Model Structure and Syntax

A dynamic SELES model consists of a set of interacting files:

File type	Purpose	Reference
Scenario scripts (.scn)	Sequence of commands to load grids/models, run simulations, change parameters and working folders	Section 2
Raster grids	Spatial input and output data (GeoTiff preferred)	Section 3
Dynamic model files (.sel)	Define the spatio-temporal state space: spatial/global constants and variables, landscape events	Section 4
Landscape event files (.lse)	Define the dynamic processes acting on the landscape, as properties and expressions	Section 5
Legend files	Named constants associated with raster values; usable in input tables	Section 4.6
Input table files (.txt)	Tab-separated parameter tables	Section 3.1
Macro files (.ce)	Reusable functional expressions	Section 6

Figure 7 — SELES models consist of scenario files that load spatial grids and dynamic model configuration files, and issue various commands. Dynamic model files in turn load landscape events, legends, input tables, and macro files.

(Diagram from original documentation — to be recreated)

---

1.1 How to Understand Syntax Specifications

The following notation is used throughout this reference for describing file syntax:

Notation	Meaning
Punctuation shown as-is	Must be provided exactly as shown
#Factor	A numeric value
{ variables}	Optional element
item*	Item may be repeated zero or more times
item+	Item may be repeated one or more times (at least once)
<Label>	User-defined value — substitute an appropriate name, path, or number
%value	A logical value (true or false)
"text"	A literal text string

---

1.2 General Syntax Rules

These rules apply to all SELES language files (.scn, .sel, .lse, .ce):

• Comments are for documentation only and have no effect. Use /* … */ for block comments or // for line-end comments. Example:

  /* This is a block comment */
  x = 1  // this is a line comment; "x = 1" is not a comment

  Well-documented models often consist of at least 50% comments.

• White space (extra spaces, tabs, carriage returns) is ignored and can be used for formatting. Consistent indentation (e.g. three spaces per nesting level) is critical for readability. Prefer spaces over tabs — different programs may interpret tab depth differently.

• Keywords are shown in all capitals (e.g. GLOBAL VARIABLES:). The parser is not case sensitive, but keywords must otherwise be spelled exactly as shown. Portions of keywords shown in italics are optional (e.g. MINIMUM indicates that either MIN or MINIMUM is valid).

• Commands (except the model type declaration at the top of each file) are generally optional. The syntax description gives the default value for each command.

• Each command or expression must generally be on a separate line (separated by a carriage return). Some expressions may span multiple lines (e.g. IF expressions).

• The last line of every file must be blank (end with a carriage return). If the LSEditor cannot locate a syntax error, check this first.

• Labels in angle brackets (e.g. <Variable>) indicate user-defined items that the modeller must substitute.

• Labels preceded by # indicate numbers. In most cases, numbers, constants, and arithmetic expressions are valid. Examples: 2, 3.5, 1/365.25, (5*-3)^4/6, MaxAge+1, 1/NUMCELLS.

• Number Pairs and Number Lists may be enclosed in optional brackets (), with each number separated by a comma. Examples: (1,2,5,6) or 1,2,5,6.

• Labels preceded by % indicate logical values. Valid true values: 1, ON, TRUE. Valid false values: 0, OFF, FALSE.

• Text in double quotes indicates a literal text value (e.g. "This is a literal text string").

• File names containing spaces must be enclosed in double quotes. As a general rule, spaces in filenames should be avoided.

• Non-uppercase labels (i.e. not all capitals) indicate structures defined elsewhere in the section.