Population grammar

A sip file supplies the initial instance population for exactly one scenario. It opens with the scenario name and then supplies one block per populated class.

Here is the overall shape of a file, trimmed down from the three bank elevator scenario:

scenario : Three Bank1
--
Bank
Name | Passenger load time | Block clear time | Max close attempts | Average cabin speed | Average stop duration
--
L { [Lower Floors] [4.0] [2.0] [25] [7.0] [9.0] }
P { [Penthouse]    [4.0] [2.0] [25] [7.0] [9.0] }
F { [Freight]      [7.0] [5.0] [25] [5.0] [14.0] }
--
Shaft
ID | In service | R1>Bank
--
{ [S1] [true] @L } R53> NO TRANSFER > IDLE
{ [S2] [true] @L } R53> NO TRANSFER > IDLE
--
Floor
Name | Height
--
{ [PH] [35.2] }
{ [8]  [32.0] }
--

The top level grammar term is:

si_population = EOL* scenario (class_def instance_block)+ EOF

So after any leading blank lines we have the scenario declaration followed by one or more class populations. Each class population is a pair of terms: a class_def giving the class name and its column header, and an instance_block giving one row per instance. The two always travel together and in that order.

At least one class population is required. An otherwise valid file that names a scenario and stops there will not parse.

Separators

Everything is delimited by an unindented -- separator on its own line:

block_end = "--" EOL*

A -- appears in three places: after the scenario line, after each column header, and after each instance block. That last one is easy to forget — the final instance block in the file needs its closing -- just like all the others.

Since block_end ends in EOL*, you can leave as many blank lines as you like after a separator to space the file out. The elevator scenario doesn't bother — it runs one class population straight into the next, letting the -- separators do the visual work.

Nothing is indented

Unlike the xcm class model file, a sip file has no indented terms at all. Every line starts in column one. Alignment within a row is achieved with padding spaces inside the braces, which the parser discards. See Instance grammar.

Order

Classes may be listed in any order and the parser preserves the order it finds when it hands back the result. Each class should appear exactly once. Nothing in the grammar stops you from opening a second block for a class you have already populated, but the parser keys its result by class name, so the later block silently replaces the earlier one and those instances are lost. See Parser output.