# MIP Models

### 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 specified 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`

parameter. If the total amount of memory that Gurobi tries to allocate
exceeds this value (in GBytes), it will abort and return a
`OUT_OF_MEMORY`

error. Note that the `MemLimit`

parameter
can only be set in the master environment, and it has to be set before
the environment is started.

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