Do not discard a MIP solution when its repair LP fails to solve (#3180)

[EamonHetherton]

Fixes #3180.

The defect

When a MIP solution is feasible for the presolved model but violates the original model by more
than mip_feasibility_tolerance, HighsMipSolverData repairs it by fixing the integer columns and
re-solving the LP in the original space. The repaired solution is accepted only if that LP returns a
feasible primal solution, so a failure of the solver is treated exactly like a solution that is
genuinely bad: it is discarded, and kHighsInf is returned so it is not used for bounding.

The repair LP is solved in the original space with the dual simplex, which on a badly scaled model
can fail the ratio test — "excessive dual values", or its primal counterpart — and return
kSolveError. When the discarded solution is the optimum, the search reports a worse incumbent as
Optimal at a zero gap. The repair LP runs with output_flag = false, so the error it raised is
never shown either.

The change

Two parts, both in HighsMipSolverData::transformNewIntegerFeasibleSolution.

Retry a failed repair LP without presolve.

    tmpSolver.optimizeLp();
    if (tmpSolver.getModelStatus() == HighsModelStatus::kSolveError) {
      tmpSolver.setOptionValue("presolve", kHighsOffString);
      tmpSolver.optimizeLp();
    }

The failing LPs solve to optimality that way; primal simplex and IPM also solve them, so if you
would rather fall back differently, any of the three recovers the solution.

Recompute the row activities from the repaired column values.

      solution = tmpSolver.getSolution();
      calculateRowValuesQuad(*mipsolver.orig_model_, solution.col_value,
                             solution.row_value);

This part is not optional, and it is the subtler of the two. solutionFeasible() is passed
&solution.row_value and, when a row-value vector is supplied, trusts it instead of recomputing:

if (pass_row_value) {
  ...                                    // used as given
} else {
  calculateRowValuesQuad(*lp, col_value, row_value);
}

After a repair those activities come from the repair LP and need only satisfy that LP to its own
tolerance, whereas the check later applied to the returned solution recomputes them in quad
precision. Without recomputing, a repaired solution can pass here at 1e-7 and then fail that check
at 1.5e-7, turning a reported Optimal into Solve error. With the retry alone I reproduced
exactly that on a generated model; with both parts the same model correctly rejects the marginal
point and keeps a genuinely feasible one.

Effect

	result
12710 x 23091 production MIP	-3755449.094926 -> -3755469.767048 (correct); 17 previously discarded solutions recovered
14412 x 26520 production MIP	unchanged and correct at -19105203.4816
generated MIP, repair LP fails	-7.60954221608e+14 -> -7.60954325469e+14 (correct)
generated MIP, marginal repair	now Optimal with no error, where the retry alone gave a false optimum
the 26 MIP models in check/instances	identical objectives to stock latest
full unit test suite	1259300 assertions in 334 test cases, pass

Measured on this branch alone — latest plus this commit, with no other changes applied — so the
result does not depend on anything else I have reported.

The retry is reached only when a repair LP has already failed, and the recomputation only when a
repair has already succeeded, so neither can perturb a model where no solution is ever repaired.

What I would advise against

Addressing this in HPresolve::scaleMIP, which is where the violation that triggers the repair
comes from — it scales rows down, and the feasibility tolerance is not scale invariant, so a row
scaled by s and satisfied to feastol in the presolved space is satisfied only to feastol / |s|
in the original one.

Suppressing the down-scaling does fix the first model and leaves check/instances unchanged in
objective, node count and LP iteration count. But on the second production model above it causes a
wrong answer — -19104998.2316 against a correct -19105203.4816 — even though that model never
reaches the untransformed-violation path. Any change to scaleMIP perturbs models that have no
defect. The repair path is the right place: it already exists, it already recovers 17 of the 34
repairs on the first model, and it is inert otherwise.

On a regression test

I have a generated MIP that reproduces the discard — 134 rows x 356 columns, 72 integers — but it
needs the pinned option set and its objective coefficients span 1e-6 to 1e12, which is the kind
of instance that was objected to on #3172. I have not added it as a test for that reason, and am
happy to supply it if you would like it, or to look for a numerically tamer one.

Testing

• both production models correct under presolve on and off;
• the reproducers for MIP: invalid cut from a redundant variable bound gives a suboptimal solution reported as Optimal at gap 0 #3170, MIP: path-mixing cut is untransformed with different bound substitutions than its coefficients were built with, producing an invalid cut #3171 and MIP: presolve fixes a column whose bounds are equal only within tolerance without bounding the objective error, returning a suboptimal solution as Optimal #3173 unchanged and correct;
• the numbers in the table above.

🤖 Generated with Claude Code

[jajhall]

Fair enough, this does no harm

[codecov]

Codecov Report

❌ Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.92%. Comparing base (4e6489d) to head (187c624).
⚠️ Report is 135 commits behind head on latest.

Files with missing lines	Patch %	Lines
highs/mip/HighsMipSolverData.cpp	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #3181      +/-   ##
==========================================
- Coverage   73.18%   72.92%   -0.27%     
==========================================
  Files         432      436       +4     
  Lines      105460   106038     +578     
  Branches    16982    17071      +89     
==========================================
+ Hits        77182    77329     +147     
- Misses      28002    28433     +431     
  Partials      276      276              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Opt-Mucca]

Presolve may have already been disabled in the lines directly above. In this case there's no need to re-run the LP.

[jajhall]

True, in which case the LP could be solved with presolve "on" as another attempt to get an optimal solution.

If it matters enough to a user, IPM could also be tried.

[Opt-Mucca]

@EamonHetherton you keep mentioning "production models" and "available upon request". Any chance you're willing to share them? If so we'd store them, use them for testing, and make them public with appropriate credit in a couple of years.

[jajhall]

See comment

[EamonHetherton]

@Opt-Mucca yes, I can share more, see #3180 (comment) for some detail. Would you like an MPS file where I find a bug? they are usually of the order of 2-3MB.

[EamonHetherton]

Good catch, thanks — applied.

use_presolve is !mip_root_presolve_only, so with that option set presolve is already off for
the first attempt and the retry would solve an identical LP and fail in the same way. The retry is
now guarded:

    if (use_presolve &&
        tmpSolver.getModelStatus() == HighsModelStatus::kSolveError) {
      tmpSolver.setOptionValue("presolve", kHighsOffString);
      tmpSolver.optimizeLp();
    }

Re-verified after the change: the two production models and the generated reproducer still return
the correct optima, including with mip_root_presolve_only = true, and the full unit test suite
passes (1259300 assertions in 334 test cases).

I have not added the further fallbacks you both suggested — retrying with presolve on when it was
off first, or trying IPM — since that widens the change beyond what the reported defect needs. Both
would fit in the same place if you want them; on the LPs I have, presolve off, primal simplex and
IPM all solve what the dual simplex fails on, so any of the three works as a fallback.

[Opt-Mucca]

Happy with the changes! I'd consider removing all comments though as they're pretty verbose and it's always clear what's happening.

[Opt-Mucca]

@EamonHetherton I'd like one or two of the instances that you think are representative of the application. It doesn't have to be the ones that exposed some bugs.

[jajhall]

Closes #3180

[EamonHetherton]

@Opt-Mucca how would you like me to get the mps files to you? I would rather not make them public at this stage.

[Opt-Mucca]

@EamonHetherton please email me using the information here https://www.zib.de/members/turner (if the files are more than a couple of megabytes compressed then please send a good drive link or something similar)