Code under "if where == GRB.Callback.MIPSOL" is executed, but solution count is 0
Answered
Hello,
I am experiencing a very strange behavior of Gurobi when solving a model using a callback function. I can tell that a feasible solution has been found, as there is a console output that is only created under "if where == GRB.Callback.MIPSOL":
As far as I understand, this code can only be executed after a feasible solution has been found. However, the solution count is still 0:
In this case, calling the ".X" attribute on a variable will result in an error. Furthermore, I am solving numerous problem instances using this code and the number of instances that is solved successfully until the problem described above occurs is not consistent (but usually fairly small, i.e. 2 - 5).
Do you have any idea what could cause this behavior?
Thank you very much in advance for your help!
Kind regards
Jonas
-
Hi Jonas,
Could you post a minimal reproducible example showing this issue? Best would be a simple Python code snippet where you read a model file and execute the optimize method with your callback. Could you please then also share the corresponding model file as described in Posting to the Community Forum?
Best regards,
Jaromił0 -
Hi Jaromił,
Sorry for the late reply. I have a question on how to read the model from a file in my case. Within my callback function, multiple internal attributes of the model are required. How can I obtain these when reading from a file?
I tried to simply write the model to an *.mps file before the optimization is started and then read this file back in the minimal reproducible example. As it turns out, the internal attributes assigned to the model are not written to the *.mps file and thus, when I try to solve the model read from this file using the callback fails immediately.
I am happy to provide a minimal reproducible example, but it seems you need to give me another hint here. Again, thanks a lot in advance!
Best regards,
Jonas0 -
Hi Jonas,
How can I obtain these when reading from a file?
After reading reading the model from a file, you would have to get all variables and constraints and rebuild all of your variable/constraint lists.Then, via variable and constraint names, you would have to reconstruct any attribute lists that you needed for your callback.
If it's OK for you, you could just provide the code which generates your model in the reproducible example instead of using an MPS file. This would save you quite a lot of work.
Best regards,
Jaromił0 -
Hi Jaromił,
I simplified my code as far as possible and uploaded the required parts to the following Google Drive folder.
The instance is read from a text file (cv10.rcp) using the provided reader (reader_j30.py). The actual code can be found in the file ctabo_lazy_mre.py and the behavior described above is reproduced by executing the test function at the bottom of the file (where the instance file and reader should be in the same directory as the main code). I hope that it is okay to provide my code this way.
Let me know if I should further clarify anything about the code.
Best regards,
Jonas0 -
Hi Jonas,
Thank you for the files. It worked perfectly. What you see here is the following:
1. Gurobi finds a feasible solution
2. Your callback is executed and the line Update maxt ... is printed
3. Within the same call to the callback, the newly found solution is cut off by a lazy constraint your code adds
4. The solution gets discarded because it has been cut off by a newly added lazy constraint, i.e., solution count is not increased
5. The newly added lazy constraint(s) is/are moved to a so-called cut pool. Gurobi uses only chosen constraints from the cut pool. This means that at the end of the optimization, it is possible that the number of reported lazy constraints in the "Cutting planes" statistics does not match the actual number of added lazy constraints. This is because, the cuts reported in the "Cutting planes" statistics, are cuts that are used to prove the final bound, i.e., your lazy constraints can become redundant during the optimization process but they were certainly used to cut off solutions and possibly generate new stronger cuts.I hope this makes the situation more clear.
Best regards,
Jaromił0 -
Hi Jaromił,
I am very sorry for the late reply! Thank you very much for running my code and explaining to me what is going on, I think this will help me a lot. I did not have the time yet to look for the root cause, but at least I know where to start searching.
Again, thanks a lot for your help!
Best regards,
Jonas
0
Please sign in to leave a comment.
Comments
6 comments