Results between Gurobi and AMPL suggest there's an issue with Gurobi calculations




  • Eli Towle

    Hi Roy,

    Gurobi 8.1.0 includes the Python 2.7 interactive shell, which uses integer division when the division operator is used with two integer operands. So, this line:

    m.addConstr((1/200)*x_A + (1/140)*x_B <= 40, "Time")

    is adding the constraint \( 0 x_A + 0 x_B \leq 40 \). To fix this, you can add the statement "from __future__ import division" to the beginning of your code. Alternatively, you can change one of the division operands in each division operation to be a float (e.g., 1.0 / 200).

    Also, note that adding two inequalities simultaneously through Model.addConstr() is not supported in Gurobi 8.x. Thus, these two statements

    m.addConstr(0 <= x_A <= 6000, "A_Limit")
    m.addConstr(0 <= x_B <= 4000, "B_Limit")

    will result in unexpected behavior (likely, the first inequality will be discarded). In Gurobi 9.0, to be released in a few weeks, this code will result in an error.

    Finally, variables are nonnegative by default. You can specify variable bounds directly in the Model.addVar() method:

    x_A = m.addVar(ub=6000, vtype=GRB.INTEGER, name="x_A")
    x_B = m.addVar(ub=4000, vtype=GRB.INTEGER, name="x_B")

    I hope this helps!


    Comment actions Permalink
  • Roy Ruiz

    thank you, Eli. This is great! All of those options worked beautifully. I was trying to figure out a way to debug it, but couldn't. If you have any recommendations for debugging issues like this in the future, please let me know.

    Also, I assume you recommend I specify the variable bounds directly in the Model.addVar() instead of using the two inequalities since variables are nonnegative by default, right?

    What if I need to include a range in which it also included negative values? Is there a way to add that in Model.addVar()?

    Comment actions Permalink
  • Silke Horn

    Hi Roy,

    To debug issues like this, you could write the model to an LP file and inspect that. In the LP file, you can often see if something went wrong when building your constraints.

    Yes, it is recommended to specify variable bounds as bounds instead of as constraints. You can do this in addVar() or later via the UB attribute (e.g. x_A.UB = 6000), but it is usually clearer to do it in addVar.

    If your variable has a lower bound different from 0, you can define it as follows:

    x_A = m.addVar(lb=-1000, ub=6000, ...)
    x_B = m.addVar(lb=-GRB.INFINITY, ub=4000, ...)
    Comment actions Permalink
  • Roy Ruiz

    thank you Silke! :)

    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk