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 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

\[\begin{split}\begin{array}{ll} \mathrm{minimize} & c'x \\ \mathrm{subject\ to} & Ax \ge b \\ & x \ge 0 \end{array}\end{split}\]

and a corresponding dual problem

\[\begin{split}\begin{array}{ll} \mathrm{maximize} & b'y \\ \mathrm{subject\ to} & A'y \le c \\ & y \ge 0 \end{array}\end{split}\]

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 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:

\[\lambda^tAx \leq \lambda^tb.\]

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

\[\bar{a} := \lambda^tA\]

be the coefficients of this inequality and

\[\bar{b} := \lambda^tb\]

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

\[\beta := \bar{a}^tx^* - \bar{b} = \sum\limits_{j:\bar{a}_j>0}\bar{a}_jL_j + \sum\limits_{j:\bar{a}_j<0}\bar{a}_jU_j - \bar{b}\]

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.