Potential issues with presolve: incorrect 'optimal' solution and incorrect infeasibiliy detection about highs HOT 10 OPEN

I'm not sure if it would have been better to create a new issue but I suspect mine is another manifestation of this issue (please let me know if you prefer a separate issue).

Optimizing model.mps.txt gives the following values with different solvers under different presolve settings.

We noticed the difference while upgrading from 1.5.3 to 1.7.0 so included that one in the table as well.

Everyone agrees on the optimal objective function values if the presolve is off but HiGHS deviates from the optimal significantly if the presolve is active.

I couldn't try on 1.7.1 as the model is created in julia and the latest version of highs.jl points to 1.7.0.

Here are at the solver logs:
gurobi-lp-presolve-off.log
gurobi-lp.log
gurobi-mps-presolve-off.log
gurobi-mps.log
highs-1.5.3-presolve-off.log
highs-1.5.3.log
highs-1.7.0-presolve-off.log
highs-1.7.0.log

from highs.

Thanks. There are bugs in the MIP presolve that we are steadily fixing. This can be added to the instances @fwesselm

I just tried the latest branch, and this seems to be fixed:

Solving report
Status Optimal
Primal bound -132.633753085
Dual bound -132.633753085
Gap 0% (tolerance: 0.01%)
Solution status feasible
-132.633753085 (objective)
0 (bound viol.)
0 (int. viol.)
0 (row viol.)
Timing 1.53 (total)
0.07 (presolve)
0.00 (postsolve)
Nodes 1
LP iterations 677 (total)
0 (strong br.)
237 (separation)
36 (heuristics)

from highs.

With latest:

• First (1725a.mps) is incorrectly identified as infeasible in presolve, and solved correctly with --presolve=off. Error is in reduction 851/861
• First (1725b.mps) gets wrong optimal objective value of -4987010.44031 rather than -4987029.63936, with the latter obtained when --presolve=off. Error is in reduction 850/971

from highs.

@jajhall I am having a look, if that's Ok

from highs.

Sure, I've got marking to do for a few more days

from highs.

Thanks. There are bugs in the MIP presolve that we are steadily fixing. This can be added to the instances @fwesselm

from highs.

This is great news @fwesselm

This might be due to differences in compute environment but one thing that I want to flag is that the total solver duration is very different between your output and mine (1.53s vs. 0.06s).

I wonder if reading from MPS versus creating the model directly from julia has any role here.

from highs.

This is great news @fwesselm

This might be due to differences in compute environment but one thing that I want to flag is that the total solver duration is very different between your output and mine (1.53s vs. 0.06s).

I wonder if reading from MPS versus creating the model directly from julia has any role here.

Oh, yes, I did not pay attention to the running times. I built in debug mode, which will be much slower.

from highs.

Yes, solving in debug takes 1.02s for me, and 0.16s in release

from highs.

I just tried the latest branch, and this seems to be fixed:

Hopefully, although fixes to presolve may cause the sequence of reductions to change and avoid the error

from highs.