SELES Overview
SELES facilitates the specification and execution of landscape simulation models. It is not a landscape model itself, but rather a tool to build models — for example, the SELES Spatial Timber Supply Model (STSM).
A SELES model consists of:
- a set of raster layers and global variables that define the model state, and
- a set of landscape events that define model dynamics.
Two General Components
Every dynamic SELES model has two general components:
1. Initial State
The set of initial landscape conditions before a simulation begins. This may include spatial and non-spatial (global) variables and constants. Some state variables are dynamically modified during a simulation; others remain static. For example:
- In a forest change model, stand age may change over time while elevation remains constant.
- In an erosion model, elevation itself may be dynamic.
2. Landscape Events
Each process of landscape change — forest succession, fire, timber harvesting — is specified as a semi-independent sub-model called a landscape event. The definition of a landscape event specifies:
- its recurrence frequency and spatial domain (when and where it occurs),
- how it spreads, and
- its effect on model state.
All feedback between processes is accomplished through state changes to raster layers and global variables. There is no direct inter-event communication.
Any number of rasters may be used in a model, but they must represent the same geographic location and resolution (e.g. vegetation cover, elevation, time-since-disturbance).
SELES provides a declarative modelling language for describing landscape event properties. The simulation engine interprets and executes these specifications, producing changes over simulated time to the landscape state.
Figure 2 — Components of a SELES model with three spatial variables and two landscape events, as interpreted and executed by the SELES discrete event simulation engine. The landscape events do not interact directly with each other — they interact only through changes to shared state variables.
(Diagram from original documentation — to be recreated)
Landscape events create an inherently modular structure that facilitates description, verification, and re-use. Table 1 gives an example for a simple Fire event.
Table 1 — Informal specification for a simple Fire event
| Property | Specification |
|---|---|
| Layers required | ForestAge |
| Global variables | WindSpeed, WindDirection |
| Cluster variables | FireSize |
| ReturnTime | 5 years on average, negative exponential distribution |
| ProbInit | Zero in unforested cells; linearly increasing with ForestAge; avg 0.001 in young forest, 0.01 in old forest |
| NumClusters | 1 (one fire per fire year) |
| FireSize | 200 cells on average, normally distributed (std. dev. = 20) |
| Transitions | if (FireSize > 0) — burn only if fire still needs to be bigger; sets ForestAge = 0, decrements FireSize |
| SpreadTime | Function of WindSpeed |
| SpreadLocation | All 8 adjacent cells |
| SpreadProb | Probability of 1 in WindDirection, linearly decreasing to 0 in opposite direction |
SELES models are usually stochastic, but can range from completely random to entirely deterministic. Stochastic models may require a Monte Carlo approach, since any single run represents only one possible sequence of change. Models can mix random and deterministic components — for example, starting from statistical representations of most processes and progressively replacing them with more mechanistic descriptions as understanding develops.
2.1 Discrete Event Simulation
All SELES models are executed by the discrete event simulation engine, which maintains a priority queue of scheduled events in chronological order. The current simulation time is always the time of the event at the head of the queue.
Before a simulation starts, initial events are loaded onto the queue. When the simulation starts (at time 0), the engine processes events in order:
- Remove the next event from the queue.
- Execute the event — this typically involves:
- determining event location (where),
- making state changes (what),
- spreading the event if required (where), and
- scheduling the next event instance (when).
After all events at the current time step are completed, time advances to the next event on the queue. Time progresses in discrete steps of varying duration; multiple events may be scheduled at the same time step.
The simulation continues until the event queue is empty or the specified simulation duration is reached.
Figure 3 — The "event loop" performed by the SELES discrete event simulation engine. Events are processed in chronological order. The specific behaviour of each event is determined by its specification.
(Diagram from original documentation — to be recreated)
The event queue must handle potentially millions of events (e.g. all cells on the active fronts of multiple spreading fires at many time points). In SELES 10, the event queue was re-implemented using red-black trees to increase efficiency.
2.2 General Inputs and Outputs
The primary inputs and outputs are raster grid files and tab-delimited tables.
Tabular outputs may be static (e.g. mean area burned over a run) or dynamic (e.g. stand age distribution each decade). Output tables can be loaded into a database or spreadsheet for post-simulation analysis, or used as input to a subsequent SELES model.
Spatial outputs may also be static or dynamic. For example, a model may:
- Save a single raster as the final result of a simulation (e.g. a modelled future road network).
- Schedule periodic raster output to produce a raster time-series (e.g. stand age each decade).
2.3 General Assumptions and Limitations
SELES models can range from simple to complex, but require careful thought to produce a model that is clearly interpretable. In addition to the usual caveats that apply to any modelling work, consider the following:
-
No semantic checking. Some parameter-bounds checking is provided, but SELES does not verify that a model is doing anything sensible. Run models on a test suite of data for which the outcome can be easily verified — including boundary conditions and specific behavioural tests for each landscape event.
-
No interpretation of raster values. SELES does not interpret the values in state raster layers. Care should be taken to apply the correct interpretation and units. This is especially important for categorical data, where a cell value indicates a class, not a magnitude. Use constants and legends to ensure the correct index is used for each category.
-
Undefined cells. Raster cell values may be "undefined" (e.g. −1) to delineate areas outside the study area or with no data. SELES makes no a priori assumption about how to interpret such values, but landscape events can easily be written to avoid operations in undefined cells. A binary study-area layer is often a convenient tool.
-
All rasters must share the same grain and extent. All raster layers in a single model must have the same cell size and the same number of rows and columns. The appropriate spatial scale is the modeller's responsibility. Note: SELES does provide some capability to rescale layers and align georeferencing information between two layers.