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. 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.