Do node relaxation values violate constraints?
Answered
I have some binary variables in my formulation. I see that when I extract node relaxation values using cbGetNodeRel(), sometimes, these binary variables take values exceeding 1. I don't expect these variables to be binary but at least between 0 and 1. Also, these node relaxation values are violating some constraints. Is this common? If yes, why is it happening? If no, can you tell me where I am going wrong?
-
Official comment
This post is more than three years old. Some information may not be up to date. For current information, please check the Gurobi Documentation or Knowledge Base. If you need more help, please create a new post in the community forum. Or why not try our AI Gurobot?. -
Very small bound/constraint violations are not uncommon. How large are the violations you see? Are you able to post a minimal working code example that reproduces the issue?
0 -
Here is the callback code. It should essentially not print anything but it prints a bunch of binary variables with very large values.
def mycallbackGRB(model, where):
if where==GRB.Callback.MIPNODE:
for i in model.getVars():
if i.ub==1 and model.cbGetNodeRel(i)>1:
print(i, model.cbGetNodeRel(i))0 -
Here is a sample output from the callback:
<gurobi.Var y[13,13]> 4.011629032257547
<gurobi.Var y[13,14]> 5.0
<gurobi.Var y[13,15]> 11.0
<gurobi.Var y[13,16]> 275.0
<gurobi.Var y[13,17]> 12.054435483870968
<gurobi.Var y[13,18]> 27.0
<gurobi.Var y[13,19]> 8.0
<gurobi.Var y[14,0]> 14.01162903225754
<gurobi.Var y[14,1]> 41.499999999999886
<gurobi.Var y[14,2]> 19.963709677419196
<gurobi.Var y[14,3]> 388.0
<gurobi.Var y[14,4]> 11.536290322580314
<gurobi.Var y[14,5]> 5.9999999999999005
<gurobi.Var y[14,6]> 18.9637096774192
<gurobi.Var y[14,7]> 33.50302419354818
<gurobi.Var y[14,8]> 28.011629032257538
<gurobi.Var y[14,9]> 11.027217741935486
<gurobi.Var y[14,10]> 16.975806451612662
<gurobi.Var y[14,11]> 277.9516129032254
<gurobi.Var y[14,12]> 20.527217741935488
<gurobi.Var y[17,1]> 328.98837096774247
<gurobi.Var y[17,4]> 267.0
<gurobi.Var y[17,13]> 293.945564516129
<gurobi.Var y[17,16]> 167.0
<gurobi.Var y[18,1]> 178.98837096774247
<gurobi.Var y[18,4]> 404.5000000000001
<gurobi.Var y[18,7]> 381.0362903225808
<gurobi.Var y[18,14]> 348.4637096774197
<gurobi.Var y[18,17]> 312.0000000000001
<gurobi.Var y[19,0]> 12.0362903225808
<gurobi.Var y[19,3]> 351.4969758064518
<gurobi.Var y[19,6]> 49.98837096774246
<gurobi.Var y[19,14]> 140.0483870967746
<gurobi.Var y[19,17]> 136.4727822580645
<gurobi.Var y[19,18]> 995.9883709677424
<gurobi.Var y[19,19]> 991.0116290322576
<gurobi.Var xstrt[0,M1]> 990.9883709677424
<gurobi.Var xstrt[0,M2]> 985.0116290322576
<gurobi.Var xstrt[1,M1]> 1261.9883709677424
<gurobi.Var xstrt[1,M2]> 721.0116290322576
<gurobi.Var xstrt[2,M0]> 991.0428064516134
<gurobi.Var xstrt[2,M1]> 983.9571935483866
<gurobi.Var xstrt[3,M0]> 998.9883709677424
<gurobi.Var xstrt[3,M1]> 969.0116290322576
<gurobi.Var xstrt[3,M2]> 990.9883709677424
<gurobi.Var xstrt[4,M0]> 988.0116290322576
<gurobi.Var xstrt[4,M2]> 982.00 -
Thanks for the posting your callback function. From the documentation for Model.cbGetNodeRel():
Note that this method can only be invoked when the \( \texttt{where} \) value on the callback function is equal to \( \texttt{GRB.Callback.MIPNODE} \) and \( \texttt{GRB.Callback.MIPNODE_STATUS} \) is equal to \( \texttt{GRB.OPTIMAL} \)
Can you change the first line of the callback function to
if where == GRB.Callback.MIPNODE:
if model.cbGet(GRB.Callback.MIPNODE_STATUS) == GRB.OPTIMAL:
# Remainder of callback code goes hereand try again?
0 -
Hi Nitin,
Gurobi 9.5 was recently released. Included in this release is a fix to the strange behaviour of the Model.cbGetNodeRel() method you saw when MIPNODE_STATUS is not equal to GRB.OPTIMAL. With the new fix, an exception is raised if asking for a solution when MIPNODE_STATUS != GRB.OPTIMAL and the solution vector is initialized to GRB.UNDEFINED (1e+101) values.
The code snippet in the documentation of the Model.cbGetNodeRel() method is also fixed to check the model status before asking for a solution.
We hope this new fix works well for you. Please let us know if you find any issues using this.
Best regards,
Maliheh
0
Post is closed for comments.
Comments
6 comments