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 )

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

\[\begin{split}\begin{array}{ll} \mathrm{minimize} & y - 1.3 x (1-z) + (1-z) \\ \mathrm{subject\ to} & 2 y - 3 x + 1.7 w = 1.7 \\ & -y + x + x z (1-v) \ge 0 \\ & -y \le 0,\\ & v, w, x, y, z \in \{0, 1\}. \end{array}\end{split}\]

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.

Press `/` or click to search this documentation	Gurobi website	Gurobi community forum
Go to other Gurobi documentation	Gurobi download	Contact support