CPLEX lp files
The CPLEX LP file format provides a facility for entering a problem in a
natural, algebraic LP formulation from the keyboard. The problem can be
modified and saved from within lpsolve. This procedure is one way to create a
file in a format that lpsolve can read. An alternative technique is to create a
similar file using a standard text editor and to read it into lpsolve.
The CPLEX LP format is provided as an input alternative to the MPS file format.
An LP format file may be easier to generate than an MPS file if your problem
already exists in an algebraic format or if you have an application that
generates the problem file more readily in algebraic format (such as a C
application).
Note that the CPLEX LP format is not the same as the lpsolve LP format.
See LP file format for a description about
the native lpsolve lp format. To read/write this format from lpsolve, you need
an XLI (see External Language Interfaces). The XLI for the CPLEX
format is called xli_CPLEX.
Options
The XLI accepts several options:
Reading
objconst Allow constants in the objective (default).
noobjconst Don't allow constants in the objective.
Note that CPLEX doesn't allow constants in the objective (until at least v10).
However, the lp_solve XLI does allow it by default.
Use the option noobjconst if these should not be allowed.
The parser will then give an error.
Writing
objconst Allow constants in the objective.
noobjconst Don't use constants in the objective (default).
Note that CPLEX doesn't allow constants in the objective (until at least v10).
However, the lp_solve XLI does allow it when the option objconst is used.
By default or when the option noobjconst is used, a constant in the objective
is translated to a variable objconst_term with a bound equal to the constant set
to it. So no error is generated when there is a constant.
Example
lp_solve rxli xli_CPLEX input.lpt
lp_solve mps input.mps wxli xli_CPLEX output.lpt wxliopt "objconst"
Syntax Rules of LP File Format
lpsolve will accept any problem saved in an ASCII file provided that it adheres
to the following syntax rules.

Anything that follows a backslash (\) is a comment and is ignored until a
return is encountered. Blank lines are also ignored. Blank and comment lines
may be placed anywhere and as frequently as you want in the file.

In general, white space between characters is irrelevant as it is skipped when
a file is read. However, white space is not allowed in the keywords used to
introduce a new section, such as
MAX , MIN , ST ,
or BOUNDS . Also the keywords must be separated by white space from
the rest of the file and must be at the beginning of a line. The maximum length for any
name is 255. The maximum length of any line of input is 510.


Skipping spaces may cause lpsolve to misinterpret (and accept) an invalid
entry, such as the following:


If the user intended to enter that example as a nonlinear constraint,
lpsolve would instead interpret it as a constraint specifying
that one variable named
x1x2 must be equal to zero.

The problem statement must begin with the word
MINIMIZE or MAXIMIZE ,
MINIMUM or MAXIMUM , or the abbreviations MIN
or MAX , in any combination of upper and lowercase
characters. The word introduces the objective function section.

Variables can be named anything provided that the name does not exceed 255
characters, all of which must be alphanumeric (az, AZ, 09) or one of these
symbols: ! " # $ % & ( ) / , . ; ? @ _ ` ' { }  ~. Longer names are
truncated to 255 characters. A variable name cannot begin with a number or a
period.


The letter
E or e , alone or followed by other valid
symbols, or followed by another E or e , should be
avoided as this notation is reserved for exponential entries. Thus, variables
cannot be named e9 , E24 , E8cats , or
other names that could be interpreted as an exponent. Even variable names such
as eels or example can cause a read error,
depending on their placement in an input line.


Also, the following characters are not valid in variable names (in order to
allow for quadratic objective information): ^, *, [ and ].

The objective function definition must follow
MINIMIZE or MAXIMIZE .
It may be entered on multiple lines as long as no variable,
constant, or sense indicator is split by a return. For example, this
objective function 1x1 + 2x2 +3x3 can be entered like this:
but not like this:
because the second style splits the variable name x2 with a return.

The objective function may be named by typing a name and a colon before the
objective function. The objective function name and the colon must appear on
the same line. Objective function names must conform to the same guidelines as
variable names (Rule 4).

The constraints section is introduced by the keyword
SUBJECT TO .
This expression can also appear as such that , st , S.T. ,
or ST. in any mix of upper and lowercase characters. One of
these expressions must precede the first constraint and be separated from it by
at least one space.

Each constraint definition must begin on a new line. A constraint may be named
by typing a name and a colon before the constraint. The constraint name and the
colon must appear on the same line. Constraint names must adhere to the same
guidelines as variable names (Rule 4). If
no constraint names are specified, lpsolve assigns the names
R1 ,
R2 , R3 , etc.

The constraints are entered in the same way as the objective function; however,
a constraint must be followed by an indication of its sense and a righthand
side coefficient. The righthand side coefficient must be typed on the same
line as the sense indicator. Acceptable sense indicators are <, <=,
=<, >, >=, =>, and =. These are interpreted as <=, <=, <=, >=, >=, >= and
=, respectively.
For example, here is a named constraint:

The optional
BOUNDS section follows the mandatory constraint
section. It is preceded by the word bounds or bound
in any mix of lower and uppercase characters.

Each bound definition must begin on a new line. The format for a bound is l_{n} <= x_{n
} <= u_{n} except in the following cases:
Upper and lower bounds may also be entered separately as:
l_{n} <= x_{n}
x_{n} <= u_{n}
with the default lower bound of 0 (zero) and the default upper bound of +infinite
remaining in effect until the bound is explicitly changed.
Bounds that fix a variable can be entered as simple equalities.
For example, x5
= 5.6 is equivalent to 5.6 <= x5 <= 5.6 .
The bounds positive infinity and negative infinity must be entered as
words: +infinity , infinity , +inf , inf .
A variable with a negative infinity lower bound and positive infinity upper
bound may be entered as free , in any mix of upper and lowercase
characters, with a space separating the variable name and the word free .
For example, x7 free is equivalent to infinity <= x7 <=
+infinity .

The file must end with the word
end in any combination of upper
and lowercase characters, alone on a line. This word is not required for files that are read in to lpsolve, but
it is strongly recommended. Files that have been corrupted can frequently be
detected by a missing last line.

To specify any of the variables as general integer variables, add a
GENERAL
section; to specify any of the variables as binary integer variables, add a BINARY
section. The GENERAL and BINARY sections follow the
BOUNDS section, if one is present; otherwise, they follow the
constraints section. Either of the GENERAL or BINARY sections
can precede the other. The GENERAL section is preceded by the word
GENERAL , GENERALS , or GEN in any mix of
upper and lowercase characters which must appear alone.
The following line or lines should list the names of
all variables which are to be restricted to general integer values, separated
by at least one space. The BINARY section is preceded by the word
BINARY , BINARIES , or BIN in any mix of
upper and lowercase characters which must appear alone on a line.
The following line or lines should list the names of all
variables which are to be restricted to binary integer values, separated by at
least one space. Binary variables are automatically given bounds of 0 (zero)
and 1 (one), unless alternative bounds are specified in the BOUNDS
section, in which case a warning message is issued.
Here is an example of a problem formulation in LP format where x4 is
a general integer:

To specify any of the variables as semicontinuous variables, that is as variables that
may take the value
0 or values between the specified lower and upper bounds, use a SEMICONTINUOUS section. This section must follow the BOUNDS , GENERALS , and BINARIES sections. The SEMICONTINUOUS section is preceded by the keyword SEMICONTINUOUS , SEMI , or SEMIS .
The following line or lines should list the names of all the variables
which are to be declared semicontinuous, separated by at least one
space.

To specify special ordered
sets, use a SOS section, which is preceded by the SOS keyword. The SOS
section should follow the Bounds, General, Binaries and SemiContinuous
sections. Special ordered sets of type 1 require that, of the variables
in the set, one at most may be nonzero. Special ordered sets of type 2
require that at most two variables in the set may be nonzero, and if
there are two nonzeros, they must be adjacent. Adjacency is defined by
the weights, which must be unique within a set given to the variables.
The sorted weights define the order of the special ordered set. For MIP
branch and cut, the order is used to determine how the variables are
branched upon. The set is specified by an optional set name followed
by a colon and then either of the S1 or S2 keywords (specifying the type)
followed by a double colon. The set member names are
listed on this line or lines, with their weights. Variable names and
weights are separated by a colon, for example:
SOS
set1: S1:: x1:10 x2:13

