Constraint violation after changing cost-values in an existing code-base
I am working on modifying a code-base that has mostly positive cost values and a negative value for the objective function the order of -5e2 to -1e2.
I am modifying the generation of this model in such a way, that I need to have larger positive values. With these modifications, I have run into an issue, where constraints are violated in the obtained solution.
I have been debugging this in the generating code for quite some time (>1 week) and I am increasingly under the impression that this is caused by Gurobi (likely due to numerics - see below) - mainly due to the strange behaviors I am observing. Here are some symptoms:
1) Constraints are violated in the final solution (sometimes, not always). Even though the optimization finished and was *not* terminated due to a timeout.
2) When I continue optimizing an obtained solution, the new solution (very often) contains the previously missing constraints.
3) The issue of violated constraints becomes increasingly prominent, with increasing cost-values.
After testing an older version of my code for debugging, I got the following output from Gurobi, which leads me to believe that this is a numerics issue:
Warning: Model contains large objective coefficients
Consider reformulating model or setting NumericFocus parameter
to avoid numerical issues.
Note however, that in newer versions of my code, I do not see this warning, but still see this strange behavior (which is also, why initially I suspected programming bug instead of Gurobi).
My question, is what I can try to figure out if this is truly a numerics issue versus an issue with my code and the way that it sets up the ILP?!
By googling I stumbled across the Gurobi parameter `NumericFocus`. I will test it, but would like to hear additional suggestions, as I am still fairly new to Gurobi.
Any help is greatly appreciated.
Best,
Michael
-
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?. -
This really does sound like a numerics issue, but without further information, I cannot say more. How are the coefficient statistics for your model?
You could experiment with different values for NumericFocus, as well as ScaleFlag=2 and/or Aggregate=0, but the most reliable fix would be to improve the numerics. Have you seen our Numerics Guidelines? They may contain some explanation and valuable input for reformulating your model.
A few more comments:
1) Constraints are violated in the final solution (sometimes, not always). Even though the optimization finished and was *not* terminated due to a timeout.
How the optimization was finished should not matter. No solution should violate the constraints (unless there are numerical issues).
2) When I continue optimizing an obtained solution, the new solution (very often) contains the previously missing constraints.
I don't understand this. What do you mean with "contains the previously missing constraints"?
3) The issue of violated constraints becomes increasingly prominent, with increasing cost-values.
This is to be expected since bigger numbers mean more numerical issues.
0 -
Hi Silke,
thanks for the answer.
I am not sure, what you mean by coefficient statistics. Is it this(?):
Matrix range [1e+00, 2e+01]
Objective range [3e-04, 1e+05]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 2e+01]Regarding this statistic: Could you point me to one or more resources on how to interpret this information?
Regarding "2) When I continue optimizing an obtained solution, the new solution (very often) contains the previously missing constraints.":
In our software, we have the ability to re-run the optimization based on the prior optimization result (I think this is called a warm-start?!). And when doing this, I sometimes observe, that after the initial optimization run, I have violations of some constraints, that are then "fixed" (meaning the constraints are then correctly applied/fulfilled) after continuing the optimization.
Best and thanks for your reply,
Michael
0
Post is closed for comments.
Comments
3 comments