Examples

Parameter usage

Let's continue with a few examples on how the parameters related to solution pools would be used. Imagine that you are solving a MIP model with an optimal (minimization) objective of 100. Further imagine that, using default settings, the MIP solver finds four solutions to this model with objectives 100, 110, 120, and 130.

If you set the PoolSolutions parameter to 3 and solve the model again, the MIP solver would return with 3 solutions in the solution pool (i.e., the SolCount attribute would have value 3). If you instead set the PoolGap parameter to value 0.2, the MIP solver would discard any solutions whose objective value is worse than 120 (which would also leave 3 solutions in the solution pool).

If you set the PoolSearchMode parameter to 1 and the PoolSolutions parameter to 10, the MIP solver would continue running after having found an optimal solution trying to find and store 10 solutions, but with no guarantee on the quality of the additional solutions.

If you set the PoolSearchMode parameter to 2 and the PoolSolutions parameter to 10, the MIP solver would attempt to find the 10 best solutions to the model. An OPTIMAL return status would indicate that either (i) it found the 10 best solutions, or (ii) it found all feasible solutions to the model, and there were fewer than 10. If you also set the PoolGap parameter to a value of 0.1, the MIP solver would try to find 10 solutions with objective no worse than 110. While this may appear equivalent to asking for 10 solutions and simply ignoring those with objective worse than 110, the solve will typically complete significantly faster with this parameter set, since the solver does not have to expend effort looking for solutions beyond the requested gap.

Interpreting attribute information

Let's try to better understand the attributes related to solution pools. Consider again a minimization problem where the parameter settings PoolSearchMode=2 and PoolSolutions=10 have been used.

First, imagine that the solver terminated with an OPTIMAL return status. We look at several possible hypothetical values of some attributes:

  • Case 1: ObjVal=100, ObjBound=100, PoolObjBound=500, and the objective value of the 10th solution in the pool is 500.

    The first solution in the pool is optimal (because ObjVal and ObjBound are equal), and the solver was able to find 10 solutions of value at most 500. Because PoolObjBound=500, we know that all solutions that the solver did not find have an objective value of at least 500. Since the last solution in the pool has value 500, the 10 solutions in the pool are definitely the 10 best solutions.

  • Case 2: ObjVal=100, ObjBound=100, PoolObjBound=+infinity, SolCount=7, and the values of the 7th and 8th solutions in the pool are 350 and +infinity, respectively.

    The solver has found 7 solutions and has proven that no other feasible solution for the model exists. The best of these 7 solutions has objective 100, the worst of them has objective 350.

Now, imagine that the solver terminated early due to a time limit (return status TIME_LIMIT). Again, we look at several possible hypothetical values of some attributes:

  • Case 3: ObjVal=100, ObjBound=50, PoolObjBound=50

    Since ObjBound < ObjVal, the solver did not prove optimality of the incumbent solution (the first solution in the pool). There can be better solutions than the incumbent.

  • Case 4: ObjVal=100, ObjBound=100, PoolObjBound=100, and the objective value of the 10th solution in the pool is 500.

    The first solution in the pool is optimal (because ObjVal and ObjBound are equal), and the solver was able to find 10 solutions with objective value at most 500. Because PoolObjBound=100, we know that all solutions that the solver did not find have an objective value of at least 100. Since the value of the last solution in the pool is 500, it could be the case that there exist 10 or more solutions with objective smaller than 500 (but greater than or equal to 100). In particular, solutions that are currently in the pool and have objective value greater than 100 might not be among the 10 best solutions.

  • Case 5: ObjVal=100, ObjBound=100, PoolObjBound=200, and the objective values of the 4th, 5th and 10th solutions in the pool are 180, 220 and 500, respectively.

    The first solution in the pool is optimal (because ObjVal and ObjBound are equal), and the solver was able to find 10 solutions of value at most 500. Because PoolObjBound=200, we know that all solutions that the solver did not find have an objective value of at least 200. This means that the first 4 solutions in the pool (up to the solution with value 180) are definitely the best four solutions that exist. The 5th solution with value 220 (and subsequent solutions in the pool) may be inferior to other undiscovered solutions.

Try Gurobi for Free

Choose the evaluation license that fits you best, and start working with our Expert Team for technical guidance and support.

Evaluation License
Get a free, full-featured license of the Gurobi Optimizer to experience the performance, support, benchmarking and tuning services we provide as part of our product offering.
Academic License
Gurobi supports the teaching and use of optimization within academic institutions. We offer free, full-featured copies of Gurobi for use in class, and for research.
Cloud Trial

Request free trial hours, so you can see how quickly and easily a model can be solved on the cloud.

Search