Gurobi v. 9.5.2 and v.10 gives different results for the same small problem
Answered
Hi,
I have just upgraded to Gurobi v. 10, which lead to that my previously built algorithm (based on a MILP) no longer works in some cases. I debugged it thoroughly, and it seems that v. 10 of Gurobi behaves differently (and worse) than its predecessor for a small test case. What happens is that the preprocessing step removes all lines, and the variables that comes out to my understanding do not have correct values. I have exported the model, but I don't see a way to attach files here. I realize that it could be the case that there is just one solution, but shouldn't I then get the same value of the variables as with the previous version? Any suggestions?
-
Dear Johan,
could you please upload your model to some filesharing service and then share the link here? We will then be able to analyse the model and help you further.
Best regards
Jonasz0 -
Hi and thanks for the quick reply, the file is here:
https://drive.google.com/file/d/1uY99lSKOLYg_EEX_H1JVv6V3gClKQOkL/view?usp=share_linkBest,
Johan
0 -
Dear Johan,
I am unable to replicate your issue. I compared the logs and the solutions generated by Gurobi 9.5.2 and 10 and both the presolve statistics and solutions seem identical. Perhaps you could supply a different instance, or someone from Gurobi Team could have a look?
Best regards
Jonasz0 -
Hi Johan,
Just as Jonasz, I could not replicate the behavior you described. For both versions 9.5.2 and 10.0.0 the model you provided \(\texttt{ExpModelv10_0.mps}\) solves in basically no time to global optimal objective value \(-49\). The optimal solution point values are also the same for both versions.
Best regards,
Jaromił0 -
Ok, thanks for looking into this. I will debug this more and see if I can figure out more details about what has happened!
0 -
Ok, I understand now why you cannot reproduce it - you are using different parameters. Run the following code, this should reproduce the problem:
prob102 = gurobi_read(['c:/Code/ExpModelv10_0.mps']); %replace the path with a path to the file I provided
sp = struct();sp.OutputFlag = 1;sp.Seed = 1;sp.DisplayInterval = 1;sp.FeasibilityTol = 1.0000e-09;sp.OptimalityTol = 1.0000e-09;sp.Presolve = 2;sp.MIPGap = 4.0000e-04;sp.TimeLimit = 120sp.IntFeasTol = 1.0000e-08;
resG3 = gurobi(prob102,sp)The problem is the IntFeasTol param, the rest doesn't matter.
resG3 looks like this for me:
resG3 =
struct with fields:
status: 'OPTIMAL'
versioninfo: [1×1 struct]
runtime: 9.9993e-04
work: 2.3992e-04
objval: -1.3500e-05
x: [60×1 double]
slack: [34×1 double]
poolobjbound: -1.3500e-05
pool: [1×2 struct]
mipgap: 0
objbound: -1.3500e-05
objboundc: -1.3500e-05
itercount: 0
baritercount: 0
nodecount: 0
maxvio: 3.5000e-07
As you can see, the objval is for example totally wrong.I hope this helps!
Johan
0 -
Correction: The other parameters seem to matter as well. If I skip setting the IntFeasTol, it goes fine. However, if I only set the IntFeasTol, it also goes fine. With the combination, it doesn't.
0 -
Hi Johan,
Thank you for the additional details. I am able to reproduce the issue and will let you know once I found out what is going on.
Best regards,
Jaromił0 -
Hi Jaromil,
Thanks, looking forward to see what you will conclude!
Best,
Johan
0 -
Hi Johan,
This is a numerical issue and setting NumericFocus=2 avoids it. What happens, is that during a tightening of a binary variable a division of two double numbers which should be equal (but are not starting in the 9th digit) results in only a value of "almost 1". Then due to the tight tolerances you set, this "almost 1" is treated as 0 (because the variable is binary and the "almost 1" does not fulfill tolerances set). This then results in a wrong variable fixing. This is really a corner case and we will try to improve the numerical behavior in an upcoming release.
Please note that working with very tight tolerances can lead to such bogus results from time to time due to numerical precision. Usually, tightening feasibility tolerances should only be performed if the optimal solution provided violates constraints or variable bounds or has constraint/bound violations close to the default feasibility tolerances.
Best regards,
Jaromił0 -
Hi Jaromil,
Great, I changed the IntTol to 10^-7, which I after some consideration think should be ok for my problem, and the problem no longer appeared! Thanks for the help, from my point of view you can close this now!
Best,
Johan
0
Please sign in to leave a comment.
Comments
11 comments