Code 1/3 solution at the same time
Answered
So, ive got a numerically ... challenging model, which is built on top of a known MCFP that can take ages to solve(literally terminated it after 12h today) but with less precision and presolve enabled it solves in 6s. When I now attempt to the model of interest I get the following, slightly confusing output:
this wouldnt be that much of a problem, if it didnt mess with my
....
...
routine somehow, neither branch is being executed.
Do you have an idea how to handle this more elegantly?
I'm 99% sure whats the reason for the numerical instability (BigM and wide ranges which arise naturally from the problem statement) but I would like to identify exactly how far I can take my model and that'd be far easier if errors didnt throw my variation testing loops.
ive also been looking at https://www.gurobi.com/documentation/current/refman/parameters.html
https://www.gurobi.com/documentation/current/refman/parameter_tuning_tool.html#sec:Tuning
but I doubt they can help me with my numeric issues per se, since parameters cant address the variable ranges.
thanks!
-
Hi Constantin,
Indeed it seems to be related to numerical stability. Ideally, you would improve your model to avoid this, if possible. In terms of parameters, you can try increasing the value of NumericFocus and/or decreasing the value of PreSolve, which may reduce numerical problems, possibly increasing the optimization time. You may also want to try changing the ScaleFlag parameter.
0 -
Hello Michel, thanks for your reply.
yeah, ive already been working with numeric focus 3, and turned presolve off but have not tried setting the ScaleFlag parameter yet.
The huge range of my model is related to the storage and storage BigM constraints which stem directly from the research question im working on but I am working on alternative approaches. What's annoying about this is that it unpredictably sidesteps my error handling routine interrupting my re-testing loops with slightly different parameters.I had hoped that maybe there was a miracle solution that I had missed but im not surprised that there aint one! Thanks anyway :)
0 -
It appears this model is on the brink of infeasibility. You can also set the parameters InfUnbdInfo=1 or DualReductions=0 to get a cleaner result right after the first optimization at the cost of some less powerful presolving reductions.
Unfortunately, it can sometimes happen for such models, that the normal optimization path declares infeasibility while the IIS computation finds a feasible solution. It may be that both results are true, depending on how the numerical tolerances are getting into play.
0 -
The huge range of my model is related to ... BigM constraints
Perhaps try switching the BigM constraints out for indicator constraints. See https://support.gurobi.com/hc/en-us/articles/4414392016529-How-do-I-model-conditional-statements-in-Gurobi-
0 -
Thanks, Riley, will give it a try but even with indicator constraints, that doesnt help me reduce the range on my variables since the capacity of the storage is >>>>> x_flow_t, or does it?
and thank you to you to Matthias, i will give these parameters a try and it's almost certainly the issue. I know for a fact that the model is feasible, when it otherwise wouldnt it be it can make itself feasible again thanks to very expensive sources/ sinks, which is part of the behavior I am interested in, for better and worse.
may I make a suggestion, a code 'numeric issues' would be great because then I could specifically handle the this edge case in my code
If I had the time, which I unfortunately dont, I would move all the numerically problematic constraints into their own master problem which would allow me to massively crunch down on the constraint range... but Ive never done this and done this and dont know how difficult or not it is to implement.0
Please sign in to leave a comment.
Comments
5 comments