Whiledefault settings generally work well, MIP models will oftenbenefit from parameter tuning. We offer the following guidelines,but we also encourage you to experiment.Most Important ParametersThe two most important Gurobi settings when solving a MIP model areprobably the Threads and MIPFocus parameters. TheThreads parameter controls the number of threads used by theparallel 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-levelsolution strategy, depending on your goals. By default, the GurobiMIP solver strikes a balance between finding new feasible solutionsand proving that the current solution is optimal. If you are moreinterested in good quality feasible solutions, you can selectMIPFocus=1. If you believe the solver is having no troublefinding the optimal solution, and wish to focus more attention onproving optimality, select MIPFocus=2. If the best objectivebound is moving very slowly (or not at all), you may want to tryMIPFocus=3 to focus on the bound.Solution ImprovementThe ImproveStartTime and ImproveStartGap parameterscan also be used to modify your high-level solution strategy, but in adifferent way. These parameters allow you to give up on provingoptimality at a certain point in the search, and instead focus allattention on finding better feasible solutions from that point onward.The ImproveStartTime parameter allows you to make thistransition after the specified time has elapsed, while theImproveStartGap parameter makes the transition when thespecified optimality gap has been achieved.TerminationAnother important set of Gurobi parameters affect solver termination.If the solver is unable to find a proven optimal solution within thedesired time, you will need to indicate how to limit the search. Thesimplest option is to limit runtime using the TimeLimitparameter. Of course, using a wall-clock based time limit may lead tonon-deterministic results. This means that performing the sameoptimization twice with exactly the same input data can lead tostopping at different points during the optimization process and thusproducing different solver output. If a deterministic stoppingcriterion is desired, one may use the WorkLimit parameterinstead. This specifies a limit on the total work that is spent onthe optimization. One work unit corresponds very roughly to onesecond, but this greatly depends on the hardware on which Gurobi isrunning and on the model that has been solved.Another common termination choice for MIP models is to setthe MIPGap parameter. This parameter allows you to indicatethat optimization should stop when the relative gap between the bestknown solution and the best known bound on the solution objective isless than the specified value. You can terminate when the absolutegap is below a desired threshold using the MIPGapAbs parameter.You can also terminate based strictly on the current lower or upperbound using the BestBdStop or BestObjStop parameters.Other termination optionsinclude NodeLimit, IterationLimit,SolutionLimit, and Cutoff. The first three indicatethat optimization should terminate when the number of branch-and-boundnodes, the total number of simplex iterations, or the number ofdiscovered feasible integer solutions exceeds the specified value,respectively. The Cutoff parameter indicates that the solvershould only consider solutions whose objective values are better thanthe specified value, and should terminate if no such solutions arefound.Reducing Memory UsageIf you find that the Gurobi Optimizer exhausts memory when solving aMIP, you should modify the NodefileStart parameter. When theamount of memory used to store nodes (measured in GBytes) exceeds thespecified parameter value, nodes are written to disk. We recommend asetting of 0.5, but you may wish to choose a different value,depending on the memory available in your machine. By default, nodesare written to the current working directory. The NodefileDirparameter can be used to choose a different location.If you still exhaust memory after setting the NodefileStartparameter to a small value, you should try limiting the thread count.Each thread in parallel MIP requires a copy of the model, as well asseveral other large data structures. Reducing the Threadsparameter can sometimes significantly reduce memory usage.Finally, to protect against exhausting the memory you can limit thememory that is available to Gurobi by setting the MemLimit orthe SoftMemLimit parameters. If the total amount of memory thatGurobi tries to allocate exceeds this value (in GBytes), it willabort. In case of the MemLimit parameter, Gurobi will abortimmediately with anOUT_OF_MEMORY error. In contrast, the SoftMemLimitmay be overshot a little bit, but instead of returning an error itallows a graceful termination of the current optimization witha MEMLIMIT status code.Speeding Up The Root RelaxationThe root relaxation in a MIP model can sometimes be quite expensive tosolve. If you find that a lot of time is spent here, consider usingthe Method parameter to select a different continuous algorithmfor the root. For example, Method=2 would select the parallelbarrier algorithm at the root, and Method=3 would select theconcurrent solver. Note that you can choose a different algorithm forthe MIP node relaxations using the NodeMethod parameter, but itis rarely beneficial to change this from the default (dual simplex).Difficult RelaxationsIf you find that the solver is having trouble solving the rootrelaxation even after you have tried the recommendations above, or isspending an inordinate amount of time at the root node, you should trythe NoRel heuristic (controlled by the NoRelHeurTimeand NoRelHeurWork parameters). This heuristic attempts to findhigh-quality solutions without ever solving the MIP relaxation. Itcan often be quite effective, although of course it won't provide goodlower bounds on the optimal objective.HeuristicsA few Gurobi parameters control internal MIP strategies. TheHeuristics parameter controls the fraction of runtime spent onfeasibility heuristics. Increasing the parameter can lead to more andbetter feasible solutions, but it will also reduce the rate ofprogress in the best bound. The SubMIPNodes parametercontrols the number of nodes explored in some of the moresophisticated local search heuristics inside the Gurobi solver. Youcan increase this if you are having trouble finding good feasiblesolutions. The MinRelNodes, PumpPasses, andZeroObjNodes parameters control a set of expensive heuristicswhose goal is to find a feasible solution. All are invoked at the endof the MIP root node and usually only if no feasible solution has been foundalready. Try these if you are having trouble finding any feasiblesolutions.Cutting PlanesThe Gurobi MIP solver employs a wide range of cutting planestrategies. The aggressiveness of these strategies can be controlledat a coarse level through the Cuts parameter, and at a finergrain through a further set of cuts parameters (e.g.,FlowCoverCuts, MIRCuts, etc.). Each cut parameter can beset to Aggressive (2), Conservative (1), Automatic (-1), or None (0).The more specific parameters override the more general, so for examplesetting MIRCuts to None (0) while also setting Cuts toAggressive (2) would aggressively generate all cut types, except MIRcuts which would not be generated at all. Very easy models can sometimesbenefit from turning cuts off, while extremely difficult models canbenefit from turning them to their Aggressive setting.PresolvePresolve behavior can be modified with a set of parameters. ThePresolve 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 cansometimes lead to a significantly tighter model. ThePrePasses provides finer-grain control of presolve. It limitsthe number of passes presolve performs. Setting it to a small value(e.g., 3) can reduce presolve runtime. The Aggregateparameter controls the aggregation level in presolve.Aggregation typically leads to a smaller formulation, but in rarecases it can introduce numerical issues. The AggFillparameter controls aggregation at a finer grain. It controls how muchfill is tolerated in the constraint matrix from a single variableaggregation. The PreSparsify parameter enables an algorithmthat can sometimes significantly reduce the number of non-zero valuesin the constraint matrix.Coping with Integrality ViolationsThe MIP solver can sometimes exploit tolerances on integer variablesto violate the intent of a constraint. The best-known example of thisis probably trickle flows, where trivial integrality violations onfixed-charge (binary) variables can lead to solutions that allowsignificant flows down closed edges.The IntegralityFocus parameter allows you to tell the solver totake a much stricter approach to integrality (at a small performancepenalty).Additional ParametersThe Symmetry parameter controls symmetry detection. Thedefault value usually works well. The VarBranch parametercontrols the branching variable selection strategy within thebranch-and-bound process. Variable selection can have a significantimpact on overall time to solution, but the default strategy isusually the best choice.TolerancesThe Gurobi solver includes a set of numerical tolerance parameters.These rarely require adjustment, and are included for advanced userswho are having trouble with the numerical properties of their models.The FeasibilityTol, IntFeasTol, MarkowitzTol,and OptimalityTol parameters allow you to adjust the primalfeasibility tolerance, the integer feasibility tolerance, theMarkowitz tolerance for simplex basis factorization, and the dualfeasibility tolerance, respectively.
Next: Parameter Descriptions Up: Parameter Guidelines Previous: Continuous Models
The Gurobi suite of optimization products include state-of-the-art simplex and parallel barrier solvers for linear programming (LP) and quadratic programming (QP), parallel barrier solver for quadratically constrained programming (QCP), as well as parallel mixed-integer linear programming (MILP), mixed-integer quadratic programming (MIQP), mixed-integer quadratically constrained programming (MIQCP) and (mixed-integer) nonlinear programming (NLP) solvers.
3a8082e126