# 14.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.

## 14.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
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.

### 14.5.1.1 Names¶

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] ) )* "'"


### 14.5.1.2 Expressions¶

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.

An expression:

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


## 14.5.2 Task section¶

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.

Format:

Task NAME
Anything goes here...


NAME is a the task name.

## 14.5.3 Objective section¶

The Objective section defines the objective name, sense and function. The format:

"Objective" NAME?
( "Minimize" | "Maximize" ) EXPR


For example:

Objective 'obj'
Minimize x1 + 0.2 x2 + < M1 ; X1 >


## 14.5.4 Constraints section¶

The constraints section defines a series of constraints. A constraint defines a term $$A\cdot x + b\in K$$. For linear constraints A 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 sub-section.

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.

For example:

Constraints
'c1' [0;10] x1 + x2 + x3
[0] 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 N

• RSOC(N) Rotated second order cone of dimension N

• PSD(N) Symmetric positive semidefinite cone of dimension N. This contains N*(N+1)/2 elements.

• PEXP Primal exponential cone of dimension 3

• DEXP Dual exponential cone of dimension 3

• PPOW(N,P) Primal power cone of dimension N with parameter P

• DPOW(N,P) Dual power cone of dimension N with parameter P

• ZERO(N) The zero-cone of dimension N.

"Constraints"
NAME? "[" DOMAIN "]" EXPR_LIST


For example:

Constraints
'K1' [SOC(3)] x1 + x2 ; x2 + x3 ; x3 + x1
'K2' [RSOC(3)]
x1 + x2
x2 + x3
x3 + x1


## 14.5.5 Variables section¶

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


## 14.5.6 Integer section¶

This section contains a list of variables that are integral. For example:

Integer
x1 x2 x3


## 14.5.7 SymmetricMatrixes section¶

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 ")" )*
...


For example:

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)


## 14.5.8 Solutions section¶

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:

• interior Interior solution, the result of an interior-point solver.

• basic Basic solution, as produced by a simplex solver.

• integer Integer solution, the solution to a mixed-integer problem. This does not define a dual solution.

Following values for PROSTA are supported:

• unknown The problem status is unknown

• feasible The problem has been proven feasible

• infeasible The problem has been proven infeasible

• illposed The problem has been proved to be ill posed

• infeasible_or_unbounded The problem is infeasible or unbounded

Following values for SOLSTA are supported:

• unknown The solution status is unknown

• feasible The solution is feasible

• optimal The solution is optimal

• infeas_cert The solution is a certificate of infeasibility

• illposed_cert The solution is a certificate of illposedness

Following values for STATUS are supported:

• unknown The value is unknown

• super_basic The value is super basic

• at_lower The value is basic and at its lower bound

• at_upper The value is basic and at its upper bound

• fixed The value is basic fixed

• infinite The value is at infinity