Try our new documentation site (beta).
MIP Models
While default settings generally work well, MIP models will often benefit from parameter tuning. We offer the following guidelines, but we also encourage you to experiment.
Most Important Parameters
The two most important Gurobi settings when solving a MIP model are
probably the Threads and MIPFocus parameters. The
Threads parameter controls the number of threads used by the
parallel MIP solver. The default is to use all cores in the machine
(up to 32). If you wish to leave some available for other activities,
adjust this parameter accordingly.
The MIPFocus parameter allows you to modify your high-level
solution strategy, depending on your goals. By default, the Gurobi
MIP solver strikes a balance between finding new feasible solutions
and proving that the current solution is optimal. If you are more
interested in good quality feasible solutions, you can select
MIPFocus=1. If you believe the solver is having no trouble
finding the optimal solution, and wish to focus more attention on
proving optimality, select MIPFocus=2. If the best objective
bound is moving very slowly (or not at all), you may want to try
MIPFocus=3 to focus on the bound.
Solution Improvement
The ImproveStartTime and ImproveStartGap parameters
can also be used to modify your high-level solution strategy, but in a
different way. These parameters allow you to give up on proving
optimality at a certain point in the search, and instead focus all
attention on finding better feasible solutions from that point onward.
The ImproveStartTime parameter allows you to make this
transition after the specified time has elapsed, while the
ImproveStartGap parameter makes the transition when the
specified optimality gap has been achieved.
Termination
Another important set of Gurobi parameters affect solver termination.
If the solver is unable to find a proven optimal solution within the
desired time, you will need to indicate how to limit the search. The
simplest option is to limit runtime using the TimeLimit
parameter. Of course, using a wall-clock based time limit may lead to
non-deterministic results. This means that performing the same
optimization twice with exactly the same input data can lead to
stopping at different points during the optimization process and thus
producing different solver output. If a deterministic stopping
criterion is desired, one may use the WorkLimit parameter
instead. This specifies a limit on the total work that is spent on
the optimization. One work unit corresponds very roughly to one
second, but this greatly depends on the hardware on which Gurobi is
running and on the model that has been solved.
Another common termination choice for MIP models is to set
the MIPGap parameter. This parameter allows you to indicate
that optimization should stop when the relative gap between the best
known solution and the best known bound on the solution objective is
less than the specified value. You can terminate when the absolute
gap is below a desired threshold using the MIPGapAbs parameter.
You can also terminate based strictly on the current lower or upper
bound using the BestBdStop or BestObjStop parameters.
Other termination options
include NodeLimit, IterationLimit,
SolutionLimit, and Cutoff. The first three indicate
that optimization should terminate when the number of branch-and-bound
nodes, the total number of simplex iterations, or the number of
discovered feasible integer solutions exceeds the specified value,
respectively. The Cutoff parameter indicates that the solver
should only consider solutions whose objective values are better than
the specified value, and should terminate if no such solutions are
found.
Reducing Memory Usage
If you find that the Gurobi Optimizer exhausts memory when solving a
MIP, you should modify the NodefileStart parameter. When the
amount of memory used to store nodes (measured in GBytes) exceeds the
specified parameter value, nodes are written to disk. We recommend a
setting of 0.5, but you may wish to choose a different value,
depending on the memory available in your machine. By default, nodes
are written to the current working directory. The NodefileDir
parameter can be used to choose a different location.
If you still exhaust memory after setting the NodefileStart
parameter to a small value, you should try limiting the thread count.
Each thread in parallel MIP requires a copy of the model, as well as
several other large data structures. Reducing the Threads
parameter can sometimes significantly reduce memory usage.
Finally, to protect against exhausting the memory you can limit the
memory that is available to Gurobi by setting the MemLimit or
the SoftMemLimit parameters. If the total amount of memory that
Gurobi tries to allocate exceeds this value (in GBytes), it will
abort. In case of the MemLimit parameter, Gurobi will abort
immediately with an
OUT_OF_MEMORY error. In contrast, the SoftMemLimit
may be overshot a little bit, but instead of returning an error it
allows a graceful termination of the current optimization with
a MEMLIMIT status code.
Speeding Up The Root Relaxation
The root relaxation in a MIP model can sometimes be quite expensive to
solve. If you find that a lot of time is spent here, consider using
the Method parameter to select a different continuous algorithm
for the root. For example, Method=2 would select the parallel
barrier algorithm at the root, and Method=3 would select the
concurrent solver. Note that you can choose a different algorithm for
the MIP node relaxations using the NodeMethod parameter, but it
is rarely beneficial to change this from the default (dual simplex).
Difficult Relaxations
If you find that the solver is having trouble solving the root
relaxation even after you have tried the recommendations above, or is
spending an inordinate amount of time at the root node, you should try
the NoRel heuristic (controlled by the NoRelHeurTime
and NoRelHeurWork parameters). This heuristic attempts to find
high-quality solutions without ever solving the MIP relaxation. It
can often be quite effective, although of course it won't provide good
lower bounds on the optimal objective.
Heuristics
A few Gurobi parameters control internal MIP strategies. The
Heuristics parameter controls the fraction of runtime spent on
feasibility heuristics. Increasing the parameter can lead to more and
better feasible solutions, but it will also reduce the rate of
progress in the best bound. The SubMIPNodes parameter
controls the number of nodes explored in some of the more
sophisticated local search heuristics inside the Gurobi solver. You
can increase this if you are having trouble finding good feasible
solutions. The MinRelNodes, PumpPasses, and
ZeroObjNodes parameters control a set of expensive heuristics
whose goal is to find a feasible solution. All are invoked at the end
of the MIP root node and usually only if no feasible solution has been found
already. Try these if you are having trouble finding any feasible
solutions.
Cutting Planes
The Gurobi MIP solver employs a wide range of cutting plane
strategies. The aggressiveness of these strategies can be controlled
at a coarse level through the Cuts parameter, and at a finer
grain through a further set of cuts parameters (e.g.,
FlowCoverCuts, MIRCuts, etc.). Each cut parameter can be
set to Aggressive (2), Conservative (1), Automatic (-1), or None (0).
The more specific parameters override the more general, so for example
setting MIRCuts to None (0) while also setting Cuts to
Aggressive (2) would aggressively generate all cut types, except MIR
cuts which would not be generated at all. Very easy models can sometimes
benefit from turning cuts off, while extremely difficult models can
benefit from turning them to their Aggressive setting.
Presolve
Presolve behavior can be modified with a set of parameters. The
Presolve parameter sets the aggressiveness level of presolve.
Options are Aggressive (2), Conservative (1), Automatic (-1), or None
(0). More aggressive application of presolve takes more time, but can
sometimes lead to a significantly tighter model. The
PrePasses provides finer-grain control of presolve. It limits
the number of passes presolve performs. Setting it to a small value
(e.g., 3) can reduce presolve runtime. The Aggregate
parameter controls the aggregation level in presolve.
Aggregation typically leads to a smaller formulation, but in rare
cases it can introduce numerical issues. The AggFill
parameter controls aggregation at a finer grain. It controls how much
fill is tolerated in the constraint matrix from a single variable
aggregation. The PreSparsify parameter enables an algorithm
that can sometimes significantly reduce the number of non-zero values
in the constraint matrix.
Coping with Integrality Violations
The MIP solver can sometimes exploit tolerances on integer variables
to violate the intent of a constraint. The best-known example of this
is probably trickle flows, where trivial integrality violations on
fixed-charge (binary) variables can lead to solutions that allow
significant flows down closed edges.
The IntegralityFocus parameter allows you to tell the solver to
take a much stricter approach to integrality (at a small performance
penalty).
Additional Parameters
The Symmetry parameter controls symmetry detection. The
default value usually works well. The VarBranch parameter
controls the branching variable selection strategy within the
branch-and-bound process. Variable selection can have a significant
impact on overall time to solution, but the default strategy is
usually the best choice.
Tolerances
The Gurobi solver includes a set of numerical tolerance parameters.
These rarely require adjustment, and are included for advanced users
who are having trouble with the numerical properties of their models.
The FeasibilityTol, IntFeasTol, MarkowitzTol,
and OptimalityTol parameters allow you to adjust the primal
feasibility tolerance, the integer feasibility tolerance, the
Markowitz tolerance for simplex basis factorization, and the dual
feasibility tolerance, respectively.
