Closed mzy2240 closed 6 months ago
dont think it is related to HiGHS.jl
but loop @odow in just in case
This isn't a bug. It's an artefact of using a positive gap tolerance, and was interesting to observe
Here are
With a gap tolerance of 0.0005...
HiGHS with presolve finds the optimal solution of 2084748.23857, and has a dual (lower) bound of 2084172.97145 so stops because the relative gap of 0.000276 satisfies the tolerance
HiGHS without presolve gets a sub-optimal solution with objective 2085446.34169, and has a dual (lower) bound of 2084650.38456 (rather larger than HiGHS with presolve has when it stops) so stops because the relative gap of 0.000382 satisfies the tolerance
Gurobi gets a sub-optimal solution with objective 2085148.187359, and has a dual (lower) bound of 2084533.829127, (rather larger than HiGHS with presolve has when it stops) so stops because the relative gap of 0.000295 satisfies the tolerance
Make sense. Thank you for the investigation!
I am trying to tune the HiGHS on a MIP problem and happen to find out that HiGHS returns worse result if switching off the presolve. I have attached the case that should help reproduce the issue. With
mip_rel_gap=0.0005
, I am able to get2.084748238572568e6
when presolve is enabled and2.0849273612253e6
when presolve is disabled. This is a minimization problem. I am running HiGHS v1.7.0 on a M1 Max machine. model_1.mps.zip