Hide navigation sidebar
Hide table of contents sidebar
Back to top
Toggle table of contents sidebar

# 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 must be no longer than 255 characters, must not contain any of the characters `+`, `-`, `*`, `^`, or `:` and must not begin with a number or any of the characters `<`, `>`, `=`, `(`, `)`, `[`, `]`, or `,`. Variable names must 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.

The maximum line length in an LP file is 999 characters. Expressions that require more characters can be broken up into as many individual lines as needed.

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

\[\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.

Help and Feedback

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