Does model.cbSetSolution affect the search process?
AnsweredHello, I am working on a model that finds all best feasible solution.
In my case of the problem, If I find one feasible integer solution, I can find n more feasible solution. Thus, I am adding them with model.cbSetSolution() in my MIPSOL callback.
Here, I am wondering if this action affects the process of branch and bound process. e.g. adding the other feasible solution might prune the search tree and therefore shorten the search process.
to add, I have these parameters on;
model.setParam('PoolSearchMode', 2) # solver will find #'PoolSolutions' best solutions
model.setParam('PoolSolutions', 2000000000) # find maximum number of solutions; MAXINT
model.setParam('PoolGapAbs', 0) # find exact optimal solution pool-
Hello Junseo,
Yes, you can improve the search for "all" solutions with the best objective (i.e., using
PoolSearchMode=2,PoolGapAbs=0, and a sufficiently large value forPoolSolutions) by providing additional solutions via callbacks and thecbSetSolution()method.This works in two ways:
- If a provided solution has the same objective as the best solution found up till now, then it is added to the candidate pool.
- If a provided solution has a better objective value than any other solution found or provided so far, the candidate pool is cleared, and the newly submitted solution becomes the sole element in the candidate pool.
In both scenarios, Gurobi may utilize the provided solutions as starting points for various heuristics, such as NoRel, which can help the solver discover more or even better solutions. Furthermore, in the second scenario, Gurobi can leverage the improved objective value to prune nodes with a relaxed objective bound that is strictly worse.
Just so you know, if you set PoolGapAbs to exactly 0, Gurobi may discard some truly optimal solutions due to rounding errors. Depending on the strength of your MIP formulation, Gurobi may also take considerable time to refine the dual bound to confirm that your solutions are indeed optimal.
I hope that helps answer your question.
Best regards,
Martin
----
Dr. Martin Bromberger - MIP Development Scholar
Gurobi GmbH
Sandstraße 104
40789 Monheim am Rhein
Email: martin.bromberger@gurobi.com (he, him, his)
-------------------------------------------------------------------------------
Sitz der Gesellschaft: Düsseldorf
Registergericht: Düsseldorf, HRB 99473
Geschäftsführer: Craig Albrecht und Duke Perrucci
1 -
Thanks for your help, I really appreciate it!!
I have one more question from the answer you gave,
Is there any criteria to set the PoolGapAbs value? if the objective is integer-valued, and the objective value is about in range of 0-80, can you suggest a value to use?
0 -
There are three competing factors to consider:
- Likelihood and magnitude of rounding errors
- Strength of your formulation, i.e., how close is the relaxed problem to the convex hull of the integer feasible solutions
- How close is the next best solution you want to exclude
If your model is likely to exhibit significant rounding errors, particularly in the objective value, you might miss relevant solutions if PoolGapAbs is too small.
A large PoolGapAbs can slow down the search if your model is weak. The reason is that Gurobi cannot prune some of the nodes because the current best objective + PoolGapAbs is larger than the relaxed optimal objective of those nodes.
A large PoolGapAbs can also lead to "wrong" solutions, i.e., that you accidentally include the next best solution instead of just all the best solutions.
I can't say a lot about the strength of your formulation, but at least the next best solution is reasonably far away if the objective is always an integer value.
With respect to likelihood and magnitude of rounding errors: It sounds like the values (coefficients, rhs, bounds, etc.) in your model are all integers that can be modeled precisely as floating point numbers, the ranges between those values are equally small as your objective range, there aren't a lot of variables, and you did not modify the base tolerances of the solver. If all of that is true, then significant rounding errors are unlikely.
All of that together means PoolGapAbs=0 might actually work well for your problem. If you want to be sure, I'd recommend experimenting with increasing PoolGapAbs values up to 0.25. You can be reasonably sure that you did not miss any relevant solutions if you get the same number of solutions for PoolGapAbs=0 and PoolGapAbs=0.25 (or up to the point where the problem takes too long for you to solve). If you don't want to experiment, I'd personally try PoolGapAbs=1e-4.
0
Please sign in to leave a comment.
Comments
3 comments