Module 1 · Modelling in SELES: Overview
Adapted from the SELES training course by Andrew Fall, Landscape Systems Ecologist, Gowlland Technologies Ltd. (April 2024)
This module sets the stage for the rest of the training series. Before touching the SELES software itself, it asks a more fundamental question: what does it actually mean to build a good landscape model, and why does a tool like SELES exist at all?
By the end of this module you should have:
- some basic guidelines for building complex models,
- a high-level understanding of SELES as a tool for building and running landscape models, and
- a map of how the rest of the training modules fit together.
See also: SELES User Documentation, Part 1 — Conceptual Framework, sections 1 and 2.
:::tip Following along hands-on Later modules have you build and run real SELES models. SELES itself only runs on Windows and is a free download from Andrew Fall's site: gowlland.ca. Nothing to install yet for Module 1 — it's all conceptual. :::
Why Landscape Modelling Is Hard
Landscape management problems are hard for reasons that have nothing to do with software: they cover large areas over long time frames, they're genuinely complex — pattern and process feed back on each other across space and time — and they carry many sources of uncertainty, from patchy spatial data to natural variability in the processes themselves. On top of that, landscapes serve competing values (conservation, resource extraction, tourism) with no single "optimal" answer.
Yet decisions still have to be made — land-use planning, sustainable resource management, endangered species recovery, disaster response. Modelling doesn't make those decisions for you, but it gives you a disciplined way to explore their consequences before committing to them.
Because landscape-scale problems are systems problems, they resist purely analytical or statistical treatment. That's the core justification for simulation: models become the tool for exploring hypotheses and supporting decisions when the system itself is too tangled for closed-form answers.
Weinberg's classification is a useful gut-check for whether simulation is even the right tool:
- Organized simplicity — few components, strong consistent relationships. Calculus and optimization work fine.
- Unorganized complexity — many components acting independently and uniformly. Statistics can describe the aggregate behaviour.
- Organized complexity — many components with varied interactions. This is where landscapes live, and it's usually where you need systems analysis and simulation.
Aside
Who was Weinberg? Gerald Weinberg (October 27, 1933 – August 7, 2018) was an American computer scientist, author, and teacher of the psychology and anthropology of computer software development. His most well-known books are The Psychology of Computer Programming and An Introduction to General Systems Thinking — the latter is the source of the three-tier classification above, and remains one of the foundational texts in systems thinking, cited well beyond software engineering in fields like ecology and organizational theory.
Spatial, Temporal, and Spatio-Temporal Modelling
Two modelling traditions converge in landscape simulation: temporal modelling, concerned with process (how something behaves over time — think of a small state-transition diagram), and spatial modelling, concerned with pattern (how something is arranged across the landscape — think of a stack of raster layers). SELES sits at their intersection: spatio-temporal modelling, where pattern and process are simulated together rather than treated separately.
A few properties define what that combination looks like in practice:
- Dynamic spatial models explicitly simulate change over time, with feedback between state changes, and output a sequence of landscape states rather than a single static map.
- Deterministic vs. stochastic — a deterministic model always produces the same output from the same starting conditions (loaded dice); a stochastic model includes randomness and produces different results each run. Most landscape event models are stochastic, since real disturbance processes are.
- Cellular automata — each cell behaves as an independent sub-model, and its next state depends on its own current state plus its neighbours'. The interesting large-scale patterns are emergent — nobody programs them directly.
- Diffusion models spread across space, grid- or vector-based, and have to reconcile continuous (Euclidean) spread behaviour with a discrete grid — wildfire spread and water flow are the classic examples.
- Event-based models treat change as a sequence of discrete events — this is discrete-event simulation, and it's the paradigm SELES itself is built on (see Landscape Events).
- Population models represent a population as a set of non-distinct individuals, often divided into life stages (egg, tadpole, juvenile, adult) — matrix population models are the classic formalization.
- Individual-based models instead track distinct individuals with persistent identity — useful when movement rules or individual mortality matter, e.g. random-walker models.
Combining space and time buys real modelling power — lateral fluxes like flow along roads, or feedback between fire and salvage logging, only make sense spatio-temporally — but it comes at a cost: more complexity, more opportunities for error to propagate, and a much higher data burden than a purely temporal or purely spatial model.
The 4 Tenets of Landscape Modelling
These four tenets are less about SELES specifically and more about landscape modelling as a discipline — worth keeping in mind no matter what tool you eventually use.
Tenet #1 — Fit the decision process, not the other way around
The modelling process has to adapt to fit the decision-making process, not vice versa. In practice this means: if you can't explain and defend your model to the people who have to act on its results, it isn't useful yet, no matter how sophisticated it is.
A common failure mode is the "loading dock" approach — science develops a research model in isolation, then proposes it be applied in a management context. That assumes management decisions are driven mainly by better knowledge of the system, and it tends to ignore the decision-making process itself: the social, economic, and political objectives at play, and the fact that decision-makers already have specific problems they're trying to solve.
The alternative is a collaborative approach: management and science working together from the start, with the explicit goals of increasing decision-makers' understanding, delivering relevant and timely information, involving and informing stakeholders, and documenting the rationale behind decisions — not just the decisions themselves. The diagram above shows what that looks like structurally: all participants shape the questions and scenarios; domain experts translate those into conceptual models; and a core team implements and runs the actual simulation experiments, with results flowing back out through analysis to inform the next round of questions.
Tenet #2 — As simple as possible, but not simpler
"Models should be as simple as possible but not simpler." — usually attributed to Einstein, and echoing William of Ockham's Entia non sunt multiplicanda praeter necessitatem ("entities should not be multiplied beyond necessity").
There's a real trade-off between realism and certainty: pushing a model toward more detail and "realism" tends to increase uncertainty (more parameters, more data demands, more ways to be wrong) rather than decrease it, at least until the underlying data can actually support that level of detail.
It's also worth keeping precision and accuracy conceptually separate: 3.14 is accurate to two decimal places but not very precise; 3.145176 is very precise but might not be accurate at all. A model that reports numbers to five decimal places isn't necessarily a better model — it may just be a more confidently wrong one.
Tenet #3 — Conceptual models are distinct from implemented models
A conceptual model is the plan — what you want to achieve, described in writing. An implemented model (a program) is the actual realization of that plan. They're not the same thing, and conflating them is a common source of confusion. The recommendation is to keep your focus on the conceptual model, the scenarios, and the outputs — the program is just the vehicle.
The mountaineering analogy here is a good one: the conceptual model is the plan for an ascent, including how you intend to handle known unknowns. The implemented model is the actual climb — including the unforeseen technical issues and the places where reality quietly diverges from the plan. The gap between the two (the "modelling gap") is real, and it's worth naming explicitly rather than assuming your code does exactly what you meant it to do. Note also that more than one implementation can legitimately correspond to the same conceptual model.
Tenet #4 — Modelling tools should be flexible and transparent
As Botkin put it in 1977, a faithful implemented model "forces us to see the implications, true or false, wise or foolish, of the assumptions we have made" — a model is a tool to confront us with the consequences of what we think we know, not a black box that produces answers on faith. That only works if the tool used to build the model is transparent enough that its assumptions can actually be inspected — which is a design goal SELES takes seriously (see The SELES Paradigm).
Where SELES Fits Among Modelling Tools
Modelling tools fall on a spectrum. At one end are general-purpose programming languages and program-level frameworks (SimScript, EcoSim, SpaDES+R, Swarm) — maximally flexible, but expensive to build with and hard to modify, usually requiring procedural specification. At the other end are model-level tools (STELLA, Patchworks, SELES's own Spatial Timber Supply Model) — special-purpose, restricted to a narrower class of models, but much faster and simpler to build with, using a more declarative specification style. SELES itself sits toward the model-level end, alongside tools like LANDIS II — general enough to express many kinds of landscape processes, but far more constrained (and so far more productive to work in) than a general-purpose language.
That said, the line blurs once you allow "plug-in" extensibility: a tool like LANDIS II + C# lets you extend the model's state space and behaviour with custom code, which pushes it back toward the general-purpose end without abandoning its model-level structure. The distinguishing question is whether the tool defines a state space and general process behaviour (an extensible model, like SELES) or leaves the entire state space and model behaviour up to the user (programming support for modelling, like SpaDES+R).
Domain-specific modelling tools earn their keep by being simultaneously simple (fast to build a working model in), flexible (handle a variety of model types), capable (limited by your domain knowledge, not the tool), modular (models decompose into manageable pieces), transparent (assumptions are explicit, not buried), efficient (can process large, complex models), and adaptable (components can be reused across projects). SELES was designed against exactly this checklist.
What SELES Actually Is
SELES — the Spatially Explicit Landscape Event Simulator — is a general tool for building models of landscape dynamics. It's two things bundled together: a language for specifying models of landscape dynamics, and a simulation engine for running the models written in that language. (See SELES Overview for the fuller treatment.)
Its paradigm rests on spatio-temporal contexts: landscape change arises from feedback between system state and definable processes, and as agents of that change, processes react to and modify landscape state within a spatio-temporal context — the set of state variables available at a particular place and time. Contexts provide a general hierarchical framework for describing landscape dynamics, and by managing them appropriately, SELES can express a wide range of model types: natural disturbance models, habitat supply models, timber supply models, spatial population/metapopulation models, and individual-based models. Full detail on this paradigm is in the next module.
Aside
How SELES Started
The first version of SELES originated from a course project by Andrew Fall and Joseph Fall in 1996, in a graduate-level modelling course in Resource and Environmental Management at Simon Fraser University (SFU), B.C. While it was very limited — and wasn't yet a modelling language — it did have the essential concept of a landscape event, used to represent percolation-based fire spread models.
They believed model implementation should be as transparent as possible, so others could understand the "beauty" of a model separately from the "beast" of the overhead code needed to get it running on the modelling platform. Model-building tools should support thinking about the model-building process — this was the insight behind SELES from the start (Fall & Fall 2001).
Learn more about the origin of SELES.
Structurally, a SELES model is a Scenario Script (.scn) that ties together grids/layers (the spatial initial state) and one or more Dynamic Model Files, which in turn reference Landscape Events (.lse), Legends, Input Table Files, and Macro Files (.ce). You'll meet each of these file types in detail in Part 3 — File Reference; for now it's enough to recognize the shape of the tree.
How This Training Series Fits Together
The modules ahead build on each other in order:
- Module 2 — the SELES paradigm (conceptual basis)
- Module 3 — the user interface (SELES as a program)
- Module 4 — running models (the driver perspective)
- Module 5 — reading models (the mechanic perspective — transparency)
- Module 6 — exploring the landscape-event meta-model
- Module 7 — writing models, via a worked case study (the constructor perspective)
Each module assumes the ones before it are done — this isn't a reference you can jump into at Module 5 without Modules 2–4 first.
Another way to see the same structure is as five facets of SELES, each tied to a different perspective on the tool:
- Data exploration tool (Module 3) — a GIS-like perspective: user interface and visualization.
- Simulation tool (Module 4) — a driver's perspective: setting up and running existing models, scenarios, and experiments.
- Modelling platform, understanding existing models (Module 5) — a mechanic's perspective: the conceptual basis and language of landscape events/agents.
- Modelling platform, building models (Modules 6–7) — a constructor's perspective: modifying and building models, debugging and verification.
- Model factory (Module 8, if/when available) — a designer's perspective: designing models that fit the SELES paradigm — landscape systems ecology proper.
These facets map onto modelling roles, and it's worth asking yourself which one you are before you start: Clients set objectives and use results; Designers bring model and domain knowledge to create the conceptual blueprint and interpret results; Constructors implement that design and handle testing/verification; Mechanics adapt and modify existing models; and Drivers generate and analyze results by running scenarios. Most people doing SELES work wear more than one of these hats — but knowing which hat you have on for a given task will save you a lot of confusion in the modules ahead.
Aside
Review Questions
- Weinberg classifies systems into three categories. Give an example of "unorganized complexity," and explain why it resists purely analytical treatment.
- What are the 4 tenets of landscape modelling introduced in this module?
- Describe Ockham's Razor, and how does it relate to real-world modelling?
- What's the difference between a deterministic model and a stochastic model?
- What's the difference between a population model and an individual-based model?
- SELES is described as "two things at once." What are they?
- What is a spatio-temporal context, and why is it central to the SELES paradigm?
- Name the five SELES "facets" introduced at the end of this module, and the perspective each represents.
Next: Module 2 · The SELES Paradigm (coming soon)