• Community Moderator

Dear Johan,

Best regards
Jonasz

Hi and thanks for the quick reply, the file is here:

Best,

Johan

• Community Moderator

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
Jonasz

• Gurobi Staff

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ł

Ok, thanks for looking into this. I will debug this more and see if I can figure out more details about what has happened!

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 = 120
sp.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

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.

• Gurobi Staff

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ł

Hi Jaromil,

Thanks, looking forward to see what you will conclude!

Best,

Johan

• Gurobi Staff

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ł

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