Model File Formats#
MPS format#
MPS format is the oldest and most widely used format for storing math programming models. There are actually two variants of this format in wide use. In fixed format, the various fields must always start at fixed columns in the file. Free format is very similar, but the fields are separated by whitespace characters instead of appearing in specific columns. One important practical difference between the two formats is in name length. In fixed format, row and column names are exactly 8 characters, and spaces are part of the name. In free format, names can be arbitrarily long (although the Gurobi reader places a 255 character limit on name length), and names may not contain spaces. The Gurobi MPS reader reads both MPS types, and recognizes the format automatically.
Note that any line that begins with the *
character is a comment.
The contents of that line are ignored.
NAME section#
The first section in an MPS format file is the NAME
section. It
gives the name of the model:
NAME AFIRO
In fixed format, the model name starts in column 15.
OBJSENSE section#
The OBJSENSE
section is an optional section for maximizing the
objective function. By default, Gurobi assumes the objective function of
an MPS file should be minimized, in which case the OBJSENSE
section
can be omitted.
To instruct Gurobi to maximize the objective function, add the line
OBJSENSE MAX
after the NAME
section.
ROWS section#
The next section is the ROWS
section. It begins with the word
ROWS
on its own line, and continues with one line for each row in
the model. These lines indicate the constraint type (E
for equality,
L
for less-than-or-equal, or G
for greater-than-or-equal), and
the constraint name. In fixed format, the type appears in column 2 and
the row name starts in column 5. Here’s a simple example:
ROWS
E R09
E R10
L X05
N COST
Note that an N
in the type field indicates that the row is a free
row. The first free row is used as the objective function.
If the file includes multiple N
rows, each including a priority,
weight, relative, and absolute tolerance field, then each such row is
treated as an objective in a multi-objective model. The additional
fields must appear after the name, separated by spaces. For example, the
following would capture a pair of objectives, where the first has
priority 2 and the second has priority 1 (and both have identical
weights, and relative and absolute tolerances):
N OBJ0 2 1 0 0
N OBJ1 1 1 0 0
Please refer to the multi-objective, ObjNPriority, ObjNWeight, ObjNAbsTol, and ObjNRelTol sections for information on the meanings of these fields. Note that all objectives of a multi-objective optimization problem have to be linear.
LAZYCONS section#
The next section is the LAZY CONSTRAINTS
section. It begins with the
line LAZYCONS
, optionally followed by a space and a laziness level
1-3 (if no laziness level is specified 1 is assumed), and continues with
one line for each lazy constraint. The format is the same as that of the
ROWS
section: each line indicates the constraint type (E
for
equality, L
for less-than-or-equal, or G
for
greater-than-or-equal), and the constraint name. In fixed format, the
type appears in column 2 and the row name starts in column 5. For
example:
LAZYCONS
E R01
G R07
L S01
LAZYCONS 2
E R02
G R03
L S11
Lazy constraints are linear constraints, and they are semantically
equivalent to standard linear constraints (i.e., entries in the ROWS
section). Depending on their laziness level they are enforced
differently by the MIP solver. Please refer to the description of the
Lazy attribute for details.
This section is optional.
USERCUTS section#
The next section is the USER CUTS
section. It begins with the line
USERCUTS
, on its own line, and continues with one line for each user
cut. The format is the same as that of the ROWS
section: each line
indicates the constraint type (E
for equality, L
for
less-than-or-equal, or G
for greater-than-or-equal), and the
constraint name. In fixed format, the type appears in column 2 and the
row name starts in column 5. For example:
USERCUTS
E R01
G R07
L S01
User cuts are linear constraints, and they are semantically equivalent
to standard linear constraints (i.e., entries in the ROWS
section).
Please refer to the description of the Lazy attribute for
details.
This section is optional.
COLUMNS section#
The next and typically largest section of an MPS file is the COLUMNS
section, which lists the columns in the model and the non-zero
coefficients associated with each. Each line in the columns section
provides a column name, followed by either zero, one, or two non-zero
coefficients from that column. Coefficients are specified using a row
name first, followed by a floating-point value. Consider the following
example:
COLUMNS
X01 X48 .301 R09 -1.
X01 R10 -1.06 X05 1.
X02 X21 -1. R09 1.
X02 COST -4.
The first line indicates that column X01
has a non-zero in row
X48
with coefficient .301
, and a non-zero in row R09
with
coefficient -1.0
. Note that multiple lines associated with the same
column must be contiguous in the file.
In fixed format, the column name starts in column 5, the row name for the first non-zero starts in column 15, and the value for the first non-zero starts in column 25. If a second non-zero is present, the row name starts in column 40 and the value starts in column 50.
Integrality markers#
The COLUMNS
section can optionally include integrality markers. The
variables introduced between a pair of markers must take integer values.
All variables within markers will have a default lower bound of 0 and a
default upper bound of 1 (other bounds can be specified in the
BOUNDS
section). The beginning of an integer section is marked by an
INTORG
marker:
MARK0000 'MARKER' 'INTORG'
The end of the section is marked by an INTEND
marker:
MARK0000 'MARKER' 'INTEND'
The first field (beginning in column 5 in fixed format) is the name of
the marker (which is ignored). The second field (in column 15 in fixed
format) must be equal to the string 'MARKER'
(including the single
quotes). The third field (in column 40 in fixed format) is 'INTORG'
at the start and 'INTEND'
at the end of the integer section.
The COLUMNS
section can contain an arbitrary number of such marker
pairs.
RHS section#
The next section of an MPS file is the RHS
section, which specifies
right-hand side values. Each line in this section may contain one or two
right-hand side values.
RHS
B X50 310. X51 300.
B X05 80. X17 80.
The first line above indicates that row X50
has a right-hand side
value of 310
, and X51
has a right-hand side value of 300
. In
fixed format, the variable name for the first bound starts in column 15,
and the first bound value starts in column 25. For the second bound, the
variable name starts in column 40 and the value starts in column 50. The
name of the RHS is specified in the first field (column 5 in fixed
format), but this name is ignored by the Gurobi reader. If a row is not
mentioned anywhere in the RHS
section, that row takes a right-hand
side value of 0
. You may define an objective offset by setting the
negative offset as right-hand side of the objective row. For example, if
the linear objective row in the problem is called COST
and you want
to add an offset of 1000 to your objective function, you can add the
following to the RHS
section:
RHS
RHS1 COST -1000
BOUNDS section#
The next section in an MPS file is the optional BOUNDS
section. By
default, each variable takes a lower bound of 0 and an infinite upper
bound. Each line in this section can modify the lower bound of a
variable, the upper bound, or both. Each line indicates a bound type
(in column 2 in fixed format), a bound name (ignored), a variable name
(in column 15 in fixed format), and a bound value (in columns 25 in
fixed format). The different bound types, and the meaning of the
associate bound value, are as follows:
Bound type |
Meaning |
---|---|
LO |
lower bound |
UP |
upper bound |
FX |
variable is fixed at the specified value |
FR |
free variable (no lower or upper bound) |
MI |
infinite lower bound |
PL |
infinite upper bound |
BV |
variable is binary (equal 0 or 1) |
LI |
lower bound for integer variable |
UI |
upper bound for integer variable |
SC |
upper bound for semi-continuous variable |
SI |
upper bound for semi-integer variable |
Consider the following example:
BOUNDS
FR BND X49
UP BND X50 80.
LO BND X51 20.
FX BND X52 30.
In this BOUNDS
section, variable X49
gets a lower bound of
-infinity
(infinite upper bound is unchanged), variable X50
gets
a upper bound of 80
(lower bound is unchanged at 0
, X51
gets
a lower bound of 20
(infinite upper bound is unchanged), and X52
is fixed at 30
.
QUADOBJ section#
The next section in an MPS file is the optional QUADOBJ
section,
which contains quadratic objective terms. Each line in this section
represents a single non-zero value in the lower triangle of the Q
matrix. The names of the two variable that participate in the quadratic
term are found first (starting in columns 5 and 15 in fixed format),
followed by the numerical value of the coefficient (in column 25 in
fixed format). By convention, the Q matrix has an implicit one-half
multiplier associated with it. Here’s an example containing three
quadratic terms:
QUADOBJ
X01 X01 10.0
X01 X02 2.0
X02 X02 2.0
These three terms would represent the quadratic function \((10 X01^2 + 2 X01 * X02 + 2 X02 * X01 + 2 X02^2)/2\) (recall that the single off-diagonal term actually represents a pair of non-zero values in the symmetric Q matrix).
QCMATRIX section#
The next section in an MPS file contains zero or more QCMATRIX
blocks. These blocks contain the quadratic terms associated with the
quadratic constraints. There should be one block for each quadratic
constraint in the model.
Each QCMATRIX
block starts with a line that indicates the name of
the associated quadratic constraint (starting in column 12 in fixed
format). This is followed by one of more quadratic terms. Each term is
described on one line, which gives the names of the two involved
variables (starting in columns 5 and 15 in fixed format), followed by
the coefficient (in column 25 in fixed format). For example:
QCMATRIX QC0
X01 X01 10.0
X01 X02 2.0
X02 X01 2.0
X02 X02 2.0
These four lines describe three quadratic terms: quadratic constraint
QC0
contains terms \(10 X01^2\), \(4 X01*X02\), and
\(2 X02^2\). Note that a QCMATRIX
block must contain a symmetric
matrix, so for example an X01*X02
term must be accompanied by a
matching X02*X01
term.
Linear terms for quadratic constraint QC0
appear in the COLUMNS
section. The sense and right-hand side value appear in the ROWS
and
RHS
sections, respectively.
PWLOBJ section#
The next section in an MPS file is the optional PWLOBJ
section,
which contains piecewise-linear objective functions. Each line in this
section represents a single point in a piecewise-linear objective
function. The name of the associated variable appears first (starting in
column 4), followed by the x and y coordinates of the point (starting in
columns 14 and 17). Here’s an example containing two piecewise-linear
expressions, for variables X01
and X02
, each with three points:
PWLOBJ
X01 1 1
X01 2 2
X01 3 4
X02 1 1
X02 3 5
X02 7 10
SOS section#
The next section in an MPS file is the optional SOS
section. The
representation for a single SOS constraint contains one line that
provides the type of the SOS set (S1
for SOS type 1 or S2
for
SOS type 2, found in column 2 in fixed format) and the name of the SOS
set (column 5 in fixed format) of the SOS set. This is followed by one
line for each SOS member. The member line gives the name of the member
(column 5 in fixed format) and the associated weight (column 15 in fixed
format). Here’s an example containing two SOS2 sets.
SOS
S2 sos1
x1 1
x2 2
x3 3
S2 sos2
x3 1
x4 2
x5 3
Indicator Constraint section#
The indicator constraint section is optional in the MPS format. It
starts with the keyword INDICATORS
. Each subsequent line of the
indicator section starts with the keyword IF
(placed at column 2 in
fixed format) followed by a space and a row name (the row must have
already been defined in the ROWS
section). The line continues with a
binary variable (placed at column 15 in fixed format) and finally a
value 0
or 1
(placed at column 25 in fixed format).
Here a simple example:
INDICATORS
IF row1 x1 0
IF row2 y1 1
The first indicator constraint in this example states that row1
has
to be fulfilled if the variable x1
takes a value of 0
.
General Constraint section#
An MPS file may contain an optional section that captures general
constraints. This section starts with the keyword GENCONS
.
General constraints can be of three basic types: simple general constraints - MIN, MAX, OR, AND, NORM, ABS or PWL, function constraints - polynomial (POLY), power (POW), exponential ( EXP or EXPA), logarithmic (LOG, LOGA), logistic (LOGISTIC), or trigonometric (SIN, COS, or TAN), or nonlinear constraints - arbitrary nonlinear expressions.
Each simple and function constraint starts with a general constraint type specifier (MIN, MAX, OR, AND, NORM, ABS, PWL, POLY, POW, EXP, EXPA, LOG, LOGA, LOGISTIC, SIN, COS, or TAN), found in column 2 in fixed format. Optionally a space and a constraint name may follow. For a NORM constraint, the norm type (0, 1, 2, or INF) follows the type specifier (and is optionally followed by a constraint name).
For function constraints, the next line defines a few attributes used to perform the piecewise-linear approximation. The line starts with the keyword Options (found in column 5 in fixed format), followed by two spaces, followed by four values (separated by two spaces) that define the FuncPieces, FuncPieceLength, FuncPieceError, and FuncPieceRatio and FuncNonlinear attribute values (in that order).
What follows depends on the general constraint type. Simple general constraints start with the name of the so-called resultant variable, placed on it’s own line (starting at column 5 in fixed format). For MIN or MAX constraints, a non empty list of variables or values follows (with each variable name on its own line). For OR, AND, and NORM constraints, a list of variables follows (each on its own line). The variables must be binary for OR and AND constraints. For ABS constraints, only one additional variable follows (on its own line). In fixed format, all of these variables or values begin in column 5.
Piecewise-linear constraints start with the name of the so-called operand variable (starting at column 5 in fixed format), followed by the so-called resultant variable. The next lines contain the piecewise-linear function breakpoints, each represented as pair of x and y values. The x values must be non-decreasing.
Function constraints also start with the name of the operand variable (starting at column 5 in fixed format), followed by two spaces, followed by the name of the resultant variable. This is sufficient to define EXP, LOG, LOGISTIC, SIN, COS, and TAN functions. The POW, EXPA and LOGA functions require an exponent or base, respectively, which is defined on the next line (starting in column 5 in fixed format). For the polynomial function, the following lines contain a coefficient (at column 5 in fixed format), followed by two spaces, followed by the associated power (natural numbers only). Note that powers must be decreasing.
The other general constraint type, the INDICATOR constraint, appears
in a separate Indicator
section, which is described above.
The following shows an example of a general constraint section that contains simple and function constraints:
GENCONS
MAX gc0
r1
x1
x2
x10
0.7
MIN gencons1
r2
y0
10
y1
r1
AND and1
r
b1
b2
OR or1
r
b3
b4
NORM 2 norm2
r3
x1
y1
z1
ABS GC14
xabs
x
PWL GC0
x[0] y[0]
-1 2
0 1
0 0
0 1
1 2
POLY GC2
Options 0 0.01 0.001 -1
x y
4 7
2 3
SIN gc1
Options 0 0.01 1e-05 0.5
y z
LOGA gc6
Options 0 0.01 0.001 -1
x y
10
EXPA gc4
Options 0 0.01 0.001 -1
y z
3
The third type of general constraint, the nonlinear constraint, captures an arbitrary nonlinear expression as an expression tree. This representation is explained in the expression tree discussion. You will need to understand it to follow the discussion below.
The first line in a nonlinear constraint contains the letters NL (starting in column 2 in fixed format), followed by the name of the general constraint (starting in column 5 in fixed format).
The next line provides the name of the resultant variable (i.e., \(y\) in \(y = f(x)\)). The name starts in column 5 in fixed format.
The lines that follow provide information on the nodes of the expression tree. Each line describes one node, and the nodes are implicitly numbered in the order they appear, starting from node 0.
The first field for a node contains the name of the operation found at that node (starting in column 5 in fixed format). A list of supported arithmetic operations can be found in the operation codes discussion.
The next field, separated by blanks, gives an auxiliary data item for
this node’s operation, if there is one, and -1 otherwise. To give a
simple example, the CONSTANT
operation allows you to specify a
numerical constant within the expression, and the data item gives the
actual value of that constant. For a VARIABLE
operation, the data
item is the variable name.
Finally, the third field gives the parent node for this current node, using the implicit numbering noted above. The root node has parent -1.
Here’s a simple example of a general constraint section that contains a single nonlinear constraint:
GENCONS
NL GC0
y
PLUS -1 -1
SIN -1 0
MULTIPLY -1 1
CONSTANT 2.5 2
VARIABLE x1 2
VARIABLE x2 0
As is explained in the section Expression Trees this text represents the expression \(y = \sin(2.5 x_1) + x_2\).
For more information on all the different general constraint types, consult the general constraint discussion.
Scenario section#
An MPS file may contain an optional section that captures scenario data. A model can have multiple scenarios, where each defines a set of changes to the original model (which we refer to as the base model).
This section starts with the keyword SCENARIOS
, followed by the
number of scenarios. Scenarios are described as a set of changes to the
objective function, the right-hand sides of linear constraints, and the
bounds of variables. Objective changes are stated first, followed by
right-hand side changes, then bound changes. A scenario can be empty
(i.e., identical to the base model).
Each scenario starts with the keyword NAME
(starting at column 2 in
fixed format), followed by a scenario name.
Changes to the objective function are defined in the COLUMNS
subsection (starting at column 2 in fixed format). Each objective change
is on its own line; that line contains the variable name (starting at
column 5 in fixed format), the objective name (starting at column 15 in
fixed format), and the modified objective value (starting at column 25
in fixed format). The format is similar to the columns section above.
Changes to the right-hand sides of linear constraints are defined in the
RHS
subsection (starting at column 2 in fixed format). Each
right-hand side change is on its own line; that line contains a
right-hand side specifier (starting at column 5 in fixed format), the
constraint name (starting at column 15 in fixed format), and the
right-hand side value (starting at column 25 in fixed format). The
format is similar to the right-hand side section above.
Changes to variable bounds are defined in the BOUNDS
subsection.
Each changed variable bound is on its own line. The format is similar to
the bounds section above (with a small difference that the first and
second column in fixed format are 5 and 8, respectively).
The following example shows three scenarios in MPS format:
SCENARIOS 3
NAME scenario0
NAME scenario1
COLUMNS
x1 OBJ 0
x2 OBJ 1
RHS
RHS1 c1 2
RHS1 c2 2
BOUNDS
FR BND1 x1
LO BND1 x3 0.5
UP BND1 x3 1.5
FX BND1 x2 0
NAME scenario2
BOUNDS
FX BND1 x3 3
For more information, consult the multiple scenario discussion.
ENDATA#
The final line in an MPS file must be an ENDATA
statement.
Additional notes#
Note that in the Gurobi Optimizer, MPS models are always written in full precision. That means that if you write a model and then read it back, the data associated with the resulting model will be bit-for-bit identical to the original data.
REW format#
The REW format is identical to the MPS format, except
in how objects are named when files are written. When writing an MPS
format file, the Gurobi Optimizer refers to constraints and variables
using their given names. When writing an REW format file, the Gurobi
Optimizer ignores the given names and instead refers to the variables
using a set of default names that are based on row and column numbers.
The constraint name depends solely on the associated row number: row
i
gets name ci
. The variable name depends on the type of the
variable, the column number of the variable in the constraint matrix,
and the number of non-zero coefficients in the associated column. A
continuous variable in column 7 with column length 2 would get name
C7(2)
, for example. A binary variable with the same characteristics
would get name B7(2)
.
DUA format#
The DUA format is identical to the MPS format. The only difference is in how they are used. Writing a DUA file will generate and write the dual formulation of a pure LP model.
LP format#
The LP format captures an optimization model in a way that is easier for humans to read than MPS format, and can often be more natural to produce. One limitation of the LP format is that it doesn’t preserve several model properties. In particular, LP files do not preserve column order when read, and they typically don’t preserve the exact numerical values of the coefficients (although this isn’t inherent to the format).
Unlike MPS files, LP files do not rely on fixed field widths. Line breaks and whitespace characters are used to separate objects. Here is a simple example:
\ LP format example
Maximize
x + y + z
Subject To
c0: x + y = 1
c1: x + 5 y + 2 z <= 10
qc0: x + y + [ x ^ 2 - 2 x * y + 3 y ^ 2 ] <= 5
Bounds
0 <= x <= 5
z >= 2
Generals
x y z
End
The backslash symbol starts a comment; the remainder of that line is ignored.
Variable names play a major role in LP files. Each variable must have
its own unique name. A name should be no longer than 255 characters, and
to avoid confusing the LP parser, it can not begin with a number or any
of the characters +, -, *, ^, <, >, =, (, ), [, ], ,, or :
. For
similar reasons, a name should not contain any of the characters
+, -, *, ^, or :
. Also, variable names should not be equal (case
insensitive) to any of the LP file format keywords, e.g.,
st, bounds, min, max, binary, or end
. Names must be preceded and
followed by whitespace.
The same rules apply to any other type of names in the LP format, e.g., constraint names or the objective name.
Note that whitespace characters are not optional in the Gurobi LP
format. Thus, for example, the text x+y+z
would be treated as a
single variable name, while x + y + z
would be treated as a three
term expression.
LP files are structured as a list of sections, where each section captures a logical piece of the whole optimization model. Sections begin with particular keywords, and must generally come in a fixed order, although a few are allowed to be interchanged.
Objective Section#
The first section in an LP file is the objective section. This section begins with one of the following six keywords: minimize, maximize, minimum, maximum, min, or max. Capitalization is ignored. This keyword may appear alone, or it may be immediately followed by multi-objectives, which indicates that the model contains multiple objective functions.
Single-Objective Case#
Let us consider single-objective models first, where this header is followed by a single linear or quadratic expression that captures the objective function.
The objective optionally begins with a label. A label consists of a name, followed by a colon character, following by a space. A space is allowed between the name and the colon, but not required.
The objective then continues with a list of linear terms, separated by
the +
or -
operators. A term can contain a coefficient and a
variable (e.g., 4.5 x
), or just a variable (e.g., x
). The
objective can be spread over many lines, or it may be listed on a single
line. Line breaks can come between tokens, but never within tokens.
The objective may optionally continue with a list of quadratic terms.
The quadratic portion of the objective expression begins with a [
symbol and ends with a ]
symbol, followed by / 2
. These brackets
should enclose one or more quadratic terms. Either squared terms (e.g.,
2 x ^ 2
) or product terms (e.g., 3 x * y
) are accepted.
Coefficients on the quadratic terms are optional.
For variables with piecewise-linear objective functions, the objective
section will include a __pwl(x)
term, where x
is the name of the
variable. The actual piecewise-linear expressions are pulled from the
later PWLObj
section.
The objective expression must always end with a line break.
An objective section might look like the following:
Minimize
obj: 3.1 x + 4.5 y + 10 z + [ x ^ 2 + 2 x * y + 3 y ^ 2 ] / 2
Multi-Objective Case#
In the multi-objective case, the header is followed by one or more
linear objective functions, where each starts with its own sub-header.
The sub-header gives the name of the objective, followed by a number of
fields that provide a Priority, Weight, absolute tolerance
(AbsTol) and relative tolerance (RelTol) for that objective (see
ObjNPriority, ObjNWeight, ObjNAbsTol,
and ObjNRelTol for details on the meanings of these fields).
The fields start with the field name, followed by a =
, followed by
the value. For example:
OBJ0: Priority=2 Weight=1 AbsTol=0 RelTol=0
Please refer to the multi-objective section for additional details.
Each sub-header is followed by a linear expression that captures that objective.
A complete multi-objective section might look like the following:
Minimize multi-objectives
OBJ0: Priority=2 Weight=1 AbsTol=0 RelTol=0
3.1 x + 4.5 y + 10 z
OBJ1: Priority=1 Weight=1 AbsTol=0 RelTol=0
10 x + 0.1 y
The objective section is optional. The objective is set to 0 when it is not present.
Constraints Section#
The next section is the constraints section. It begins with one of the following headers, on its own line: subject to, such that, st, or s.t.. Capitalization is ignored.
The constraint section can have an arbitrary number of constraints. Each
constraint starts with an optional label (constraint name, followed by a
colon, followed by a space), continues with a linear expression,
followed by an optional quadratic expression (enclosed in square
brackets), and ends with a comparison operator, followed by a numerical
value, followed by a line break. Valid comparison operators are =
,
<=
, <
, >=
, or >
. Note that LP format does not
distinguish between strict and non-strict inequalities, so for example
<
and <=
are equivalent.
Note that the left-hand side of a constraint may not contain a constant term; the constant must appear on the right-hand side.
The following is a simple example of a valid linear constraint:
c0: 2.5 x + 2.3 y + 5.3 z <= 8.1
The following is a valid quadratic constraint:
qc0: 3.1 x + 4.5 y + 10 z + [ x ^ 2 + 2 x * y + 3 y ^ 2 ] <= 10
The constraint section may also contain another constraint type: the
so-called indicator constraint. Indicator constraints start with an
optional label (constraint name, followed by a colon, followed by a
space), followed by a binary variable, a space, a =
, again a space
and a value, either 0
or 1
. They continue with a space, followed
by ->
, and again a space and finally a linear constraint (without a
label).
For example:
c0: b1 = 1 -> 2.5 x + 2.3 y + 5.3 z <= 8.1
This example constraint requires the given linear constraint to be
satisfied if the variable b1
takes a value of 1
.
Every LP format file must have a constraints section.
Lazy Constraints Section#
The next section is the lazy constraints section. It begins with the
line Lazy Constraints
, optionally followed by a space and a laziness
level 1-3 (if no laziness level is specified 1 is assumed), and
continues with a list of linear constraints in the exact same format as
the linear constraints in the constraints section. For example:
Lazy Constraints
c0: 2.5 x + 2.3 y + 5.3 z <= 8.1
Lazy Constraints 2
c1: 1.5 x + 3.3 y + 4.3 z <= 8.1
Lazy constraints are linear constraints, and they are semantically equivalent to standard linear constraints. Depending on their laziness level they are enforced differently by the MIP solver. Please refer to the description of the Lazy attribute for details.
This section is optional.
User Cuts Section#
The next section is the user cuts section. It begins with the line
User Cuts
, on its own line, and is followed by a list of linear
constraints in the exact same format as the linear constraints in the
constraints section. For example:
User Cuts
c0: 2.5 x + 2.3 y + 5.3 z <= 8.1
User cuts are linear constraints, and they are semantically equivalent to standard linear constraints. Please refer to the description of the Lazy attribute for details.
This section is optional.
Bounds Section#
The next section is the bounds section. It begins with the word
Bounds
, on its own line, and is followed by a list of variable
bounds. Each line specifies the lower bound, the upper bound, or both
for a single variable. The keywords inf
or infinity
can be used
in the bounds section to specify infinite bounds. A bound line can also
indicate that a variable is free
, meaning that it is unbounded in
either direction.
Here are examples of valid bound lines:
Bounds
0 <= x0 <= 1
x1 <= 1.2
x2 >= 3
x3 free
x2 >= -Inf
It is not necessary to specify bounds for all variables; by default, each variable has a lower bound of 0 and an infinite upper bound. In fact, the entire bounds section is optional.
Variable Type Section#
The next section is the variable types section. Variables can be designated as being either binary, general integer, or semi-continuous. In all cases, the designation is applied by first providing the appropriate header (on its own line), and then listing the variables that have the associated type. For example:
Binary
x y z
Variable type designations don’t need to appear in any particular order (e.g., general integers can either precede or follow binaries). If a variable is included in multiple sections, the last one determines the variable type.
Valid keywords for variable type headers are: binary, binaries, bin, general, generals, gen, semi-continuous, semis, or semi.
The variable types section is optional. By default, variables are assumed to be continuous.
SOS Section#
An LP file can contain a section that captures SOS constraints of type 1
or type 2. The SOS section begins with the SOS
header on its own
line (capitalization isn’t important). An arbitrary number of SOS
constraints can follow. An SOS constraint starts with a name, followed
by a colon (unlike linear constraints, the name is not optional here).
Next comes the SOS type, which can be either S1
or S2
. The type
is followed by a pair of colons.
Next come the members of the SOS set, along with their weights. Each member is captured using the variable name, followed by a colon, followed by the associated weight. Spaces can optionally be placed before and after the colon. An SOS constraint must end with a line break.
Here’s an example of an SOS section containing two SOS constraints:
SOS
sos1: S1 :: x1 : 1 x2 : 2 x3 : 3
sos2: S2 :: x4:8.5 x5:10.2 x6:18.3
The SOS section is optional.
PWLObj Section#
An LP file can contain a section that captures piecewise-linear
objective functions. The PWL section begins with the PWLObj
header
on its own line (capitalization isn’t important). Each piecewise-linear
objective function is associated with a model variable. A PWL function
starts with the corresponding variable name, followed immediately by a
colon (the name is not optional). Next come the points that define the
piecewise-linear function. These points are represented as (x, y)
pairs, with parenthesis surrounding the two values and a comma
separating them. A PWL function must end with a line break.
Here’s an example of a PWLObj section containing two simple piecewise-linear functions:
PWLObj
x1: (1, 1) (2, 2) (3, 4)
x2: (1, 3) (3, 5) (100, 300)
The PWLObj section is optional.
General Constraint Section#
An LP file may contain an optional section that captures general constraints. This section starts with one of the following keywords general constraints, general constraint, gencons, or g.c. (capitalization is ignored).
General constraints can be of three basic types: simple general
constraints - MIN, MAX, OR, AND, NORM, ABS, or PWL, or
function constraints - polynomial (POLY
), power (POW
),
exponential (EXP
or EXPA
), logarithmic (LOG
, LOGA
),
logistic (LOGISTIC
), or trigonometric (SIN
, COS
, or
TAN
), or nonlinear constraints - arbitrary
nonlinear expressions.
A simple general constraint starts with an optional label (constraint
name, followed by a colon), followed by a variable name (the so-called
resultant), then an equals sign =
. The line continues with a
general constraint type specifier (MIN, MAX, OR, AND, NORM, or
ABS), then a (
. All tokens must be separated using spaces.
Capitalization is ignored.
What follows depends on the general constraint type. MIN or MAX constraints expect a non-empty, comma-separated list of variables or values. OR and AND constraints expect a comma-separated list of binary variables. NORM expects a norm type (0, 1, 2, or INF), in parenthesis, followed by a comma-separated list of variables. ABS constraints expect only one variable name. Again, all tokens (including commas) must be separated using spaces.
All of these simple general constraints end with a )
and a line
break.
Here are a few examples:
gc0: r1 = MAX ( x1 , x2 , x10 , 0.7 )
gencons1: r2 = MIN ( y0 , 10 , y1 , r1 )
and1: r = AND ( b1 , b2 )
or1: r = OR ( b3 , b4 )
norm2: r = NORM ( 2 ) ( x1 , y1, z1 )
GC14: xabs = ABS ( x )
Piecewise-linear constraints also start with an optional label
(constraint name, followed by a colon). The line continues with a
variable name (the so-called resultant) and an equal sign =
. Next
comes the keyword PWL that indicates that the constraint is of type
piecewise-linear. This is followed by a (
, and then by a variable
name (the so-called operand) followed by a )
. The line continues
with a :
and then the list of piecewise-linear breakpoints in
parentheses (e.g., (x0, y0) (x1, y1)) with non-decreasing values on x.
Recall that spaces are required between tokens.
Here an example:
GC0: y[0] = PWL ( x[0] ) : (-1, 2) (0, 1) (0, 0) (0, 1) (1, 2)
There is one other type of simple constraint, the INDICATOR constraint. Those appear in the regular constraints section (described above), not in the general constraint section.
Function constraints also start with an optional label (constraint name,
followed by a colon). An optional list of attribute assignments follows.
These start with a (
, then a space-separated list of Name=Value
strings (no spaces before or after the =
), closed with a )
. An
example is shown below. Default values are used if no attributes are
specified.
The line continues with a variable name (the so-called resultant) and
an equal sign =
. Next comes a keyword that indicates the type of
function being defined (POLY, POW, EXP, EXPA, LOG, LOG_A,
LOGISTIC, SIN, COS, or TAN). For a LOG, use LOG_A if it
isn’t a natural log, where \(A\) is the base. This is followed by a
(
, and then by the expression that defines the actual function. The
line closes with a )
. Recall that spaces are required between
tokens.
Polynomials and powers are described in what is hopefully the natural
way, with exponents preceded by the ^
symbol.
The following give examples of a few function constraints:
gc1: ( FuncPieceError=1e-05 FuncPieceRatio=0.5 ) z = SIN ( y )
GC2: ( FuncPieceLength=0.001 ) y = POLY ( 5 x ^ 3 + 2 x + 5 )
gc3: z = EXPA ( 3.5 ^ y )
gc4: z = LOG_10 ( y )
logytoz: z = LOG ( y )
The third type of general constraint, the nonlinear constraint, captures an arbitrary nonlinear expression as an expression tree. This representation is explained in the expression tree discussion. You will need to understand it to follow the discussion below.
Nonlinear constraints start with an optional label (constraint
name, followed by a colon). The line continues with the name
of the resultant variable (\(y\) in \(y = f(x)\)), an equal
sign =
, the keyword NL, and a colon (all separated by spaces).
The text that follows provides information on the nodes of the expression tree. Each node is described by three values enclosed in parenthesis, separated by commas. Nodes are implicitly numbered in the order they appear, starting from node 0.
The first field for node gives the name of the operation found at that node. A list of supported arithmetic operations can be found in the operation codes discussion.
The second field for a node gives an auxiliary data item, if there
is one, and -1 otherwise. To give a simple example, the CONSTANT
operation in the first field allows you to specify a numerical
constant within the expression, and the second field gives the actual
value of that constant. The data item of a VARIABLE
operation is
the variable name.
Finally, the third field gives the parent node for this current node, using the implicit numbering noted above. The root node has parent -1.
A nonlinear constraint must by terminated with a line break. All tokens, including commas, must be separated with spaces.
Here’s a simple example of a general constraint section that contains a single nonlinear constraint:
GC0: y = NL : ( PLUS , -1 , -1 ) ( SIN , -1 , 0 ) ( MULTIPLY , -1 , 1 )
( CONSTANT , 2.5 , 2 ) ( VARIABLE , x1 , 2 ) ( VARIABLE , x2 , 0 )
As is explained in the section Expression Trees this text represents the expression \(y = \sin(2.5 x_1) + x_2\).
For more information on all the different general constraint types, consult the general constraint discussion.
Scenario Section#
An LP file may contain an optional section that captures scenario data. A model can have multiple scenarios, where each defines a set of changes to the original model (which we refer to as the base model).
This section starts with the Scenario keyword (capitalization is ignored), followed by a scenario name. Scenarios are described as a set of changes to the objective function, the right-hand sides of linear constraints, and the bounds of variables. Objective changes are stated first, followed by right-hand side changes, then bound changes. A scenario can be empty (i.e., identical to the base model).
Changes to the objective function start with one of the allowed
objective keywords (Minimize
, Maximize
, etc.; see objective
section above for additional information). Note that the keyword needs
to match the objective sense of the base model. This is followed by a
line for each changed objective coefficient that contains the variable
name and its modified value (separated by a space).
Changes to the right-hand sides of linear constraints start with one of
the allowed constraint section keywords (Subject To
, etc.; see the
constraints section above for additional information). This is followed
by a line for each changed right-hand side value that contains the
constraint name followed by a colon, then a space, the constraint sense,
a space, and the scenario right-hand side value.
Changes to variable bounds start with the Bounds
keyword. This is
followed by a line for each variable with changed scenario bounds; the
format of each such line is the same as in the bounds section above.
The following example shows three scenarios in LP format:
Scenario scenario0
Scenario scenario1
Maximize
x1 0
x2 1
Subject To
c1: <= 2
c2: >= 2
Bounds
x3 <= 1.5
x1 free
0 <= x2 <= 0
x3 >= 0.5
Scenario scenario2
Bounds
x3 = 3
For more information, consult the multiple scenario discussion.
End statement#
The last line in an LP format file should be an End
statement.
RLP format#
The RLP format is identical to the LP format, except
in how objects are named when files are written. When writing an LP
format file, the Gurobi Optimizer refers to constraints and variables
using their given names. When writing an RLP format file, the Gurobi
Optimizer ignores the given names and instead refers to the variables
using names that are based on variable or constraint characteristics.
The constraint name depends solely on the associated row number: row
i
gets name ci
. The variable name depends on the type of the
variable, the column number of the variable in the constraint matrix,
and the number of non-zero coefficients in the associated column. A
continuous variable in column 7 with column length 2 would get name
C7(2)
, for example. A binary variable with the same characteristics
would get name B7(2)
.
DLP format#
The DLP file format is identical to the LP format. The only difference is in how they are used. Writing a DLP file will generate and write the dual formulation of a pure LP model.
ILP format#
The ILP file format is identical to the LP format. The only difference is in how they are used. ILP files are specifically used to write computed Irreducible Inconsistent Subsystem (IIS) models.
OPB format#
The OPB file format is used to store pseudo-boolean satisfaction and pseudo-boolean optimization models. These models may only contain binary variables, but these variables may be complemented and multiplied together in constraints and objectives. Pseudo-boolean models in OPB files are translated into a MIP representation by Gurobi. The syntax of the OPB format is described in detail by Roussel and Manquinho. However, the OPB format supported by Gurobi is less restrictive, e.g., fractional coefficients are allowed.
The following is an example of a pseudo-boolean optimization model
The corresponding OPB file for this example is given by
* This is a dummy pseudo-boolean optimization model
min: y - 1.3 x ~z + ~z;
2 y - 3 x + 1.7 w = 1.7;
-1 y + x + x z ~v >= 0;
-1 y <= 0;
Lines starting with *
are treated as comments and ignored.
Non-comment lines must end with a semicolon ;
. Whitespace characters
must be used to separate variables. The complement of a variable may be
specified with a tilde ~
.
Only minimization models are supported. These models must be specified
with the min:
objective keyword. This keyword must appear before
other constraints. Satisfiability models may be defined by omitting the
objective.
Constraint senses >=
, =
, and <=
are supported.