16.5 The PTF Format¶
The PTF format is a new human-readable, natural text format. Its features and structure are similar to the OPF format, with the difference that the PTF format does support semidefinite terms.
16.5.1 The overall format¶
The format is indentation based, where each section is started by a head line and followed by a section body with deeper indentation that the head line. For example:
Header line Body line 1 Body line 1 Body line 1
Section can also be nested:
Header line A Body line in A Header line A.1 Body line in A.1 Body line in A.1 Body line in A
The indentation of blank lines is ignored, so a subsection can contain
a blank line with no indentation. The character
# defines a line
comment and anything between the
# character and the end of the
line is ignored.
In a PTF file, the first section must be a
Task section. The order
of the remaining section is arbitrary, and sections may occur multiple
times or not at all.
MOSEK will ignore any top-level section it does not recognize.
In the description of the format we use following definitions for name strings:
NAME: PLAIN_NAME | QUOTED_NAME PLAIN_NAME: [a-zA-Z_] [a-zA-Z0-9_-.!|] QUOTED_NAME: "'" ( [^'\\\r\n] | "\\" ( [\\rn] | "x" [0-9a-fA-F] [0-9a-fA-F] ) )* "'"
An expression is a sum of terms. A term is either a linear term (a coefficient and a variable name, where the coefficient can be left out if it is 1.0), or a matrix inner product.
EXPR: EMPTY | [+-]? TERM ( [+-] TERM )* TERM: LINEAR_TERM | MATRIX_TERM
A linear term
LINEAR_TERM: FLOAT? NAME
A matrix term
MATRIX_TERM: "<" FLOAT? NAME ( [+-] FLOAT? NAME)* ";" NAME ">"
Here the right-hand name is the name of a (semidefinite) matrix variable, and the left-hand side is a sum of symmetric matrixes. The actual matrixes are defined in a separate section.
Expressions can span multiple lines by giving subsequent lines a deeper indentation.
For example following two section are equivalent:
# Everything on one line: x1 + x2 + x3 + x4 # Split into multiple lines: x1 + x2 + x3 + x4
The first section of the file must be a
Task. The text in this
section is not used and may contain comments, or meta-information from
the writer or about the content.
Task NAME Anything goes here...
NAME is a the task name.
Objective section defines the objective name, sense and function. The format:
"Objective" NAME? ( "Minimize" | "Maximize" ) EXPR
Objective 'obj' Minimize x1 + 0.2 x2 + < M1 ; X1 >
The constraints section defines a series of constraints. A constraint
defines a term \(A\cdot x + b\in K\). For linear constraints
is just one row, while for conic constraints it can be multiple
rows. If a constraint spans multiple rows these can either be written
inline separated by semi-colons, or each expression in a separete
Simple linear constraints:
"Constraints" NAME? "[" [-+] (FLOAT | "Inf") (";" [-+] (FLOAT | "Inf") )? "]" EXPR
If the brackets contain two values, they are used as upper and lower bounds. It they contain one value the constraint is an equality.
Constraints 'c1' [0;10] x1 + x2 + x3  x1 + x2 + x3
Constraint blocks put the expression either in a subsection or inline. The cone type (domain) is written in the brackets, and MOSEK currently supports following types:
SOC(N)Second order cone of dimension
RSOC(N)Rotated second order cone of dimension
PSD(N)Symmetric positive semidefinite cone of dimension
N. This contains
PEXPPrimal exponential cone of dimension 3
DEXPDual exponential cone of dimension 3
PPOW(N,P)Primal power cone of dimension
DPOW(N,P)Dual power cone of dimension
ZERO(N)The zero-cone of dimension
"Constraints" NAME? "[" DOMAIN "]" EXPR_LIST
Constraints 'K1' [SOC(3)] x1 + x2 ; x2 + x3 ; x3 + x1 'K2' [RSOC(3)] x1 + x2 x2 + x3 x3 + x1
Any variable used in an expression must be defined in a variable section. The variable section defines each variable domain.
"Variables" NAME "[" [-+] (FLOAT | "Inf") (";" [-+] (FLOAT | "Inf") )? "]" NAME "[" DOMAIN "]" NAMES For example, a linear variable
Variables x1 [0;Inf]
As with constraints, members of a conic domain can be listed either inline or in a subsection:
Variables k1 [SOC(3)] x1 ; x2 ; x3 k2 [RSOC(3)] x1 x2 x3
This section contains a list of variables that are integral. For example:
Integer x1 x2 x3
This section defines the symmetric matrixes used for matrix coefficients in matrix inner product terms. The section lists named matrixes, each with a size and a number of non-zeros. Only non-zeros in the lower triangular part should be defined.
"SymmetricMatrixes" NAME "SYMMAT" "(" INT ")" ( "(" INT "," INT "," FLOAT ")" )* ...
SymmetricMatrixes M1 SYMMAT(3) (0,0,1.0) (1,1,2.0) (2,1,0.5) M2 SYMMAT(3) (0,0,1.0) (1,1,2.0) (2,1,0.5)
Each subsection defines a solution. A solution defines for each constraint and for each variable exactly one primal value and either one (for conic domains) or two (for linear domains) dual values. The values follow the same logic as in the MOSEK C API. A primal and a dual solution status defines the meaning of the values primal and dual (solution, certificate, unknown, etc.)
The format is this:
"Solutions" "Solution" WHICHSOL "ProblemStatus" PROSTA PROSTA? "SolutionStatus" SOLSTA SOLSTA? "Objective" FLOAT FLOAT "Variables" # Linear variable status: level, slx, sux NAME "[" STATUS "]" FLOAT (FLOAT FLOAT)? # Conic variable status: level, snx NAME "[" STATUS "]" FLOAT FLOAT? ... "Constraints" # Linear variable status: level, slx, sux NAME "[" STATUS "]" FLOAT (FLOAT FLOAT)? # Conic variable status: level, snx NAME "[" STATUS "]" FLOAT FLOAT? ...
Following values for
WHICHSOL are supported:
interiorInterior solution, the result of an interior-point solver.
basicBasic solution, as produced by a simplex solver.
integerInteger solution, the solution to a mixed-integer problem. This does not define a dual solution.
Following values for
PROSTA are supported:
unknownThe problem status is unknown
feasibleThe problem has been proven feasible
infeasibleThe problem has been proven infeasible
illposedThe problem has been proved to be ill posed
infeasible_or_unboundedThe problem is infeasible or unbounded
Following values for
SOLSTA are supported:
unknownThe solution status is unknown
feasibleThe solution is feasible
optimalThe solution is optimal
infeas_certThe solution is a certificate of infeasibility
illposed_certThe solution is a certificate of illposedness
Following values for
STATUS are supported:
unknownThe value is unknown
super_basicThe value is super basic
at_lowerThe value is basic and at its lower bound
at_upperThe value is basic and at its upper bound
fixedThe value is basic fixed
infiniteThe value is at infinity