is MIPSOL callback called only on new incumbent or on all integer solutions?
Answered
Hello,
I believe this is more of a clarifying question about the documentation on callbacks.
I am confused about the proper behavior of MIPSOL callback. From the Callback Codes page, I read that it is call when new incumbent solutions are found, which I am reading as "solutions that actually improve the primal bound". Which is also said here, for example.
However, I can also find the information that MIPSOL is callback every time an integer feasible solution is found. That is said, here, for example. From my experience, this is the appropriate definition.
Are both these versions incompatible or am I missing something?
One scenario that I think this could be relevant is the following. An algorithm is adding subtour elimination constraints to a TSP instance. But if MIPSOL is only activated for new incumbent, the final solution pool might contain solutions with subtours.
-
Hi Pedro,
It is the case as described in the documentation, i.e., the MIPSOL callback is called whenever a new incumbent is found. A new incumbent is a solution that improves the primal bound.
But if MIPSOL is only activated for new incumbent, the final solution pool might contain solutions with subtours.
If your lazy constraints eliminate solutions with subtours then the final solution pool will not contain these solutions, because they are cutoff by the respective lazy constraint(s).
Best regards,
Jaromił0 -
Hi Jaromil,
I appreciate the quick response. But it is still fuzzy to me. I will try to elucidate with an example.
Let us say the solver has registered an incumbent with value 100 for a minimization problem. Later, in the optimization, it found a solution with value 105 (with subtours, i.e, not feasible). This 105 solution is not a new incumbent (105 > 100), so MIPSOL *will not* be triggered (right?). Since I did not have a change to add a lazy constraint, there is nothing to tell the solver it is not a valid solution and I am assuming it would (wrongfully) be added to the solution pool.
Cheers,
Pedro
0 -
Hi Pedro,
I do not understand your last sentence
Since I did not have a change to add a lazy constraint, there is nothing to tell the solver it is not a valid solution and I am assuming it would (wrongfully) be added to the solution pool.
The new solution \(x_{new}\) with value 105 is worse than the old solution \(x_{old}\) with value 100. Thus, it will not be saved in the solution pool, independent of what the lazy constraints do.
Best regards,
Jaromił0 -
Hi Jaromil,
I see! So maybe my issue is with the policy of adding solutions to the solution pool. I was under the impression that it saved up to 'PoolSolutions' regardless of the order the solutions were found.
So, let us say I warm-start the solver with a solution that ends up being an optimal one. In this case, regardless of how many solutions were found during execution, will the solution pool only contain 1 solution? Would this behavior be the same even if I change the 'PoolSearchMode' parameter?
I appreciate your patience.
Cheers,
Pedro
0 -
Hi Pedro,
So, let us say I warm-start the solver with a solution that ends up being an optimal one. In this case, regardless of how many solutions were found during execution, will the solution pool only contain 1 solution?
Yes.
Would this behavior be the same even if I change the 'PoolSearchMode' parameter?
The behavior will not change. The PoolSearchMode parameter controls the additional behavior after an optimal solution has been found.
Best regards,
Jaromił1
Please sign in to leave a comment.
Comments
5 comments