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
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.
Among the remaining parameters that affect continuous models, the only
one that you would typically want to adjust is
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
parameter. For an unbounded model, setting this parameter allows you
to retrieve an unbounded ray (using the
For an infeasible model, setting this parameter allows you to retrieve
a Farkas infeasibility proof (using the
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.
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
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
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
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.
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
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.
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
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.