`polymake` allows to store the objects in files. Although the preferred way to handle objects is to create them using construction functions (clients), sometimes you might want to manually type in the initial properties. Hence we describe the file format here. Please be aware that in one of the next `polymake` releases we will switch to XML file format.

Currently `polymake` works with plain ASCII files. One data file corresponds exactly to one object, the name of the file is identical to the object name (plus application-dependent suffix, e.g. .poly for polytopes.)

Lines starting with # are treated as comments. They can be arbitrarily intermixed with the data lines. After the file has been once processed by `polymake`, the comment lines will move in front of the section headers.

The object properties are stored as sections, separated by empty lines. The first line consists of a single word, the property name. It is followed by the printable representation of the property value. The latter depends on the property type. To learn of the format for certain property, find its description on the "Properties" page of the correspoding object type and follow the hyperlink to the right of the property name.

As of now, the syntax check of the property value is done only when the property is requested by a client program. This way you can make a typo in the data file which stays undiscovered for a longer period of time. The upcoming XML representation will be, in contrary, validated using an adopted Scheme mechanism.

### Undefined properties

Usually, when the object representation doesn't contain some property, it doesn't say anything definite about it. It merely means that this property was not needed so far;is unknown; once requested for it, `polymake` will try to compute it from available properties. This should clearly be distinguished from the situation where some property is known to be missing or undefined for a given object. The latter case is expressed by special data line

    ==UNDEF==

For example, MAXIMAL_VALUE or MINIMAL_VALUE of the objective function applied to an unbounded polyhedron will have this undefined value.

### Temporary properties

Some properties are declared as temporary. `polymake` does not store them in the data file normally. If `polymake` encounters temporary properties in the input file, it removes them before every other processing and issues a corresponding warning.

Under seldom circumstances (mostly for testing purposes) you might want to supply the values of temporary properties via the data file. Then you have to use the command line option --keep-temporary.

### Undeclared properties

A data file is allowed to contain sections with unknown names, that is, not declared as a property in the rules. The only requierement to such sections is that the header line consists of a single syntactically correct identifier (only alphanumeric characters, the first being a letter.) The unknown properties are kept untouched; you can even read them using the standard methods.

This way you can work with data files created by somebody else who has written own extensions to `polymake` rules and introduced new properties, without having to install this extensions.

### File preamble

The very first lines of a data file may contain a preamble with metadata. It is created automatically by `polymake` when it writes the file. The following preamble lines are recognized:

_application NAME
The name of the application which created the file
_type OBJECT_TYPE
The type of the object stored in the file
_version n.n
Version of `polymake` which has last worked with the file. This may be used for automatical file conversion, in the case the file format has changed between the releases.

If you create the data file manually, you must supply the application name unless it is your default application. Similarly, you must specify the object type if it differs from the default type of the application.