Variable Attributes#

These are variable attributes, meaning that they are associated with specific variables in the model. You should use one of the various get routines to retrieve the value of an attribute. These are described at the beginning of this section. For the object-oriented interfaces, variable attributes are retrieved by invoking the get method on a variable object. For attributes that can be modified directly by the user, you can use one of the various set methods.

Attempting to query an attribute that is not available will produce an error. In C, the attribute query routine will return a DATA_NOT_AVAILABLE error code. The object-oriented interfaces will throw an exception.

Additional variable attributes can be found in the Multi-objective Attributes and Multi-Scenario Attributes sections.

LB#

  • Type: double

  • Modifiable: Yes

Variable lower bound. Note that any value less than or equal to -1e20 is treated as negative infinity.

For examples of how to query or modify attributes, refer to our Attribute Examples.

UB#

  • Type: double

  • Modifiable: Yes

Variable upper bound. Note that any value greater than or equal to 1e20 is treated as infinite.

For examples of how to query or modify attributes, refer to our Attribute Examples.

Obj#

  • Type: double

  • Modifiable: Yes

Linear objective coefficient. In our object-oriented interfaces, you typically use the setObjective method to set the objective, but this attribute provides an alternative for setting or modifying linear objective terms.

Note that this attribute interacts with our piecewise-linear objective feature. If you set a piecewise-linear objective function for a variable, that will automatically set the Obj attribute to zero. Similarly, if you set the Obj attribute for a variable, that will automatically delete any previously specified piecewise-linear objective.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VarName#

  • Type: string

  • Modifiable: Yes

Variable name.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VTag#

  • Type: string

  • Modifiable: Yes

Tag for variables.

If you will be retrieving the solution to your model in JSON format, you might define a tag for every variable that you plan to retrieve solution information for. Each variable tag must be unique, and if any tag is used (variable tag, constraint tag, quadratic constraint tag) only tagged elements will appear in the JSON solution string. Tags must consist of printable US-ASCII characters. Using extended characters or escaped characters will result in an error. The maximum supported length for a tag is 10240 characters.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VType#

  • Type: char

  • Modifiable: Yes

Variable type ('C' for continuous, 'B' for binary, 'I' for integer, 'S' for semi-continuous, or 'N' for semi-integer). Binary variables must be either 0 or 1. Integer variables can take any integer value between the specified lower and upper bounds. Semi-continuous variables can take any value between the specified lower and upper bounds, or a value of zero. Semi-integer variables can take any integer value between the specified lower and upper bounds, or a value of zero.

Refer to this section for more information on variable types.

For examples of how to query or modify attributes, refer to our Attribute Examples.

X#

  • Type: double

  • Modifiable: No

Variable value in the current solution.

For examples of how to query or modify attributes, refer to our Attribute Examples.

Xn#

  • Type: double

  • Modifiable: No

The variable value in a sub-optimal MIP solution. Use parameter SolutionNumber to indicate which alternate solution to retrieve. Solutions are sorted in order of worsening objective value. Thus, when SolutionNumber is 1, Xn returns the second-best solution found. When SolutionNumber is equal to its default value of 0, querying attribute Xn is equivalent to querying attribute X.

The number of sub-optimal solutions found during the MIP search will depend on the values of a few parameters. The most important of these are PoolSolutions, PoolSearchMode, and PoolGap. Please consult the section on Solution Pools for a more detailed discussion of this topic.

Only available for MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

RC#

  • Type: double

  • Modifiable: No

The reduced cost in the current solution. Only available for convex, continuous models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

BarX#

  • Type: double

  • Modifiable: No

The variable value in the best barrier iterate (before crossover). Only available when the barrier algorithm was selected.

For examples of how to query or modify attributes, refer to our Attribute Examples.

Start#

  • Type: double

  • Modifiable: Yes

The current MIP start vector. The MIP solver will attempt to build an initial solution from this vector when it is available. Note that the start can be partially populated – the MIP solver will attempt to fill in values for missing start values. If you wish to leave the start value for a variable undefined, you can either avoid setting the Start attribute for that variable, or you can set it to a special undefined value (GRB_UNDEFINED in C and C++, or GRB.UNDEFINED in Java, .NET, and Python).

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, more 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 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 undefined for all variables).

If you have multiple start vectors, you can provide them to Gurobi by using the Start attribute in combination with the NumStart attribute and the StartNumber parameter. Specifically, use the NumStart attribute to indicate how many start vectors you will supply. Then set the StartNumber parameter to a value between 0 and NumStart-1 to indicate which start you are supplying. For each value of StartNumber, populate the Start attribute 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 parameter NumStart will be increased, and any unspecified variable will be left as undefined.

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.

Only affects MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VarHintVal#

  • Type: double

  • Modifiable: Yes

A set of user hints. If you know that a variable is likely to take a particular value in high quality solutions of a MIP model, you can provide that value as a hint. You can also (optionally) 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.

If you wish to leave the hint value for a variable undefined, you can either avoid setting the VarHintVal attribute for that variable, or you can set it to a special undefined value (GRB_UNDEFINED in C and C++, GRB.UNDEFINED in Java, .NET, and Python, NA in R or nan in Matlab).

Note that deleting variables from your model will cause several attributes to be discarded (variable hints and branch priorities). If you’d like them to persist, your program will need to repopulate them after deleting the variables and making a subsequent model update call.

Only affects MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VarHintPri#

  • Type: int

  • Modifiable: Yes

Priorities on user hints. After providing variable hints through the VarHintVal attribute, you can optionally also provide hint priorities to give an indication of your level of confidence in your hints.

Hint priorities are relative. If you are more confident in the hint value for one variable than for another, you simply need to set a larger priority value for the more solid hint. The default hint priority for a variable is 0.

Please refer to the VarHintVal discussion for more details on the role of variable hints.

Only affects MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

BranchPriority#

  • Type: int

  • Modifiable: Yes

Variable branching priority. The value of this attribute is used as the primary criterion for selecting a fractional variable for branching during the MIP search. Variables with larger values always take priority over those with smaller values. Ties are broken using the standard branch variable selection criteria. The default variable branch priority value is zero.

Note that deleting variables from your model will cause several attributes to be discarded (variable hints and branch priorities). If you’d like them to persist, your program will need to repopulate them after deleting the variables and making a subsequent model update call.

Only affects MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

Partition#

  • Type: int

  • Modifiable: Yes

Variable partition. The MIP solver can perform a solution improvement heuristic using user-provided partition information. The provided partition number can be positive, which indicates that the variable should be included when the correspondingly numbered sub-MIP is solved, 0 which indicates that the variable should be included in every sub-MIP, or -1 which indicates that the variable should not be included in any sub-MIP. Variables that are not included in the sub-MIP are fixed to their values in the current incumbent solution. By default, all variables start with a value of -1.

To give an example, imagine you are solving a model with 400 variables and you set the partition attribute to -1 for variables 0-99, 0 for variables 100-199, 1 for variables 200-299, and 2 for variables 300-399. The heuristic would solve two sub-MIP models: sub-MIP 1 would fix variables 0-99 and 300-399 to their values in the incumbent and solve for the rest, while sub-MIP 2 would fix variables 0-99 and 200-299.

Use the PartitionPlace parameter to control where the partition heuristic runs.

Only affects MIP models.

For examples of how to query or modify attributes, refer to our Attribute Examples.

VBasis#

  • Type: int

  • Modifiable: Yes

The status of a given variable in the current basis. Possible values are 0 (basic), -1 (non-basic at lower bound), -2 (non-basic at upper bound), and -3 (super-basic). Note that, if you wish to specify an advanced starting basis, you must set basis status information for all constraints and variables in the model. Only available for basic solutions.

Note that if you provide a valid starting extreme point, either through PStart, DStart, or through VBasis, CBasis, then LP presolve will be disabled by default. For models where presolve greatly reduces the problem size, this might hurt performance. For presolve to be enabled, the parameter LPWarmStart must be set to 2.

For examples of how to query or modify attributes, refer to our Attribute Examples.

PStart#

  • Type: double

  • Modifiable: Yes

Primal start vector.

For LP models, this defines the current simplex start vector. If you set PStart values for every variable in the model and DStart values for every constraint, then simplex will use those values to compute a warm start basis. Note that you’ll get much better performance if you warm start your linear program using a simplex basis (using VBasis and CBasis). The PStart attribute should only be used in situations where you don’t have a basis or you don’t want to disable presolve.

For non-convex (MI)QCP and (MI)NLP models, this defines the starting point for certain primal heuristics. If you set PStart values for every variable in the model, then these heuristics will be more likely to converge to feasible points in the vicinity of the given starting point.

For other problem types, the Pstart values will be ignored.

If you’d like to provide a feasible starting solution for MIP, non-convex (MI)QCP, or (MI)NLP models, you should input it using the Start attribute.

Note that any model modifications which are pending or are made after setting PStart (adding variables or constraints, changing coefficients, etc.) will discard the start. You should only set this attribute after you are done modifying your model. If you’d like to retract a previously specified start, set any PStart value to GRB_UNDEFINED.

Note that if you provide a valid starting extreme point, either through PStart, DStart, or through VBasis, CBasis, then LP presolve will be disabled by default. For models where presolve greatly reduces the problem size, this might hurt performance. For presolve to be enabled, the parameter LPWarmStart must be set to 2.

For examples of how to query or modify attributes, refer to our Attribute Examples.

IISLB#

  • Type: int

  • Modifiable: No

For an infeasible model, indicates whether the lower bound participates in the computed Irreducible Inconsistent Subsystem (IIS). Note that the bounds for a binary variable are considered to be implicit in the variable type and will never participate in an IIS.

Only available after you have computed an IIS.

For examples of how to query or modify attributes, refer to our Attribute Examples.

IISLBForce#

  • Type: int

  • Modifiable: Yes

When computing an Irreducible Inconsistent Subsystem (IIS) for an infeasible model, indicates whether the variable lower bound should be included or excluded from the IIS.

The default value of -1 lets the IIS algorithm decide.

If the attribute is set to 0, the bound is not eligible for inclusion in the IIS.

If the attribute is set to 1, the bound is included in the IIS and the IIS algorithm never considers the possibility of removing it.

Note that setting this attribute to 0 may make the resulting subsystem feasible (or consistent), which would then make it impossible to construct an IIS. Trying anyway will result in a IIS_NOT_INFEASIBLE error. Similarly, setting this attribute to 1 may result in an IIS that is not irreducible. More precisely, the system would only be irreducible with respect to the model elements that have force values of -1 or 0.

See the Model.computeIIS documentation for more details.

This attribute is ignored for LPs.

For examples of how to query or modify attributes, refer to our Attribute Examples.

IISUB#

  • Type: int

  • Modifiable: No

For an infeasible model, indicates whether the upper bound participates in the computed Irreducible Inconsistent Subsystem (IIS). Note that the bounds for a binary variable are considered to be implicit in the variable type and will never participate in an IIS.

Only available after you have computed an IIS.

For examples of how to query or modify attributes, refer to our Attribute Examples.

IISUBForce#

  • Type: int

  • Modifiable: Yes

When computing an Irreducible Inconsistent Subsystem (IIS) for an infeasible model, indicates whether the variable upper bound should be included or excluded from the IIS.

The default value of -1 lets the IIS algorithm decide.

If the attribute is set to 0, the bound is not eligible for inclusion in the IIS.

If the attribute is set to 1, the bound is included in the IIS and the IIS algorithm never considers the possibility of removing it.

Note that setting this attribute to 0 may make the resulting subsystem feasible (or consistent), which would then make it impossible to construct an IIS. Trying anyway will result in a IIS_NOT_INFEASIBLE error. Similarly, setting this attribute to 1 may result in an IIS that is not irreducible. More precisely, the system would only be irreducible with respect to the model elements that have force values of -1 or 0.

See the Model.computeIIS documentation for more details.

This attribute is ignored for LPs.

For examples of how to query or modify attributes, refer to our Attribute Examples.

PoolIgnore#

  • Type: int

  • Modifiable: Yes

When solving a MIP model, the Gurobi Optimizer maintains a solution pool that contains the best solutions found during the search. The PoolIgnore attribute allows you to discard some solutions. Specifically, if multiple solutions differ only in variables where PoolIgnore is set to 1, only the solution with the best objective will be kept in the pool. The default value for the attribute is 0, meaning that the variable should be used to distinguish solutions.

This attribute is particularly helpful when used in conjunction with the PoolSearchMode parameter. By identifying variables that do not capture meaningful differences between solutions, you can make sure that the pool contains some interesting variety.

For examples of how to query or modify attributes, refer to our Attribute Examples.

PWLObjCvx#

  • Type: int

  • Modifiable: No

Indicates whether a variable has a convex piecewise-linear objective. Returns 0 if the piecewise-linear objective function on the variable is non-convex. Returns 1 if the function is convex, or if the objective function on the variable is linear.

This attribute is useful for isolating the particular variable that caused a continuous model with a piecewise-linear objective function to become a MIP.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SAObjLow#

  • Type: double

  • Modifiable: No

Objective coefficient sensitivity information: smallest objective coefficient value at which the current optimal basis would remain optimal. Only available for basic solutions.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SAObjUp#

  • Type: double

  • Modifiable: No

Objective coefficient sensitivity information: largest objective coefficient value at which the current optimal basis would remain optimal. Only available for basic solutions.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SALBLow#

  • Type: double

  • Modifiable: No

Lower bound sensitivity information: smallest lower bound value at which the current optimal basis would remain optimal. Only available for basic solutions.

Please note that if the variable is fixed, no sensitivity information is available and the value of this attribute is that of the variable.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SALBUp#

  • Type: double

  • Modifiable: No

Lower bound sensitivity information: largest lower bound value at which the current optimal basis would remain optimal. Only available for basic solutions.

Please note that if the variable is fixed, no sensitivity information is available and the value of this attribute is that of the variable.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SAUBLow#

  • Type: double

  • Modifiable: No

Upper bound sensitivity information: smallest upper bound value at which the current optimal basis would remain optimal. Only available for basic solutions.

Please note that if the variable is fixed, no sensitivity information is available and the value of this attribute is that of the variable.

For examples of how to query or modify attributes, refer to our Attribute Examples.

SAUBUp#

  • Type: double

  • Modifiable: No

Upper bound sensitivity information: largest upper bound value at which the current optimal basis would remain optimal. Only available for basic solutions.

Please note that if the variable is fixed, no sensitivity information is available and the value of this attribute is that of the variable.

For examples of how to query or modify attributes, refer to our Attribute Examples.

UnbdRay#

  • Type: double

  • Modifiable: No

Unbounded ray (for unbounded linear models only). Provides a vector that, when added to any feasible solution, yields a new solution that is also feasible but improves the objective. Only available when parameter InfUnbdInfo is set to 1.

For examples of how to query or modify attributes, refer to our Attribute Examples.