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 to solve the model. The default is to use all
cores in the machine. 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. Another common termination choice for MIP models is to set
the MIPGap parameter. The MIPGap 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.
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).
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, but 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. 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 whether presolve performs constraint aggregation.
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 nonzero values
in the constraint matrix.
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.
