MOSEK supports the standard MPS format with some extensions. For a detailed description of the MPS format the book by Nazareth [12] is a good reference.
The version of the MPS format supported by MOSEK allows specification of an optimization problem on the form
![]() |
(B.1.1) |
where
is a vector of quadratic functions. Hence,
![]() |
where it is assumed that
![]() |
(B.1.2) |
Please note the explicit 1/2 in the quadratic term and that is required to be symmetric.
An MPS file with one row and one column can be illustrated like this:
* 1 2 3 4 5 6
*23456789012345678901234567890123456789012345678901234567890
NAME [name]
OBJSENSE
[objsense]
OBJNAME
[objname]
ROWS
? [cname1]
COLUMNS
[vname1] [cname1] [value1] [vname3] [value2]
RHS
[name] [cname1] [value1] [cname2] [value2]
RANGES
[name] [cname1] [value1] [cname2] [value2]
QSECTION [cname1]
[vname1] [vname2] [value1] [vname3] [value2]
BOUNDS
?? [name] [vname1] [value1]
CSECTION [kname1] [value1] [ktype]
[vname1]
ENDATA
Here the names in capitals are keywords of the MPS format and names in brackets are custom defined names or values. A couple of notes on the structure:
All items surrounded by brackets appear in fields. The fields named “valueN” are numerical values. Hence, they must have the format
[+|-]XXXXXXX.XXXXXX[[e|E][+|-]XXX]
where
X = [0|1|2|3|4|5|6|7|8|9].
The MPS file consists of several sections where the names in capitals indicate the beginning of a new section. For example, COLUMNS denotes the beginning of the columns section.
Lines starting with an “*” are comment lines and are ignored by MOSEK.
The question marks represent keys to be specified later.
The sections QSECTION and CSECTION are MOSEK specific extensions of the MPS format.
The standard MPS format is a fixed format, i.e. everything in the MPS file must be within certain fixed positions. MOSEK also supports a free format. See Section B.5 for details.
A concrete example of a MPS file is presented below:
NAME EXAMPLE OBJSENSE MIN ROWS N obj L c1 L c2 L c3 L c4 COLUMNS x1 obj -10.0 c1 0.7 x1 c2 0.5 c3 1.0 x1 c4 0.1 x2 obj -9.0 c1 1.0 x2 c2 0.8333333333 c3 0.66666667 x2 c4 0.25 RHS rhs c1 630.0 c2 600.0 rhs c3 708.0 c4 135.0 ENDATA
Subsequently each individual section in the MPS format is discussed.
This is an optional section that can be used to specify the sense of the objective function. The OBJSENSE section contains one line at most which can be one of the following
MIN MINIMIZE MAX MAXIMIZE
It should be obvious what the implication is of each of these four lines.
This is an optional section that can be used to specify the name of the row that is used as objective function. The OBJNAME section contains one line at most which has the form
objname
objname should be a valid row name.
A record in the ROWS section has the form
? [cname1]
where the requirements for the fields are as follows:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
? | 2 | 1 | Yes | Constraint key |
[cname1] | 5 | 8 | Yes | Constraint name |
Hence, in this section each constraint is assigned an unique name denoted by [cname1]. Please note that [cname1] starts in position 5 and the field can be at most 8 characters wide. An initial key (?) must be present to specify the type of the constraint. The key can have the values E, G, L, or N whith ther following interpretation:
Constraint | ![]() |
![]() |
type | ||
E | finite | ![]() |
G | finite | ∞ |
L | -∞ | finite |
N | -∞ | ∞ |
In the MPS format an objective vector is not specified explicitly, but one of the constraints having the key N will be used as the objective vector c. In general, if multiple N type constraints are specified, then the first will be used as the objective vector c.
In this section the elements of A are specified using one or more records having the form
[vname1] [cname1] [value1] [cname2] [value2]
where the requirements for each field are as follows:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[vname1] | 5 | 8 | Yes | Variable name |
[cname1] | 15 | 8 | Yes | Constraint name |
[value1] | 25 | 12 | Yes | Numerical value |
[cname2] | 40 | 8 | No | Constraint name |
[value2] | 50 | 12 | No | Numerical value |
Hence, a record specifies one or two elements of A using the principle that [vname1] and [cname1] determines j and i respectively. Please note that [cname1] must be a constraint name specified in the ROWS section. Finally, [value1] denotes the numerical value of
. Another optional element is specified by [cname2], and [value2] for the variable specified by [vname1]. Some important comments are:
A record in this section has the format
[name] [cname1] [value1] [cname2] [value2]
where the requirements for each field are as follows:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[name] | 5 | 8 | Yes | Name of the RHS vector |
[cname1] | 15 | 8 | Yes | Constraint name |
[value1] | 25 | 12 | Yes | Numerical value |
[cname2] | 40 | 8 | No | Constraint name |
[value2] | 50 | 12 | No | Numerical value |
The interpretation of a record is that [name] is the name of the RHS vector to be specified. In general, several vectors can be specified. [cname1] denotes a constraint name previously specified in the ROWS section. Now, assume that this name has been assigned to the ith constraint and denotes the value specified by [value1], then the interpretation of
is:
Constraint | ![]() |
![]() |
type | ||
E | ![]() |
![]() |
G | ![]() |
|
L | ![]() | |
N |
An optional second element is specified by [cname2] and [value2] and is interpreted in the same way. Please note that it is not necessary to specify zero elements, because elements are assumed to be zero.
A record in this section has the form
[name] [cname1] [value1] [cname2] [value2]
where the requirements for each fields are as follows:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[name] | 5 | 8 | Yes | Name of the RANGE vector |
[cname1] | 15 | 8 | Yes | Constraint name |
[value1] | 25 | 12 | Yes | Numerical value |
[cname2] | 40 | 8 | No | Constraint name |
[value2] | 50 | 12 | No | Numerical value |
The records in this section are used to modify the bound vectors for the constraints, i.e. the values in and
. A record has the following interpretation: [name] is the name of the RANGE vector anhd [cname1] is a valid constraint name. Assume that [cname1] is assigned to the ith constraint and let
be the value specified by [value1], then a record has the interpretation:
Constraint | Sign of ![]() |
![]() |
![]() |
type | |||
E | - | ![]() |
|
E | + | ![]() | |
G | - or + | ![]() | |
L | - or + | ![]() |
|
N |
Within the QSECTION the label [cname1] must be a constraint name previously specified in the ROWS section. The label [cname1] denotes the constraint to which the quadratic term belongs. A record in the QSECTION has the form
[vname1] [vname2] [value1] [vname3] [value2]
where the requirements for each field are:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[vname1] | 5 | 8 | Yes | Variable name |
[vname2] | 15 | 8 | Yes | Variable name |
[value1] | 25 | 12 | Yes | Numerical value |
[vname3] | 40 | 8 | No | Variable name |
[value2] | 50 | 12 | No | Numerical value |
A record specifies one or two elements in the lower triangular part of the matrix where [cname1] specifies the i. Hence, if the names [vname1] and [vname2] have been assigned to the kth and jth variable, then
is assigned the value given by [value1] An optional second element is specified in the same way by the fields [vname1], [vname3], and [value2].
The example
![]() |
has the following MPS file representation
NAME qoexp ROWS N obj G c1 COLUMNS x1 c1 1 x2 obj -1 x2 c1 1 x3 c1 1 RHS rhs c1 1 QSECTION obj x1 x1 2 x1 x3 -1 x2 x2 0.2 x3 x3 2 ENDATA
Regarding the QSECTIONs please note that:
In the BOUNDS section changes to the default bounds vectors and
are specified. The default bounds vectors are
and
. Moreover, it is possible to specify several sets of bound vectors. A record in this section has the form
?? [name] [vname1] [value1]
where the requirements for each field are:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
?? | 2 | 2 | Yes | Bound key |
[name] | 5 | 8 | Yes | Name of the BOUNDS vector |
[vname1] | 15 | 8 | Yes | Variable name |
[value1] | 25 | 12 | No | Variable name |
Hence, a record in the BOUNDS section has the following interpretation: [name] is the name of the bound vector and [vname1] is the name of the variable which bounds are modified by the record. ?? and [value1] are used to modify the bound vectors according to the following table:
?? | ![]() |
![]() |
Made integer |
(added to ![]() | |||
FR | -∞ | ∞ | No |
FX | ![]() |
![]() |
No |
LO | ![]() |
unchanged | No |
MI | -∞ | unchanged | No |
PL | unchanged | ∞ | No |
UP | unchanged | ![]() |
No |
BV | 0 | 1 | Yes |
LI | ![]() |
∞ | Yes |
UI | unchanged | ![]() |
Yes |
is the value specified by [value1].
The purpose of the CSECTION is to specify the constraint
![]() |
in (B.1.1).
It is assumed that satisfies the following requirements. Let
![]() |
be vectors comprised of parts of the decision variables x so that each decision variable is a member of exactly one vector , for example
![]() |
Next define
![]() |
where must have one of the following forms
In general, only quadratic and rotated quadratic cones are specified in the MPS file whereas membership of the set is not. If a variable is not a member of any other cone then it is assumed to be a member of an
cone.
Next, let us study an example. Assume that the quadratic cone
![]() |
(B.1.5) |
and the rotated quadratic cone
![]() |
(B.1.6) |
should be specified in the MPS file. One CSECTION is required for each cone and they are specified as follows:
* 1 2 3 4 5 6 *23456789012345678901234567890123456789012345678901234567890 CSECTION konea 0.0 QUAD x4 x5 x8 CSECTION koneb 0.0 RQUAD x7 x3 x1 x0
This first CSECTION specifies the cone (B.1.5) which is given the name konea. This is a quadratic cone which is specified by the keyword QUAD in the CSECTION header. The 0.0 value in the CSECTION header is not used by the QUAD cone.
The second CSECTION specifies the rotated quadratic cone (B.1.6). Please note the keyword RQUAD in the CSECTION which is used to specify that the cone is a rotated quadratic cone instead of a quadratic cone. The 0.0 value in the CSECTION header is not used by the RQUAD cone.
In general, a CSECTION header has the format
CSECTION [kname1] [value1] [ktype]
where the requirement for each field are as follows:
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[kname1] | 5 | 8 | Yes | Name of the cone |
[value1] | 15 | 12 | No | Cone parameter |
[ktype] | 25 | Yes | Type of the cone. |
The possible cone type keys are:
Please note that a quadratic cone must have at least one member whereas a rotated quadratic cone must have at least two members. A record in the CSECTION has the format
[vname1]
where the requirements for each field are
Field | Starting | Maximum | Re- | Description |
position | width | quired | ||
[vname1] | 2 | 8 | Yes | A valid variable name |
The most important restriction with respect to the CSECTION is that a variable must occur in only one CSECTION.
This keyword denotes the end of the MPS file.
Using special bound keys in the BOUNDS section it is possible to specify that some or all of the variables should be integer-constrained i.e. be members of . However, an alternative method is available.
This method is available only for backward compability and we recommend that it is not used. This method requires that markers are placed in the COLUMNS section as in the example:
COLUMNS x1 obj -10.0 c1 0.7 x1 c2 0.5 c3 1.0 x1 c4 0.1 * Start of integer-constrained variables. MARK000 'MARKER' 'INTORG' x2 obj -9.0 c1 1.0 x2 c2 0.8333333333 c3 0.66666667 x2 c4 0.25 x3 obj 1.0 c6 2.0 MARK001 'MARKER' 'INTEND' * End of integer-constrained variables.
Please note that special marker lines are used to indicate the start and the end of the integer variables. Furthermore be aware of the following
Several issues related to the MPS format are not well-defined by the industry standard. However, MOSEK uses the following interpretation:
MOSEK supports a free format variation of the MPS format. The free format is similar to the MPS file format but less restrictive, e.g. it allows longer names. However, it also presents two main limitations:
To use the free MPS format instead of the default MPS format the MOSEK parameter mosek.iparam.read_mps_format should be changed.