Try our new documentation site (beta).
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 white space 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. The name should be no longer than 255
characters, and to avoid confusing the LP parser, it should not begin
with a number, or with any of the characters
+, -, *, <, >, =, or :.
Note that white space is 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 headers, on its own line: minimize, maximize, minimum, maximum, min, or max. Capitalization in the header is ignored. The header is then followed by a 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 each variable with a piecewise-linear objective, the objective
section will include a __pwl(x) term, where x is the
name of the variable. You should view these as comments; they are
ignored by the LP reader. 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
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.1The following is a valid quadratic constraint:
qc0: 3.1 x + 4.5 y + 10 z + [ x ^ 2 + 2 x * y + 3 y ^ 2 ] <= 10
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, 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 are handled differently from other constraints by the MIP solver. A lazy constraint only becomes active when the MIP solver finds a candidate solution that violates the constraint.
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:
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 zVariable 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.
End statement
The last line in an LP format file should be an End statement.
