Parameter Guidelines#
This section provides a brief discussion of the roles of the various Gurobi parameters when solving continuous or MIP models, with some indication of their relative importance.
Note that you also have the option of using the Parameter Tuning Tool to tune parameters. We recommend that you browse this section, though, even if you use the tuning tool, to get a better understanding of the roles of the various parameters.
Continuous Models#
If you wish to use Gurobi parameters to tune performance on continuous models, we offer the following guidelines.
Choosing the method for LP or QP#
The most important parameter when solving an LP or QP is Method. The default setting (-1) uses the concurrent optimizer for an LP, and the parallel barrier solver for a QP. While the default is usually a good choice, you may want to choose a different method in a few situations.
If memory is tight, you should consider using the dual simplex method (Method=1) instead of the default. The default will invoke the barrier method, which can take a lot more memory than dual. In addition, the default for LP will try multiple algorithms simultaneously, and each requires a copy of the original model. By selecting dual simplex, you will only use one copy of the model.
Another scenario where you should change the default is when you must get the exact same optimal basis each time. For LP models, the default concurrent solver invokes multiple algorithms simultaneously on multi-core systems, returning the optimal basis from the one that finishes first. In rare cases, one algorithm may complete first in one run, while another completes first in another. This can potentially lead to different alternate optimal solutions. Selecting any other method, including the deterministic concurrent solver, will avoid this possibility. Note, however, that the deterministic concurrent solver can be significantly slower than the default concurrent solver.
Finally, if you are confronted with a difficult LP model, you should experiment with the different method options. While the default is rarely significantly slower than the best choice, you may find that one option is consistently faster or more robust for your models. There are no simple rules for predicting which method will work best for a particular family of models.
If you are solving QCP or SOCP models, note that the barrier algorithm is your only option.
Parallel solution#
Among the remaining parameters that affect continuous models, the only one that you would typically want to adjust is Threads, which controls the number of threads used for the concurrent and parallel barrier algorithms. By default, concurrent and barrier will use all available cores in your machine (up to 32). Note that the simplex solvers can only use one thread, so this parameter has no effect on them.
If you would like to experiment with different strategies than the
default ones when solving an LP model using the concurrent optimizer, we
provide methods in C,
C++,
Java,
.NET, and
Python that allow you to create and
configure concurrent environments.
Infeasible or unbounded models#
If you are confronted with an infeasible or unbounded LP, additional details can be obtained when you set the InfUnbdInfo parameter. For an unbounded model, setting this parameter allows you to retrieve an unbounded ray (using the UnbdRay attribute). For an infeasible model, setting this parameter allows you to retrieve a Farkas infeasibility proof (using the FarkasDual and FarkasProof attributes).
For the barrier algorithm, you should set the BarHomogeneous parameter to 1 whenever you have a model that you suspect is infeasible or unbounded. This algorithm is better at diagnosing infeasibility or unboundedness.
Special structure#
If you wish to solve an LP model that has many more variables than constraints, you may want to try the sifting algorithm. Sifting is actually implemented within our dual simplex solver, so to select sifting, set the Method parameter to 1 (to select dual), and then set the Sifting parameter to a positive value. You can use the SiftMethod parameter to choose the algorithm that is used to solve the sub-problems that arise within the sifting algorithm. In general, sifting is only effective when the ratio between variables and constraints is extremely large (100 to 1 or more). Note that the default Sifting setting allows the Gurobi Optimizer to select sifting automatically when a problem has the appropriate structure, so you won’t typically need to select it manually.
Additional parameters#
The ScaleFlag parameter can be used to modify the scaling performed on the model. The default scaling value (-1) is usually the most effective choice, but turning off scaling entirely (0) can sometimes reduce constraint violations on the original model. Choosing a different scaling option (1, 2, or 3) can sometimes improve performance for particularly numerically difficult models. The ObjScale parameter allows you to scale just the objective. Objective scaling can be useful when the objective contains extremely large values, but it can also lead to large dual violations in the original, unscaled model, so it should be used sparingly.
The SimplexPricing parameter determines the method used to choose a simplex pivot. The default is usually the best choice. The NormAdjust parameter allows you to choose alternate simplex pricing norms. Again, the default is usually best. The Quad parameter allows you to force the simplex solver to use (or not use) quad precision. While quad precision can help for numerically difficult models, the default setting will typically recognize such cases automatically. The PerturbValue parameter allows you to adjust the magnitude of the simplex perturbation (used to overcome degeneracy). Again, the default value is typically effective.
Other Gurobi parameters control the details of the barrier solver. The BarConvTol and BarQCPConvTol parameters allow you to adjust barrier termination. While you can ask for more precision than the default, you will typically run into the limitations of double-precision arithmetic quite quickly. This parameter is typically used to indicate that you are willing to settle for a less accurate answer than the defaults would give. The BarCorrectors parameter allows you to adjust the number of central corrections applied in each barrier iteration. More corrections generally lead to more forward progress in each iteration, but at a cost of more expensive iterations. The BarOrder parameter allows you to choose the barrier ordering method. The default approach typically works well, but you can manually choose the less expensive Approximate Minimum Degree ordering option (BarOrder=0) if you find that ordering is taking too long.
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 MEM_LIMIT 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.