Model Builder's Guide Chapter 1

= Building Spatio-temporal Models with SELES =

The Model Building Process
We recommend the following steps as a logical progression for model development. These steps assure that all aspects of a simulation scenario are identified and properly specified:

1. Problem statement : A simulation model should have a focus problem. This helps to identify the type of information required; an appropriate spatial scale (extent and resolution); the types of processes to be modelled; and the appropriate model type (e.g., deterministic vs. statistical) and detail for each of these processes. Problem statements can be simple or complex. Some examples include (i) examine the consequences of departures from the assumptions of commonly used models of fire frequency; (ii) investigate the effects of logging, grazing and forest encroachment on grassland biodiversity; or (iii) estimate the impacts of different harvesting systems over time on suitable habitat for mountain caribou. Identifying the processes to include (or exclude) is critical. Depending on level of detail, one process may be represented as one or more landscape events, or multiple processes may be represented in a single landscape event. Try to write an informal but precise description of each event. Primary model outputs should be identified, which are directly related to the problem questions, along with indications of how they will be analyzed. Output can include a sequence of spatial layers for each model execution or a single variable tracked over time. Most SELES scenarios involve some stochasticity, and so may require multiple-runs in a Monte-Carlo fashion. It is easy to output vast quantities of data, so careful design of model outputs is crucial.

2. Information gathering : The problem(s) to be addressed usually suggest a starting set of spatial and aspatial information that needs to be assembled as well as some of the processes that are important determinants of the landscape dynamics under study. The extent and resolution selected will affect the detail required of the spatial information as well as the processes to be modelled. More detail will be more precise, but processes will also have to be more detailed and simulations will be more time-consuming. In many situations the level of detail of existing spatial information will dictate the resolution of the model scenario. If process knowledge is limited, higher precision may come at the cost of lower accuracy.

3. Model prototyping : Model development can (and usually should) begin before the information gathering stage is complete. SELES provides a number of static model generators that are useful for model development, verification and refinement, but may also be used to provide simplified, synthetic spatial information during model prototyping. Such synthetic maps can be used as "placeholders" in the model prototype until the real data has been assembled. During this stage, the overall behaviour of process models should be defined, and the type of impacts they will have on the landscape. The impacts will depend on the problem statement. For example, a fire model could cause changes to species, age, understory community, percentage of canopy closure, amount of coarse woody debris, wood volume, etc. Process models can be formally described using diagrams, equations and natural language. It is important to unambiguously describe processes and avoid vague descriptions of model behaviour. Formal model descriptions facilitate the translation of verbal and conceptual models into the SELES modelling language, and also serve as a medium for communicating models to non-modellers, such as ecosystem experts, decision makers and people representing various interests, and is essential for any publications.

4. Initial scenario : An initial baseline scenario should be assembled, containing the initial conditions (real data or synthetic) and process model prototypes. Once the scenario is set up, the SELES simulation engine can be used to run and test the prototypes. This scenario provides a basis for model refinement and elaboration.

5. Model refinement : The modelling process is iterative. Construction of the initial scenario forms the first loop. At this point, modellers have often identified new ideas for improvement and additional information that must be gathered. It is fruitful to go over all steps again. Revisiting the problem statement will ensure that the project remains on track. There is a tendency to include more and more details in a model, but it is unwise to include more detail than necessary to address the problem, since this will probably increase uncertainty in the model results. The information required to parameterize process models increases with level of detail. According to Occam’s razor, the best models are those with just enough detail to capture the dynamics of interest, and no more. We find it useful to create a table with state components (layer or variable names) on one axis and process models (event and agent names) on the other. Notations in each table entry indicate if the state component influences a process, if a process modifies the state component, or both. For example, the state component Aspect may influence the process Fire, while the state component Yield may be modified by the process TimberHarvesting.

The SELES Paradigm
SELES is a system intended to facilitate the specification and execution of landscape simulation models. SELES is not a landscape model itself, but rather a tool to build models. A SELES model consists of a set of raster layers and global variables that define the model state, and a set of landscape events and agents that define model dynamics. Each simulation scenario in SELES has two main components: 1. Initial state : This is the set of initial landscape conditions before a simulation begins (e.g. forest type, topography). It may be current information, historical, projected, hypothetical, etc., and includes spatial layers and aspatial (global) variables and constants. Some of this state may be dynamically modified during a simulation, while other components may be static. For example, a model of forest change may include forest stand age, which may change over time, and topography, which remains constant. In an erosion model, however, topography may be dynamic.

2. Landscape Events and Agents : Each agent or process of landscape change (e.g. forest succession, fire, timber harvesting) is specified as a semi-independent sub-model called a landscape event or a landscape agent. The definition of a landscape event specifies its recurrence frequency and spatial domain (i.e., when and where the event should occur), how it spreads and its effect on model state. Landscape agent definitions specify starting locations and numbers of individuals and populations, and rules governing movement, mortality and reproduction. All feedback mechanisms between processes are accomplished through state changes to raster layers and global variables, with no direct inter-event communication.

Any number of rasters may be incorporated in a model, but they must represent the same geographic location and resolution. Generally rasters have integer values, but SELESv3.3 now supports real-valued rasters (see the Scenario Reference for information on how to scale a real-value raster to integer-values during load). For example, GIS map layers such as vegetation cover, digital elevation models, or time-since-disturbance are commonly used as SELES state variables. Synthetic layers can be produced using the SELES static pattern generators and statistical summary models (see Section 5).

SELES provides a declarative modelling language for describing the properties of landscape events and agents, and the simulation engine interprets and executes these specifications, resulting in changes over simulated time to the landscape state. The relationships between the components of a SELES model are shown in Figure 1. SELES models are usually stochastic, but can range from completely random to entirely deterministic. For this reason, SELES models may require a Monte Carlo approach, since any single run will represent only one possible sequence of change. One of the strengths of building models in SELES is the ability to mix random and deterministic components in the same modelling framework. For example, a theoretical or empirical model can be prototyped quickly, primarily employing statistical representations of most processes. As greater understanding of the system is developed, this statistical behaviour can be progressively replaced by a more mechanistic approach to describing each process. Earlier models can then be used as benchmarks from which to judge the increase in predictability introduced by the subsequent refinements.

Figure 1. Components of a SELES model with three spatial state variables and two landscape events. This model is interpreted and executed by the SELES discrete event simulation engine.

Simulation scenarios built from a set of landscape events and agents automatically have a modular structure and so are relatively easy to describe and verify. We recommend that modellers attempt to write an informal, but precise version of each sub-model early on in the model building process. Table 1 gives an example for a simple Fire event. Each landscape event and agent is a semi-independent model of a single process, and thus provides substantial opportunity for re-use and adaptation.

Table 1: Informal specification for a simple Fire event.



SELES Discrete Event Simulation Overview
All SELES models are executed by the discrete event simulation engine. Understanding how this engine works is critical to successfully building a SELES model. The simulation engine uses a priority queue to maintain scheduled future events in chronological order. The current time is always the time of the current event (i.e. the one at the head of the queue). During a simulation, events are scheduled to occur at some future time (i.e. events are added to the queue). When it is time to execute an event (i.e. the event is at the head of the queue), the simulation engine removes it from the queue, and executes the behaviour specified for that event. This behaviour may involve altering state variables and scheduling one or more future events (Figure 2). Time advances in discrete steps as the engine processes events the queue, although each step can have a different duration and multiple events may be scheduled for the same time.



Figure 2. The "event loop" performed by the SELES discrete event simulation engine to process events in chronological order during simulation. The specific behaviour of an event is determined by the event or agent specification.

SELES Model Format
SELES models consist of a set of interacting files containing landscape events and agents, model configuration information and scenario scripts (Figure 3). Static models are used to either generate static layers or summary information. A dynamic model configures a simulation by defining the spatial and aspatial state-space, and loading landscape events and agents. Landscape events and agents model the dynamic processes acting in the landscape. These are primarily specified with their properties (see sections 6-8). Event/agent properties and some static models are built using functional and procedural expressions (see section 9). Since scenario scripting is of interest to both model builders and users, it is described in the companion SELES Scenario Reference document.

Assumptions and Limitations
SELES models can range from simple to complex, but require careful thought to produce a model that can be clearly interpreted. In addition to the caveats that go along with any modelling, the following limitations should be considered when modelling with SELES:

1. Some error checking is provided to ensure that parameters are within bounds, etc. However, there is no checking to ensure that your model is doing anything sensible! Always run your models on a “test suite” of data for which the model outcome can be easily verified. These should include, but not be limited to, testing boundary conditions for the model (e.g. the simplest possible initial conditions for the model), and testing specific behavioural characteristics for each landscape event in the model. Produce output specifically designed to verify model behaviour.

2. SELES does not interpret the values on state raster layers, and care should be taken to apply the correct interpretation and units for these values. This is particularly important for categorical data, where the numerical value in a cell only indicates which class the cell belongs to, not the magnitude of some variable. Constants, especially legends associated with raster files, are useful to ensure that the correct index is used for each category.

3. Cells in a raster may be defined as “undefined”. This is normally used to delineate areas that are not of interest (e.g. out of the study area). SELES makes no a priori decision as to undefined values. However, individual models can contain undefined values, but it is up to the modeller to ensure that no operation will be performed on any cell that has an “undefined” value on any raster layer used by that operation. In general this is easy to do, but care must be taken. Use of a binary study area layer is often convenient.

4. All raster layers used in a single model must have the same grain (cell size) and extent (number of rows, cols). SELES makes no assumptions about the grain of your raster cells. It is up to you to determine the appropriate scale and behaviour at that scale for your model. Note: SELES does provide some capability to rescale layers and to align two layers so that their georeferencing information matches.



Figure 3. SELES models consist of a scenario file which loads GIS layers and model configuration files, and issues various commands. These in turn load events and agents, which are based on the expression language.

Go to... Next Chapter Guide Index