MIPSOL not triggered, infeasible solution returned
回答済みHi,
I wrote a callback to forbid infeasible solutions using lazy constraints. It only does something if the context is MIPSOL. It works well but in rare cases I get the following behaviour:
1) Callback is called, cuts are generated
2) Callback is never called with MIPSOL context again
3) Gurobi returns a different integer solution, which happens to be infeasible and would have been forbidden by my callback. Optimisation status is OPTIMAL.
The solution returned in 3) is clearly considered integer-feasible by Gurobi, otherwise it would not return this solution as optimal. So why is the MIPSOL context not triggered on this solution?
This happens with both 9.0.1 and 9.0.2. If I also generate lazy constraints on MIPNODE contexts then the problem goes away, but then I spend a lot more time in callbacks, which I was trying to avoid by using only MIPSOL.
-
正式なコメント
-
Gurobi Staff
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?. -
-
-
Hi Fabien,
Did you set the LazyConstraints parameter to 1? Lazy constraints are also explained here and here.
Does that help?Cheers,
Matthias0 -
-
Hi Matthias,
thanks for your quick reply. It does not help. Yes I did set LazyConstraints to 1 and in most cases my lazy constraints are generated properly. This is described in my post above: in 1) Lazy constraints are generated and they work. This happens several times. Then later in the same run (so in the same call to optimize()) another integer solution is obtained but the MIPSOL context is not happening in the callback, only other contexts such as MIP and MIPNODE. This seems like a bug to me: I would expect the callback to be called with context MIPSOL every time an integer solution is found. But maybe I am missing something?
Cheers,
Fabien
0 -
-
Hi,
I would like to know if this is being investigated or if I should rather find my own solution to the problem mentioned above.
Cheers,
Fabien
0 -
-
-
Hi Fabien,
Can you please post your callback code?
Thanks,
Eli
0 -
-
Hi Eli,
thanks for the quick reply. I can't really share the callback code: it's ongoing research, only works as part of a larger code base for the research project, and it's written in Julia (which is not supported). But I would really like to know if this is normal behaviour that the callback does not get called with where = MIPSOL after an integer solution is found, or if it is a bug. Perhaps you can answer this? If it is a bug then I will try to produce a MWE in Python; if it is normal behaviour then I will design my callback accordingly.
Cheers,
Fabien
0 -
-
-
Hi Fabien,
The MIPSOL callback should be called whenever an integer-feasible solution is found. Is the MIPSOL callback not called at all, or is the problem that your lazy constraint isn't added or doesn't cut off the new solution? An MWE in one of the Gurobi APIs would be great to look at.
Somewhat related: the values of integer variables lie within the integer feasibility tolerance. For example, instead of checking if a binary variable \( x \) is exactly equal to \( 1 \) in the MIPSOL callback, you would check if \( x > 0.5 \).
Thanks,
Eli
0 -
-
Hi Eli,
thanks for the answer. The issue is that the MIPSOL callback is called in general, but in rare cases it is not called. Therefore Gurobi returns an integer-feasible solution that is not feasible, let's call it x*, according to lazy constraints that I never got a chance to add. I have been struggling to create a MWE and it looks like I would have to reimplement the whole project in Python, which I cannot do.
Right now I found a "fix" which consists in reducing the value of IntFeastol. However this does not sound like a proper fix to me: Gurobi clearly considered x* to be integer-feasible with the default setting, since it returned it. So it should also have called the callback with MIPSOL on x*. So I think I did not fix anything but just slightly changed the environment therefore the observed behaviour does not happen any more. I will run large-scale experiments (i.e. many test instances) and revive the thread if I encounter this issue again.
Cheers,
Fabien
0 -
-
-
Gurobi 9.1 was recently released. It includes a fix for a bug where a new incumbent solution might not trigger the MIPSOL callback. So, it's possible that your issue is fixed in Gurobi 9.1, but I can't say for sure since we never had a reproducible example to test. Could you try Gurobi 9.1 and see if all incumbent solutions are properly passed to the MIPSOL callback?
0 -
投稿コメントは受け付けていません。
コメント
9件のコメント