computeIIS log not displaying correctly
回答済みAfter defining a nonconvex bilinear model (m.Params.NonConvex = 2) with no objective and running model.computeIIS() the log I get is the same as the one I get with model.optimize(), which solves it as a continuous MIP, assuming the objective as zero. I know from the guide that computeIIS should produce a different log, why is this log not being produced? Is there a way to force it or vomputeIIS does not work with this class of models?
-
-
Gurobi Staff
Hi Giordano,
Before we can compute an IIS we need the model to have an infeasible model status (see status codes).
If the model is yet to be solved, then it will first need to be before it can compute an IIS.
Additionally, sometimes our solver cannot distinguish between a model being infeasible or it being unbounded. This is due to dual reductions, and why we have the INF_OR_UNBD status code. If you try and compute an IIS for a model with this status code, the solver will re-solve with dual reductions off, before computing an IIS.
I suspect one of these two cases is what you are seeing.
- Riley
0 -
-
Thank you for your reply, I understand. Is this additional optimisation step equivalent to m.optimize() with a conditional on the parameter m.Status or is it a different routine? I wonder if it is a different routine, and if it is accessible directly in its own rights on gurobipy, and under which name, since on my machine it seems to be significantly less taxing in terms of RAM requirements than m.optimize().
0 -
-
-
Hi Giordano,
The optimization is the same routine - but performed with DualReductions=0. If it is taking less RAM then perhaps this is a side-effect of turning dual reductions off. It might be interesting to perform an optimization yourself with dual reductions off and compare the RAM requirements.
- Riley
0 -
-
Thank you for your reply, I tested what you propose. The odd thing is that when I run model.optimize() with model.Params.DualReductions = 0, the RAM usage is not that much different from the default; more importantly, the objective's best bound is displayed in the log as it improves (while no incumbent is found so far, probably because of what you said about the model being either infeasible or at the edge of infeasibility).
On the other hand, when I run model.computeIIS() instead, the RAM is barely tapped in, and the best bound on the objective is always -0.00000 (with no incumbent found so far, for the previous reason). That is why I wondered if the routine that computeIIS uses to get the model.Status is different than model.optimize() + model.Params.DualReductions = 0. For one thing, it seems that the objective of the model is replaced by something else (perhaps zero? what is the meaning of -0.00000?), and I fail to grasp how this could lead to such a radically different RAM usage.
0 -
-
-
it seems that the objective of the model is replaced by something else (perhaps zero? …)
Yes, sorry I forgot to mention that. Since we're only concerned with feasibility we can zero out the objective function, and this will make dual reductions more effective.
I fail to grasp how this could lead to such a radically different RAM usage
Maybe it is easier to think about what causes high RAM usage and see if it applies. How do the presolved model sizes compare? How large are the branch and bound trees in each solve?
0 -
-
Thank you for your suggestions, I did some testing. Presolve should not play a significant role, as the time reported on Presolve is 0.00s and the sizes reported are all the same, whether I use model.optimize() with DualReductions = 0 and zero objective (which in term of RAM usage I confirmed to be equivalent to model.computeIIS() as you suggested) or with the quadratic objective (higher RAM usage). As I am only concerned with determining infeasibility of the region, it is perfectly fine for me to proceed with a zeroed out objective.
However, focusing only on model.optimize() with DualReduction = 0 and considering zeroed out objective vs quadratic objective, I noticed that the depth reported by the branch and bound nodes is far larger when using the quadratic objective. In both cases I have not been able to make either routine terminate, even though I let it run for multiple days, but from the logging I would say that this larger depth reported by the explored nodes in the quadratic objective case should be the cause of a more extensive RAM usage (it is so extensive that at some point my shell kills the routine). The question is whether this higher RAM usage and depth corresponds to faster progress towards the termination of the routine, or whether it is just waste, and as you mention, DualReductions = 0 is more effective with a zero objective, and can do just as much and as fast without wasting so much RAM. Would you consider the latter scenario conceivable, or it is more likely that the zeroed out objective is simply slower and lagging behind?
0 -
-
-
Hi Giordano,
My money is on the zero-objective being more effective. I wouldn't say it is slower or lagging behind. The smaller B&B is just due to the nature of the solve is just different (it will be doing other things instead of pursuing the B&B tree).
- Riley
0 -
サインインしてコメントを残してください。
コメント
7件のコメント