12.5 The PTF Format

The PTF format is a human-readable, natural text format suuporting all of MOSEK optimization problems in conic form, possibly with integer variables and disjunctive constraints.

12.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. Names

In the description of the format we use following definitions for name strings:

PLAIN_NAME: [a-zA-Z_] [a-zA-Z0-9_-.!|]
QUOTED_NAME: "'" ( [^'\\\r\n] | "\\" ( [\\rn] | "x" [0-9a-fA-F] [0-9a-fA-F] ) )* "'" 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 )*

A linear term


A matrix term


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:
  + x2
  + x3
  + x4

12.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.


   Anything goes here...

NAME is a the task name.

12.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 >

12.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:

  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:

  '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.


For example:

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

12.5.5 Variables section

Any variable used in an expression must be defined in a variable section. The variable section defines each variable domain.

   NAME "[" [-+] (FLOAT | "Inf") (";" [-+] (FLOAT | "Inf") )? "]"

   For example, a linear variable
   x1 [0;Inf]

As with constraints, members of a conic domain can be listed either inline or in a subsection:

   k1 [SOC(3)] x1 ; x2 ; x3
   k2 [RSOC(3)]

12.5.6 Integer section

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

   x1 x2 x3

12.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.

   NAME "SYMMAT" "(" INT ")"  ( "(" INT "," INT "," FLOAT ")" )*

For example:

   M1 SYMMAT(3) (0,0,1.0) (1,1,2.0) (2,1,0.5)
   M2 SYMMAT(3)

12.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:

   "Solution" WHICHSOL
      "ProblemStatus" PROSTA PROSTA?
   "SolutionStatus" SOLSTA SOLSTA?
   "Objective" FLOAT FLOAT
      # Linear variable status: level, slx, sux
      # Conic variable status: level, snx
         "[" STATUS "]" FLOAT FLOAT?
      # Linear variable status: level, slx, sux
      # Conic variable status: level, snx
         "[" 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