"early end of file reading mpsi.sol" in Xpress

[4er4er4er]

The two Windows scripts in MDXoptimalmarkets.zip are the same except that one uses xpressasl where the other uses xpress. Executing include mdx_asl.run leads to a successful conclusion:

ampl: include mdx_asl.run
shell solve

shell time: 275.88 s
load solution, fix and solve

XPRESS 9.0.3(41.01.04): Global search complete
Best integer solution found 196025.0503
0 branch and bound nodes
XPRESS 9.0.3(41.01.04): crossover=-1
barpresolve=1
cpuplatform=-1
version 
cputime=0
timing 
outlev=1
threads=20
AMPL/XPRESS 9.0.3(41.01.04) (Windows AMD64), driver(20220112), liccheck(20211124), ASL2(20230310)
Licensed to Bob Fourer, AMPL Optimization (4erYoga900).
Temporary license expires 20241231.
Using license file "C:\Users\Robert\Desktop\MDXoptimalmarkets\ampl.lic".
.......
XPRESS 9.0.3(41.01.04): Optimal solution found
Objective 196025.0504
112075 simplex iterations
Obj: 196025.05 s
solver time: 141.86 s
total time: 417.73 s
ampl: 

But include mdx_new1.run (using MP) fails with an "early end of file" error:

ampl: include mdx_new1.run
shell solve

shell time: 336.20 s
load solution, fix and solve

XPRESS 9.0.3 (41.01.04): optimal solution; objective 196040.6327
37882 simplex iterations
38 barrier iterations
absmipgap=2755.82, relmipgap=0.0140574
Error at _cmdno 17040 executing "solution" command
(file mdx_new1.run, line 40, offset 999):
early end of file reading mpsi.sol
ampl: 

It might be that the old ASL option names have not been converted properly to the new MP option names, or that some new option works differently than before -- but I'm not seeing where the difference is.

Note that the first solve in the script is carried out by

shell 'start xpressasl mpsi -AMPL';

or

shell 'start xpress mpsi -AMPL';

so it directs output to its own command window. The user who provided this minimal example might be doing this because it's required somehow by the complete application.

[glebbelov]

The reason is the slow writing of the SOL file in text format. MP does not implement binary SOL writing yet, see #142. As the script only waits for the SOL file to appear, it proceeds to the solution mpsi.sol; command, which tries to read the incomplete file. ASL driver, when asked to use text SOL format, causes the same failure.

Note that this could also happen with the binary format for large enough files.

Workaround: wait 20 s after detecting the SOL file by adding shell 'timeout /t 20'; after the loop (some wait could also happen before the continue). This still does not guarantee success, as a busy system can take longer to complete the file.

Solution: perform the initial solve by the solve; command, similar to the subsequent solve. Its output can be redirected: solve >solve1.txt;. I assume the reason for putting the initial solve into a subprocess is due to a port from another modeling/solving tool; I don't see any reason to do this with AMPL.

The whole setup could become more transparent with in-memory solver interfaces.

[4er4er4er]

A web search turned up this hack, which seems to work: Replace the shell statement inside the loop by

shell ('ren mpsi.sol mpsi.sol 1>nul 2>nul');

But I agree there doesn't seem to be any reason to invoke AMPL in this complicated way, instead of using a solve.