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 will help to identify the type of information required; an appropriate spatial 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.

We recommend that you identify each of the important processes to be included as landscape events in your model. Try to write an informal but precise version for each event at this stage (see example in section 3). Primary model outputs should also be identified, along with some indications of how they will be analyzed. For example, should a sequence of spatial layers be stored for each model execution or should a single variable be tracked over time. Most SELES scenarios involve some stochasticity, and so may require multiple-runs in a Monte-Carlo fashion. Hence, the type of model output is important, since it is easy to output vast quantities of information, which may be difficult to handle.

2. Information gathering: The problem(s) to be addressed usually suggest at least a starting set of spatial and aspatial information that needs to be included in the scenario as well as some of the processes that are important determinants of the landscape dynamics under study. The resolution selected for the model 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.

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.

4. Initial scenario: At this point, an initial scenario can 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: We view the modelling process as an iterative procedure. The steps up to the construction of the initial scenario form the first loop. At this point, modellers have often identified new ideas for improving the model as well as 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 details than necessary to address the problem, since this will probably increase uncertainty in the model results. The information required to parameterize process models increases as these models become more detailed. 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 (map or variable names) on one axis and process models (event names) on the other. In each cell of this table, notations can be made to 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. A SELES model consists of a set of raster layers and global variables, which define the state variables and initial state for the model, and a number of landscape events and agents, which define the dynamic behaviour of the model.

Each simulation scenario in SELES has two main components: 1. Initial state: This is the set of initial conditions of the landscape before a simulation begins (e.g. forest type, topography). It may be current information or historical and includes both spatial layers of interest and aspatial (global) information. Some of this state may be dynamically modified during a simulation, while other parts may be static. For example, a model of forest change may include in its set of initial conditions the seral state of the forest, which may change over time, and the topography, which remains constant for the duration of the simulation.

2. Landscape Events and Agents: Each agent or process responsible for change to the landscape state (e.g. forest succession, fires, timber harvesting) is specified as an independent sub-model called a landscape event or a landscape agent. The description of a landscape event defines its recurrence frequency and spatial domain (i.e., when and where the event should occur), along with a definition of its behaviour (i.e., how it spreads and what its effect on the model state is). All feedback mechanisms between processes are accomplished through state transitions to one or more raster layer, with no direct inter-event communication. Landscape agent definitions specify starting locations and numbers of individuals and populations, and rules governing movement, mortality and reproduction.

Any number of rasters may be incorporated in a model, but they must represent integers (see the Scenario Reference for information on how to scale a real-value raster 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, such as can be produced using the SELES static pattern generators, can also be used in model scenarios (see Section 4). The SELES simulation modelling language provides a declarative syntax for describing the properties of landscape events, and the simulation engine interprets and executes the model from 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 state changes for a particular model. 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 (DES).

Landscape events specify when events occur (e.g. fire return interval), where events initiate (e.g. in which cell(s) an insect outbreak starts), and what effect the event has on these cells (e.g. timber harvesting may reset the age of a forest stand). If an event may spread (e.g. fire), landscape events specify when spreading takes place, and to where. Figure 1 shows a conceptual view of this general procedure. Landscape events may also depend on contextual information. For example, we may express that lightning strikes are more likely on ridge tops than in valley bottoms, or that timber harvesting must follow a given harvest schedule. By taking care of how landscape events change landscape patterns, modellers are freed from the task of programming and can focus on the behaviour of landscape dynamics.

SELES Discrete Event Simulation Paradigm

All SELES models are executed by the discrete event simulation engine (DES). Understanding how this engine works is critical to successfully building a SELES model. The DES uses a priority queue to maintain scheduled future events in their chronological order. It runs asynchronously -- the current time is always the time of the current event (i.e. the one at the head of the queue). During the 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 DES removes it from the queue, and executes the behaviour specified for that event. This behaviour may involve altering one or more of the state variables and scheduling one or more future events. A diagram of this “event loop” is shown in Figure 2. Section 3 describes how to specify the properties of a landscape event and the behaviour to expect from your specification.

Figure 2. The "event loop" performed by the SELES Discrete Event Simulation Engine (DES). The behaviour of the event (where and when the event occurs and what happens during the event) is determined by the specification of the Landscape Event itself.

SELES Model Structure

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 general static layers or suumary inforamtion. A dynamic model configures a simulation by defining the spatial and aspatial state, land ading landscape events and agents. Landscape events and agents model the dynamic processes acting in the landscape. These are primarily specified by defining their properties (see sections 5-7). Event/agent properties and some static models are built using functional and procedural expressions (see section 8). Since scenario scripting is of interest to both model builders and users, it is described in detail in the companion SELES Scenario Reference document.

Assumptions and Limitations

SELES models can be quite simple, but require careful thought if you are going to produce a model that can be 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 in 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.

2. SELES does not interpret the values on your state raster layers. It is up to you to know 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 category the cell belongs to, not the magnitude of some variable. Using constants in the model specifications are useful to ensure that the correct index is used for each category.

3. Cells in a raster can 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.

4. All rasters 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 do nearest neighbour sub-sampling, however you are advised to use this operation with caution. SELES/NT also provides a utility to align two layers so that their georeferencing information matches.

Next Chapter: Model Builder's Guide Chapter 2 Up to Model Builder's Guide Model Index Builder's Guide