A polytope in the polymake system is represented by a printable ASCII file. It is divided into sections, separated by empty lines. Each section represents some property of the polytope. It consists of a title line, containing the property name, and optional data lines.
Lines starting with # are treated as comments. They can be arbitrarily intermixed with the data
lines. However, processing the data by polymake moves all comment lines above the title of the respective
section.
Section names may only contain alphanumeric characters (letters, digits, underscore). By convention, the names of standard data sections are written in upper case.
The contents of a section can be arbitrary in principle, as polymake doesn't impose any general syntactic rules. However, using a property from within a rule implies that the property's data will eventually be parsed by the corresponding routine, which obviously expect it in some well-defined format. Therefore each section declaration contains the type description among other stuff.
Currently this description serves for documentation purposes only, and the real syntactical check of the data is postponed until the first read access to the section. Future versions of polymake might employ stricter data checking policies.
Usually, when the description of a polytope doesn't contain some property, it doesn't say anything definite about the polytope. It merely means that the value of this property is unknown; once asked for this, polymake will try to compute it from available data. This should clearly be distinguished from the situation where some property is known to be missing or undefined for a given polytope. The latter case is expressed by means of so called negated sections. Syntactically they have the same form as a dataless (empty) section, but with its name prepended by an exclamation mark.
Examples where negated sections can occur are boolean properties of polytopes (simplicial, neighborly, etc.), or the extremal value of the objective function in an unbounded linear program.
Not every property is worth storing in the data file. There are various motives for discarding properties. Some properties don't carry any new interesting information about the polytope; rather they hold intermediate results of complex algorithms or alternative representations of the data already available elsewhere.
The default behavior of polymake is to store all available data. So the non-persistent properties are to be declared explicitly. The lifetime scope of a non-persistent section is restricted to a single rule chain.
Non-persistent sections occasionally occur in a data file. In this case they are discarded at first sight, and an appropriate warning is issued.
Pseudo-targets are similar to non-persistent sections in that they can't appear in the data file and their names obey the same syntax rules. The difference is that they can never exist physically, even not temporarily. They may, however, occur in the output property lists of rules, and it's the only purpose they are good for.
Usually, a rule is executed by polymake if it supplies a property the user is asking for. But some rules don't produce any new properties, e.g., all visualization algorithms. If such a rule were declared with an empty output list, polymake could never apply it. Therefore such rules are declared as providing (in fact, promising to provide) some property which will never be physically created. Then those rules can be invoked via the same request-resolving mechanism as the normal producing rules. This way one can see the pseudo-targets as a kind of labels for certain rules.
Since requesting for a pseudo-target forces the execution of some rule labeled with it, pseudo-targets can be also used in another context: to distinguish between several rules providing the same output properties. Normally, polymake has its internal algorithm for making decisions which rule to take. Specifying a pseudo-target attached to one of the rules in question will overrule this algorithm and force polymake to choose the corresponding rule.
By convention, names of pseudo-targets labeling some algorithms consist of lower-case letters, as opposed to real data sections and pseudo-targets triggering some (visualization) actions.
Note: The pseudo-target concept might be changed or replaced by another adequate mechanism in future releases of polymake.
These are sections containing some information about the data file rather than problem-related data. By convention, their names start with underscore. Unless you intentionally want to influence the way polymake works, you shouldn't change or delete them. Any special section may change its semantics or disappear in future versions of polymake without announcement.
Currently the following special sections are recognized by polymake: