Filter Content By
Version

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