Linear Constraint Attributes#
These are linear constraint attributes, meaning that they are associated
with specific linear constraints 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, linear constraint attributes are
retrieved by invoking the get
method on a constraint 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
GRB_ERROR_DATA_NOT_AVAILABLE
error code. The object-oriented
interfaces will throw an exception.
Additional linear constraint attributes can be found in the Multi-Scenario Attributes section.
Sense#
Type:
char
Modifiable:
Yes
Constraint sense ('<'
, '>'
, or '='
).
For examples of how to query or modify attributes, refer to our Attribute Examples.
RHS#
Type:
double
Modifiable:
Yes
Constraint right-hand side. Note that a less-than-or-equal constraint
with a RHS value of 1e20
or larger, or a greater-than-or-equal
constraint with RHS value of -1e20
or smaller, will be treated as
always being satisfied. Equality constraints with very large RHS values
can lead to numerical issues, so these should be avoided.
For examples of how to query or modify attributes, refer to our Attribute Examples.
ConstrName#
Type:
string
Modifiable:
Yes
Constraint name.
For examples of how to query or modify attributes, refer to our Attribute Examples.
CTag#
Type:
string
Modifiable:
Yes
Tag for constraints.
If you will be retrieving the solution to your model in JSON format, you might define a tag for every constraint that you plan to retrieve solution information for. Each constraint 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.
Note that constraint tags are only allowed for continuous models.
For examples of how to query or modify attributes, refer to our Attribute Examples.
Pi#
Type:
double
Modifiable:
No
The constraint dual value in the current solution (also known as the shadow price).
Given a linear programming problem
and a corresponding dual problem
the Pi
attribute returns \(y\).
Of course, not all models fit this canonical form. In general, dual values have the following properties:
Dual values for \(\ge\) constraints are \(\ge 0\).
Dual values for \(\le\) constraints are \(\le 0\).
Dual values for \(=\) constraints are unconstrained.
For models with a maximization sense, the senses of the dual values are reversed: the dual is \(\ge 0\) for a \(\le\) constraint and \(\le 0\) for a \(\ge\) constraint.
Note that constraint dual values for linear constraints of QCP models are only available when the QCPDual parameter is set to 1. To query the duals of the quadratic constraints in a QCP model, see QCPi.
Only available for convex, continuous models.
For examples of how to query or modify attributes, refer to our Attribute Examples.
Slack#
Type:
double
Modifiable:
No
The constraint slack in the current solution.
For examples of how to query or modify attributes, refer to our Attribute Examples.
CBasis#
Type:
int
Modifiable:
Yes
The status of a given linear constraint in the current basis. Possible values are 0 (basic) or -1 (non-basic). A constraint is basic when its slack variable is in the simplex basis. 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.
DStart#
Type:
double
Modifiable:
Yes
The current simplex start vector. If you set DStart
values for every
linear constraint in the model and PStart values for every
variable, then simplex will use those values to compute a warm start
basis. If you’d like to retract a previously specified start, set any
DStart
value to GRB_UNDEFINED
.
Note that any model modifications which are pending or are made after
setting DStart
(adding variables or constraints, changing
coefficients, etc.) will discard the start. You should only set this
attribute after you are done modifying your model.
Note also that you’ll get much better performance if you warm start your
linear program from a simplex basis (using VBasis and
CBasis). The DStart
attribute should only be used in
situations where you don’t have a basis or you don’t want to disable
presolve.
If you’d like to provide a feasible starting solution for a MIP model, you should input it using the Start attribute.
Only affects LP models; it will be ignored for QP, QCP, or MIP models.
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.
Lazy#
Type:
int
Modifiable:
Yes
Determines whether a linear constraint is treated as a lazy constraint or a user cut.
At the beginning of the MIP solution process, any constraint whose
Lazy
attribute is set to 1, 2, or 3 (the default value is 0) is
treated as a lazy constraint; it is removed from the model and placed in
the lazy constraint pool. Lazy constraints remain inactive until a
feasible solution is found, at which point the solution is checked
against the lazy constraint pool. If the solution violates any lazy
constraints, the solution is discarded and one or more of the violated
lazy constraints are pulled into the active model.
Larger values for this attribute cause the constraint to be pulled into the model more aggressively. With a value of 1, the constraint can be used to cut off a feasible solution, but it won’t necessarily be pulled in if another lazy constraint also cuts off the solution. With a value of 2, all lazy constraints that are violated by a feasible solution will be pulled into the model. With a value of 3, lazy constraints that cut off the relaxation solution at the root node are also pulled in.
Any constraint whose Lazy attribute is set to -1 is treated as a user cut; it is removed from the model and placed in the user cut pool. User cuts may be added to the model at any node in the branch-and-cut search tree to cut off relaxation solutions.
The main difference between user cuts and lazy constraints is that the former are not allowed to cut off integer-feasible solutions. In other words, they are redundant for the MIP model, and the solver is free to decide whether or not to use them to cut off relaxation solutions. The hope is that adding them speeds up the overall solution process. Lazy constraints have no such restrictions. They are essential to the model, and the solver is forced to apply them whenever a solution would otherwise not satisfy them.
Note that deleting constraints from your model will cause this attribute to be discarded. If you’d like it to persist, your program will need to repopulate it after deleting the constraints and making a subsequent model update call.
Note that no corresponding attribute is available for other constraint types (quadratic, SOS, or general constraints). This attribute only affects MIP models.
For examples of how to query or modify attributes, refer to our Attribute Examples.
IISConstr#
Type:
int
Modifiable:
No
For an infeasible model, indicates whether the linear constraint participates in the computed Irreducible Inconsistent Subsystem (IIS). Only available after you have computed an IIS.
For examples of how to query or modify attributes, refer to our Attribute Examples.
IISConstrForce#
Type:
int
Modifiable:
Yes
When computing an Irreducible Inconsistent Subsystem (IIS) for an infeasible model, indicates whether the linear constraint 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 constraint is not eligible for inclusion in the IIS.
If the attribute is set to 1, the constraint 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
GRB_ERROR_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.
SARHSLow#
Type:
double
Modifiable:
No
Right-hand side sensitivity information: smallest right-hand side 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.
SARHSUp#
Type:
double
Modifiable:
No
Right-hand side sensitivity information: largest right-hand side 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.
FarkasDual#
Type:
double
Modifiable:
No
Together, attributes FarkasDual and FarkasProof provide a certificate of infeasibility for the given infeasible problem. Specifically, FarkasDual provides a vector \(\lambda\) that can be used to form the following inequality from the original constraints that is trivially infeasible within the bounds of the variables:
This inequality is valid even if the original constraints have a mix of less-than and greater-than senses because \(\lambda_i \geq 0\) if the \(i\)-th constraint has a \(\leq\) sense and \(\lambda_i \leq 0\) if the \(i\)-th constraint has a \(\geq\) sense.
Let
be the coefficients of this inequality and
be its right hand side. With \(L_j\) and \(U_j\) being the lower and upper bounds of the variables \(x_j\), we have \(\bar{a}_j \geq 0\) if \(U_j = \infty\), and \(\bar{a}_j \leq 0\) if \(L_j = -\infty\).
The minimum violation of the Farkas constraint is achieved by setting \(x^*_j := L_j\) for \(\bar{a}_j > 0\) and \(x^*_j := U_j\) for \(\bar{a}_j < 0\). Then, we can calculate the minimum violation as
where \(\beta>0\).
The FarkasProof attribute gives the value of \(\beta\).
These attributes are only available when parameter InfUnbdInfo is set to 1.
For examples of how to query or modify attributes, refer to our Attribute Examples.