Parameter Groups#
To provide some guidance on this page, we have classified the parameters into a number of categories. Some parameters are part of multiple categories. Those categories are:
Termination parameters which set the stopping conditions for algorithms;
Tolerance parameters which control solution quality requirements;
Logging and I/O parameters which control logging behavior as well as input and output files;
Algorithmic control parameters for Presolve, Simplex, Barrier, Scaling, MIP, MIP Cuts, and Numerics;
Tuning parameters which control parameter tuning strategies for
grbtune
and thetune
API calls;Solution Pool parameters which control how the solver searches for and stores additional solutions other than the best available one;
Multi-Objective parameters which control some aspects when working with multiple objectives;
Parameters for configuring aspects of remote optimization and licensing: Parallel and Distributed Computing, Instant Cloud, Compute Server, Cluster Manager, Token Server, Web License Service; and
Other parameters that do not fit directly into one of the other categories.
The tables below link to the full detail of each parameter’s effect in the Parameter Reference section.
Termination#
These parameters affect the termination of the algorithms. If the algorithm exceeds any of these limits, it will terminate and report a non-optimal termination status (see the Status Code section for further details). Note that the algorithm won’t necessarily stop the moment it hits the specified limit. The termination check may occur well after the limit has been exceeded.
Parameter name |
Purpose |
---|---|
Barrier iteration limit |
|
Best objective bound to stop |
|
Best objective value to stop |
|
Objective cutoff |
|
Simplex iteration limit |
|
Memory limit |
|
MIP node limit |
|
Soft memory limit |
|
MIP feasible solution limit |
|
Time limit |
|
Work limit |
A few termination parameters can be modified from a callback with the corresponding callback methods. Those are: TimeLimit, WorkLimit, NodeLimit, and BarIterLimit. This makes it easier to implement custom termination criteria that, for example, set a time limit based on dynamic solving process data like the current incumbent objective value.
Tolerances#
These parameters control the allowable feasibility or optimality violations.
Parameter name |
Purpose |
---|---|
Barrier convergence tolerance |
|
Barrier QCP convergence tolerance |
|
Primal feasibility tolerance |
|
Integer feasibility tolerance |
|
Threshold pivoting tolerance |
|
Relative MIP optimality gap |
|
Absolute MIP optimality gap |
|
Dual feasibility tolerance |
|
Positive semi-definite tolerance |
Logging#
These parameters control the logging information.
Parameter name |
Purpose |
---|---|
Controls logging for Compute Server and the Web License Service (WLS) |
|
Frequency at which log lines are printed |
|
Log file name |
|
Console logging |
|
Solver output control |
I/O#
These parameters can be used to read or write information.
Parameter name |
Purpose |
---|---|
File to be read before optimization commences |
|
Controls the level of detail stored in generated JSON solution |
|
Enable API call recording |
|
Result file written upon completion of optimization |
|
Location to store intermediate solution files |
Presolve#
These parameters control the operation of the presolve algorithms.
Parameter name |
Purpose |
---|---|
Allowed fill during presolve aggregation |
|
Presolve aggregation control |
|
Disables dual reductions in presolve |
|
Allows presolve to translate constraints on the original model to equivalent constraints on the presolved model |
|
Presolve dependent row reduction |
|
Presolve dualization |
|
Format of presolved MIQCP model |
|
Presolve pass limit |
|
Presolve Q matrix linearization |
|
Presolve level |
|
Controls largest coefficient in SOS1 reformulation |
|
Controls SOS1 reformulation |
|
Controls largest coefficient in SOS2 reformulation |
|
Controls SOS2 reformulation |
|
Presolve sparsify reduction |
Simplex#
These parameters control the operation of the simplex algorithms.
Parameter name |
Purpose |
---|---|
Generate additional info for infeasible/unbounded models |
|
Simplex iteration limit |
|
Warm start usage in simplex |
|
Define method, e.g., Simplex, to solve continuous models |
|
Network simplex algorithm |
|
Simplex pricing norm |
|
Simplex perturbation magnitude |
|
Quad precision computation in simplex |
|
Sifting within dual simplex |
|
LP method used to solve sifting sub-problems |
|
Simplex variable pricing strategy |
Barrier#
These parameters control the operation of the barrier solver.
Parameter name |
Purpose |
---|---|
Barrier convergence tolerance |
|
Central correction limit |
|
Barrier homogeneous algorithm |
|
Barrier iteration limit |
|
Barrier ordering algorithm |
|
Barrier QCP convergence tolerance |
|
Barrier crossover strategy |
|
Crossover initial basis construction strategy |
|
Define method, e.g., Barrier, to solve continuous models |
|
Compute dual variables for QCP models |
Scaling#
These parameters control the operation of the simplex algorithms and the barrier solver.
MIP#
These parameters control the operation of the MIP algorithms.
Parameter name |
Purpose |
---|---|
Branch direction preference |
|
Enables distributed concurrent solver |
|
Chooses continuous solvers to run concurrently |
|
Enables concurrent MIP solver |
|
Create concurrent environments from a list of .prm files |
|
Degenerate simplex moves |
|
Disconnected component strategy |
|
Enables the distributed MIP solver |
|
Turn MIP heuristics up or down |
|
Trigger solution improvement |
|
Trigger solution improvement |
|
Trigger solution improvement |
|
Set the integrality focus |
|
Programs that add lazy constraints must set this parameter |
|
Minimum relaxation heuristic control |
|
Set the focus of the MIP solver |
|
Method used to solve MIQCP models |
|
Controls the NLP heuristic for non-convex quadratic models |
|
Directory for MIP node files |
|
Memory threshold for writing MIP tree nodes to disk |
|
MIP node limit |
|
Method used to solve MIP node relaxations |
|
Control how to deal with non-convex quadratic programs |
|
Limits the amount of time (in seconds) spent in the NoRel heuristic |
|
Limits the amount of work performed by the NoRel heuristic |
|
Controls aggressiveness of optimality-based bound tightening |
|
Controls when the partition heuristic runs |
|
Feasibility pump heuristic control |
|
RINS heuristic |
|
Location to store intermediate solution files |
|
MIP feasible solution limit |
|
Sub-optimal MIP solution retrieval |
|
Node limit for MIP start sub-MIP |
|
Set index of MIP start |
|
Nodes explored by sub-MIP heuristics |
|
Symmetry detection |
|
Branch variable selection strategy |
|
Zero objective heuristic control |
The PumpPasses parameter can be modified from a callback with the corresponding callback methods.
MIP Cuts#
These parameters affect the generation of MIP cutting planes. In all cases, a value of -1 corresponds to an automatic setting, which allows the solver to determine the appropriate level of aggressiveness in the cut generation. Unless otherwise noted, settings of 0, 1, and 2 correspond to no cut generation, conservative cut generation, or aggressive cut generation, respectively. The Cuts parameter provides global cut control, affecting the generation of all cuts. This parameter also has a setting of 3, which corresponds to very aggressive cut generation. The other parameters override the global Cuts parameter (so setting Cuts to 2 and CliqueCuts to 0 would generate all cut types aggressively, except clique cuts which would not be generated at all).
Parameter name |
Purpose |
---|---|
BQP cut generation |
|
Global cut generation control |
|
Clique cut generation |
|
Cover cut generation |
|
Constraint aggregation passes performed during cut generation |
|
Root cutting plane pass limit |
|
Dual implied bound cut generation |
|
Flow cover cut generation |
|
Flow path cut generation |
|
Root Gomory cut pass limit |
|
GUB cover cut generation |
|
Implied bound cut generation |
|
Infeasibility proof cut generation |
|
Lift-and-project cut generation |
|
MIP separation cut generation |
|
MIR cut generation |
|
Mixing cut generation |
|
Mod-k cut generation |
|
Network cut generation |
|
Projected implied bound cut generation |
|
PSD cut generation |
|
Relax-and-lift cut generation |
|
RLT cut generation |
|
Strong-CG cut generation |
|
Sub-MIP cut generation |
|
Zero-half cut generation |
Numerics#
These parameters can help to handle numerically challenging problems.
Parameter name |
Purpose |
---|---|
Barrier homogeneous algorithm |
|
Set the integrality focus |
|
Set the numerical focus |
Tuning#
These parameters control the operation of the parameter tuning tool.
Parameter name |
Purpose |
---|---|
Comma-separated list of base parameter settings |
|
Enables a tuning cleanup phase |
|
Specify tuning criterion |
|
Enables distributed tuning using a dynamic set of workers |
|
Enables distributed tuning using a static set of workers |
|
Metric to aggregate results into a single measure |
|
Tuning output level |
|
Comma-separated list of JSON files defining the parameters to be considered for tuning |
|
Number of improved parameter sets returned |
|
A target gap to be reached |
|
A target runtime in seconds to be reached |
|
Time limit for tuning |
|
Perform multiple runs on each parameter set to limit the effect of random noise |
|
Use model file names as model names |
Multiple Solutions#
These parameters allow you to modify the behavior of the MIP search in order to find more than one solution to a MIP model.
Parameter name |
Purpose |
---|---|
Relative gap for solutions in pool |
|
Absolute gap for solutions in pool |
|
Choose the approach used to find additional solutions |
|
Number of solutions to keep in pool |
Multiple Objectives#
These parameters can be relevant when working with multiple objectives.
Parameter name |
Purpose |
---|---|
Warm-start method to solve for subsequent objectives |
|
Initial presolve on multi-objective models |
|
Create multi-objective settings from a list of .prm files |
|
Set index of multi-objectives |
Parallel and Distributed Computing#
Parameters that are used to control the number of threads and our distributed parallel algorithms (distributed MIP, distributed concurrent, and distributed tuning).
Parameter name |
Purpose |
---|---|
Enables distributed concurrent solver |
|
Enables concurrent MIP solver |
|
Create concurrent environments from a list of .prm files |
|
Enables the distributed MIP solver |
|
Number of parallel threads to use |
|
Specifies a thread limit when starting an environment |
|
Enables distributed tuning |
|
Password for distributed worker cluster |
|
Distributed worker cluster |
Instant Cloud#
Parameters that are used to launch Gurobi Instant Cloud instances.
Parameter name |
Purpose |
---|---|
Access ID for Gurobi Instant Cloud |
|
Host for the Gurobi Cloud entry point |
|
Secret Key for Gurobi Instant Cloud |
|
Cloud pool to use for Gurobi Instant Cloud instance |
Compute Server#
Parameters that are used to configure and launch Gurobi Compute Server jobs. You will normally set these in your license file, but you have the option of setting them through these parameters instead (by first constructing an empty environment). Refer to the Gurobi Remote Services Reference Manual for more information.
Parameter name |
Purpose |
---|---|
Name of a node in the Remote Services cluster |
|
Controls logging |
|
Job priority for Remote Services job |
|
Queue timeout for new jobs |
|
Router node for Remote Services cluster |
|
Group placement request for cluster |
|
Idle time before Compute Server kills a job |
|
Use insecure mode in Transport Layer Security (TLS) |
|
Job ID of current job |
|
Client password for Remote Services cluster (or token server) |
|
Network timeout interval |
Cluster Manager#
Parameters that are used to configure and launch Gurobi Cluster Manager. You will normally set these in your license file, but you have the option of setting them through these parameters instead (by first constructing an empty environment). Refer to the Gurobi Remote Services Reference Manual for more information.
Parameter name |
Purpose |
---|---|
Access ID for Gurobi Cluster Manager |
|
Secret key for Gurobi Cluster Manager |
|
Application name of the batches or jobs |
|
Token used internally for authentication |
|
Controls Batch-Mode optimization |
|
Controls logging |
|
URL for the Cluster Manager |
|
User name to use when connecting to the Cluster Manager |
Token Server#
Parameters that are used to launch jobs that check out tokens from a token server. You will normally set these in your license file, but you have the option of setting them through these parameters instead (by first constructing an empty environment).
Parameter name |
Purpose |
---|---|
Client password for token server (or Remote Services cluster) |
|
Name of your token server |
|
Token server port number |
Web License Service#
Parameters that are used to launch jobs that use the Web License Service (WLS). You will normally set these in your license file, but you have the option of setting them through these parameters instead (by first constructing an empty environment).
Parameter name |
Purpose |
---|---|
Controls logging |
|
License ID |
|
WLS access ID |
|
WLS secret |
|
WLS token |
|
WLS token duration |
|
Relative WLS token refresh interval |
Other#
Other parameters.
Parameter name |
Purpose |
---|---|
Big-M value for feasibility relaxations |
|
Error allowed for PWL translation of function constraint |
|
Piece length for PWL translation of function constraint |
|
Controls whether to under- or over-estimate function values in PWL approximation |
|
Sets strategy for PWL function approximation |
|
Maximum value for x and y variables in function constraints |
|
Chooses the approximation approach used to handle function constraints |
|
Indicates whether to ignore names provided by users |
|
IIS method |
|
Set index of scenario in multi-scenario models |
|
Modify the random number seed |
|
Specify the solution target for LP |
|
Change the behavior of lazy updates |
Callback settable parameters
A few parameters can be modified from within a callback with the corresponding callback methods. This makes it easier to implement custom termination criteria that, for example, set a time limit based on dynamic solving process data like the current incumbent objective value. How to do that for the different APIs is illustrated here.
Note
In case of a remote server, the change of a parameter from within a callback may not be taken into account immediately.
Parameter name |
Purpose |
---|---|
Barrier iteration limit |
|
MIP node limit |
|
Feasibility pump heuristic control |
|
Time limit |
|
Work limit |