Skip to main content

Gurobi v. 9.5.2 and v.10 gives different results for the same small problem

Answered

Comments

11 comments

  • Jonasz Staszek
    Community Moderator Community Moderator
    Thought Leader
    Gurobi-versary
    First Question

    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
    Jonasz

    0
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

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

    https://drive.google.com/file/d/1uY99lSKOLYg_EEX_H1JVv6V3gClKQOkL/view?usp=share_link

    Best,

     

    Johan

    0
  • Jonasz Staszek
    Community Moderator Community Moderator
    Thought Leader
    Gurobi-versary
    First Question

    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

    0
  • Jaromił Najman
    Gurobi Staff 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ł

    0
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

    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
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

    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

     
    0
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

    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
  • Jaromił Najman
    Gurobi Staff 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ł

    0
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

    Hi Jaromil,

    Thanks, looking forward to see what you will conclude!

    Best,

    Johan

    0
  • Jaromił Najman
    Gurobi Staff 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ł

    0
  • Johan Gustafsson
    Gurobi-versary
    Curious
    Conversationalist

    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.