Subtleties and Limitations
There are a few subtleties associated with finding multiple solutions that we'll cover now.
One subtlety arises when considering multiple solutions for models with continuous variables. Specifically, you may have two solutions that take identical values on the integer variables but where some continuous variables differ. By choosing different points on the line between these two solutions, you actually have an infinite number of choices for feasible solutions to the problem. To avoid this issue, we define two solutions as being equivalent if they take the same values on all integer variables (and on all continuous variables that participate in SOS constraints). A solution will be discarded if it is equivalent to another solution that is already in the pool.
The interplay between the optimality gap
MIPGapAbs) and multiple solutions
can be a bit subtle. When using the default
non-zero optimality gap indicates that you are willing to allow the
MIP solver to declare a solution optimal, even though the model may
have other, better solutions. The claim the solver makes upon
termination is that no other solution would improve the incumbent
objective by more than the optimality gap. Terminating at this point
is ultimately a pragmatic choice - we'd probably rather have the true
best solution, but the cost of reducing the optimality gap to zero can
often be prohibitive.
This pragmatic choice can produce a bit of confusion when finding multiple optimal solutions. Specifically, if you ask for the best solutions, the optimality gap plays a similar role as it does in the default case, but the implications may be a bit harder to understand. Specifically, a non-zero optimality gap means that you are willing to allow the solver to declare that it has found the best solutions, even though there may be solutions that are better than those that were returned. The claim in this case is that any solution not among the reported best would improve on the objective for the worst among the best by less than the optimality gap.
If you want to avoid this source of potential confusion, you should
set the optimality gap to 0 when using
If you browse the log from a MIP solve with
to a non-default value, you may see the lower bound on the objective
exceed the upper bound. This can't happen with the default
PoolSearchMode - if you are only looking for one optimal
solution, the search is done as soon as the lower bound reaches the
upper bound. However, if you are looking for the best solutions,
you have to prove that the model has no solution better than the th
best. The objective for that th solution could be much worse than
that of the incumbent.
In this situation, the log file will include a line of the form:
Optimal solution found at node 123 - now completing solution pool...
One limitation that we should point out related to multiple solutions
is that the distributed MIP solver has not been extended to support
PoolSearchMode settings. Distributed MIP will
typically produce many more feasible solutions than non-distributed
MIP, but there's no way to ask it to find the best solutions.