Warm Start Options#
Warm starting is a technique to provide initial solution information, e.g., from a previously computed solution or a heuristic guess, in order to accelerate the solve of an optimization problem. Instead of starting from scratch, the solver uses this information. This can reduce setup time, improve convergence behavior, or decrease the number of iterations needed to reach optimality.
Warm starting is particularly effective when solving a sequence of similar models (e.g., rolling-horizon) or re-optimizing a model after small updates (e.g., column generation).
Gurobi will reuse available solution information (basis, incumbent,
etc.) after a model object is modified, provided the model object is not
set to an unsolved state via a reset call, and the modification does
not invalidate the stored information. When this reuse happens, no
manual setting is needed to provide solution information. An example
that demonstrates this behavior for each supported API can be found
here.
Therefore, the easiest way to fully benefit from warm start is to use the same model object whenever possible, e.g., when modeling a rolling horizon planning or reoptimizing after model modifications such as adjusting variables bounds, objective coefficients, rhs values, or adding constraints.
If the solution information does not come from a previous solve or it needs to be adapted to a new model object, Gurobi provides attributes to capture this information. The relevant attributes are stated in the table below, associated with the problem type and the relevant algorithm. Additional details are given in the respective subsections below.
Problem Type |
Remarks |
Relevant Attributes |
|---|---|---|
LP and convex QP |
warm start Simplex with a starting basis (preferred) or start vectors (alternatively) |
|
convex QCP |
solved with barrier only; no warm start options |
- |
non-convex QP / QCP |
solved as a MIP; feasible solution can be provided |
|
MIP / MIQCP |
primal / feasible solution (MIP start) |
Gurobi does not support warm starting the barrier method. However, a crossover phase typically follows barrier to convert the barrier solution (a pair of primal/dual vectors) into a basic feasible solution, and that phase may start from a primal/dual vectors pair that you provide. See Warmstarting Simplex for Continuous Problems below for more details.
There are no warm start options for the Network Simplex (parameter NetworkAlg =1).
For mixed-integer models, warm starting means providing an initial solution, called a MIP start, to the branch-and-bound algorithm. This feature is more common and easier to use than basis- or vector-based warm starts for the Simplex method in continuous models. Non-convex QP and QCP models are solved as MIPs, and feasible solutions can also be provided as a MIP start. For more details, see Providing a Feasible Solution (MIP Start).
Providing a Feasible Solution (MIP Start)#
Each problem that is solved as a MIP via branch-and-bound can be provided with a candidate primal solution, also called a MIP start. MIP starts can be useful if you already know a good quality solution for your problem or if Gurobi struggles to find a feasible solution.
Usage#
You can provide a candidate solution (MIP start) by setting the attribute Start. It can also be loaded from a file - a MIP start file (MST) or a solution file (SOL).
If the solution defined by the values you provide is feasible, it is accepted immediately and the Gurobi log reports the objective value, for example,
Loaded user MIP start with objective 340
If it is infeasible, Gurobi will attempt to repair it. When it succeeds, it prints one or more lines such as
User MIP start produced solution with objective 0
In case it was not possible to get a solution from the start-values, the MIP start is discarded and you can find the following line in the Gurobi log:
User MIP start did not produce a new incumbent solution
Additional features:
Partial MIP starts: If you only have information about the solution values for a subset of variables, you can provide a partial MIP start, one that defines Start values only for a subset of the (integer) variables. Gurobi will try to complete the partial solution. The parameter StartNodeLimit controls the number of branch-and-bound nodes explored when trying to complete a partial MIP start.
Multiple MIP starts: If you have multiple start vectors, you can provide them to Gurobi by using the
Startattribute in combination with the NumStart attribute and the StartNumber parameter. Specifically, use theNumStartattribute to indicate how many start vectors you will supply. Then set the StartNumber parameter to a value between 0 andNumStart-1 to indicate which start you are supplying. For each value of StartNumber, populate theStartattribute to supply that start. Gurobi will use all of the provided starts. As an alternative, you can append new MIP start vectors to your model by setting the StartNumber parameter to-1. In this case, whenever you read a MIP start, or use a function to set a MIP start value for a set of variables, a new MIP start will be created, the attribute NumStart will be increased, and any unspecified variable will be left asundefined.
Best Practices#
Focus on integer variables: For typical MIP models, it is often sufficient (and recommended) to provide values only for integer and binary variables and let Gurobi compute the remaining continuous variables.
Quality matters: Poor-quality or highly infeasible starts can slow down the solver, especially if significant effort is spent trying to repair them.
Be careful with partial starts: Completing a partial MIP start requires solving subproblems and can be computationally expensive.
If you solve a sequence of models, where one is built by modifying the previous one, and if you don’t provide a MIP start, then Gurobi will try to construct one automatically from the solution of the previous model. If you don’t want it to try this, you should reset the model before starting the subsequent solve. If you provided a MIP start but would prefer to use the previous solution as the start instead, you should clear your start (by setting the Start attribute to
undefinedfor all variables).If the Gurobi MIP solver log indicates that your MIP start didn’t produce a new incumbent solution, note that there can be multiple explanations. One possibility is that your MIP start is infeasible. Another common possibility is that one of the Gurobi heuristics found a solution that is as good as the solution produced by the MIP start, so the MIP start solution was cut off. Finally, if you specified a partial MIP start, it is possible that the limited MIP exploration done on this partial start was insufficient to find a new incumbent solution. You can try setting the StartNodeLimit parameter to a larger value if you want Gurobi to work harder to try to complete the partial start.
If you want to diagnose an infeasible MIP start, you can try fixing the variables in the model to their values in your MIP start (by setting their lower and upper bound attributes). If the resulting MIP model is infeasible, you can then compute an IIS on this model to get additional information that should help to identify the cause of the infeasibility.
Variable Hints (Heuristic Guidance)#
A related but different option is variable hints. These values guide the solver throughout the solution process. If you know that a variable is likely to have a particular value in the solution but you cannot define all variable values so that the corresponding solution is feasible, you can set the attribute VarHintVal to help Gurobi find a solution. You can also provide information about your level of confidence in a hint with the VarHintPri attribute.
The Gurobi MIP solver will use these variable hints in a number of different ways. Hints will affect the heuristics that Gurobi uses to find feasible solutions, and the branching decisions that Gurobi makes to explore the MIP search tree. In general, high quality hints should produce high quality MIP solutions faster. In contrast, low quality hints will lead to some wasted effort, but shouldn’t lead to dramatic performance degradations.
Variables hints and MIP Starts are similar in concept, but they behave in very different ways. If you specify a MIP start, the Gurobi MIP solver will try to build a single feasible solution from the provided set of variable values. If you know a solution, you should use a MIP start to provide it to the solver. In contrast, variable hints provide guidance to the MIP solver that affects the entire solution process. If you have a general sense of the likely values for variables, you should provide them through variable hints.
Warmstarting Simplex for Continuous Problems#
Gurobi efficiently re-optimizes a model after modifications. So, the best and recommended option is to re-use the same model object whenever possible. But if you need to initiate a warm start from “external” information to efficiently solve your model, this section provides guidance.
Usage#
The simplex algorithm can be warm started by providing either a simplex basis or primal and dual vectors of solution values. Providing a simplex basis typically results in better performance because the Gurobi Optimizer doesn’t need to perform additional iterations to construct a basis from the given start vector(s).
Simplex Basis#
Simplex can be efficiently warm-started by providing a basis. You can define the basis status for each variable (basic, non-basic at lower bound, non-basic at upper bound) via the attribute VBasis and information on whether a constraint is basic or non-basic (active and not active) via the attribute CBasis. Gurobi then initializes the simplex algorithm from this basis.
If the basis information is complete and feasible, you can find the following line in the Gurobi log:
LP warm-start: use basis
Basis information can be stored as a BAS file and also be read from such a file.
Primal and Dual Solution Values#
An alternative is setting a start vector. You can set the initial values for primal variables (variables in your model) and the initial values for the dual variables (associated with constraints) through the variable and constraint attributes PStart and DStart.
If you provide both a primal and a dual start vector, then crossover will be used to construct a basis from them. If you only have primal values, an PStart vector, you can set the Method parameter to 0 to use the primal simplex algorithm. Conversely, if you only have dual values, you can set DStart and select the dual simplex algorithm by setting Method=1.
If a complete start vector is provided, you can find the following line in the Gurobi log:
LP warm-start: use start vectors
Best Practices#
Prefer basis information: Providing a valid simplex basis is typically more efficient than start vectors, since it avoids the need to construct a basis internally.
Ensure completeness and correctness: Both basis information and start vectors must be fully specified. Partial inputs are ignored. The basis must be valid, e.g., number of basics must equal the number of rows. Make also sure that the basis is not singular. Ideally the provided basis is primal or dual feasible.
Be cautious with poor start vectors: Start vectors far from feasibility can degrade performance, because Gurobi first needs to build a valid basis.
Consider presolve interaction: Providing basis or start vectors disables LP presolve by default, since presolve may change the model structure and invalidate the warm start. This might hurt performance when presolve greatly reduces the problem size. The relationship between warm start and presolve can be controlled with the parameter LPWarmStart.
Gurobi discards warm start information if you modify the model after reading a basis or setting warm start attributes. To use warm start, you must follow the following sequence: