Incorrect Optimal Solution from scip

[zxt5]

I am using scip to solve (minimize) this MIP problem seed.txt and getting the result:

Solver: SCIP_CMD Status: Optimal Objective: -38885.13248833593 x0 = -192.0, x1 = 47.8781752203214, x2 = -179.0, x3 = -2.0, x4 = -12.0, x5 = 168.0, x6 = 200.0, x7 = 200.0,

All other solvers I have tried (HiGHS, SCIP, GLPK, GUROBI) returned the following results with only floating-point difference:

Status: Optimal Objective: -38873.438164852254 x0 = -192.0, x1 = 48.94401244167961, x2 = -178.0, x3 = -1.0, x4 = -11.0, x5 = 169.0, x6 = 200.0, x7 = 200.0,

I'm not sure if this inconsistency is expected. I would appreciate any suggestions or instructions.

[ambros-gleixner]

Please share a log. What is the difference between the SCIP_CMD run at the top and the SCIP run that returns the same result as other solvers?

Chances are the solution from the first run is infeasible. You can check that by typing "check" in the interactive shell after solving has finished.

[zxt5]

Sorry if I wasn't clear. There is no difference between SCIP_CMD and SCIP, which SCIP_CMD is because I was calling scip solver from pulp. I used the cmd line scip solving the problem to double-check, and it returned the same result of -38885.13.. The log file is here log.txt

Seems you are right, the solution violated the constraint. Some output:

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 0.61
Solving Nodes      : 5 (total of 6 nodes in 2 runs)
Primal Bound       : -3.88851324883359e+04 (6 solutions)
==297160==poisoning: 0x7ffe9f298400 400
Dual Bound         : -3.88851324883359e+04
Gap                : 0.00 %
  [linear] <_C44>:  +6.97<x0>[I] (-192) +11.83<x1>[C] (+47.8781752) +6.34<x2>[I] (-179) -8.64<x3>[I] (-2) +15.3<x4>[I] (-12) -17.57<x5>[I] (+168) +9.59<x6>[I] (+200) +15.87<x7>[I] (+200) >= 67.22;
;
violation: left hand side is violated by 0.00118714359879846
best solution is not feasible in original problem

SCIP> check

check best solution
  [linear] <_C44>:  +6.97<x0>[I] (-192) +11.83<x1>[C] (+47.8781752) +6.34<x2>[I] (-179) -8.64<x3>[I] (-2) +15.3<x4>[I] (-12) -17.57<x5>[I] (+168) +9.59<x6>[I] (+200) +15.87<x7>[I] (+200) >= 67.22;
;
violation: left hand side is violated by 0.00118714359879846
Violation          :    absolute    relative
  bounds           : 0.00000e+00 0.00000e+00
  integrality      : 0.00000e+00           -
  LP rows          : 1.18714e-03 1.76606e-05
  constraints      : 1.18714e-03 1.76606e-05

Any suggestions?

[DominikKamp]

Here is a simplified instance by MIP-DD for SCIP v92-bugfix.

seed_17.zip

The issue seems to lie in linear presolving since it occurs for multiple heuristics.

[alexhoen]

It seems that this is an issue with the shifting heuristic which feeds a infeasible solution to SCIP. Disabling it by setting the parameter heuristics/shifting/freq = -1 should resolve the issue for now.

Meanwhile we try to work on this issue.

[zxt5]

I see, thank you for the reply.

[DominikKamp]

As already mentioned, it is not the shifting heuristic because it also fails on the simplified problem with only heuristics/shifting/freq = -1 so rather try presolving/maxrounds = 0 as reliable workaround (it is not slower for these instances).

[DominikKamp]

The presolved problem is actually correct and solved tolerably so this is really only due to tolerances relative to increased sides caused by fixings. There is already an unmerged approach to keep track on the original sides but this is a rather extensive change. In the meantime you could simply try with a smaller feasibility tolerance like numerics/feastol = 1e-8.