Spatial Discrete Event Simulator

• Discrete event simulators have a long history in computer science
• SpaDES is oriented around the construction of spatially explicit models and the use of spatial data.
• events describe changes in the state of a complex system at some time
• time is not modeled in a continuous fashion (simple loops would do this); we can 'skip ahead' to the next event, speeding up model evaluation
• events are scheduled (added to a queue) dynamically, and executed at their scheduled time

• In Ecology, there are other generic DESs:

  • SELES (very generic)
  • HexSim
  • NetLogoR (Individual based models)

• More specific DESs

  • LANDIS (forest dynamics)

• Spring thaw
  
  
• Brainstorm events…

• Modules are a convenient way to group events that fit naturally together:

  • e.g., fire ignition module
  • e.g., carbon accumulation module
  • e.g., data preparation module

• What is contained in one module is highly idiosyncratic .

SpaDES is implemented in a way that facilitates modularity of code:

• different (ecological) processes can be grouped into logical units (modules)
• a(n) (ecological) model consists of a collection of modules
• each module is responsible for scheduling its own events
• modules interact indirectly via shared data objects (e.g., a map); module 'A' doesn't need to know what module 'B' is doing

Thus, modules can be added, removed, or swapped out without needing to recode the rest of the model.

• There are many types of modules that may be useful:

  • Agents
  • Events
  • Data preparation
  • Summaries of data
  • see list from SpaDES wiki

Once we see that a module is just a convenient way to group together events, anything can be a module. Can be a single line of code or as many as you want.

• caribou
• wolfAlps
• Mountain Pine Beetle

• Vegetation change
• Spatial clustering (e.g., to create polygons)
• Aging
• Class change (e.g., land cover class)
• Biomass change
• etc.

• cropReprojectLcc

… instead of just an R script or function?

• allows things to be scheduled

• allows modularity

  • a module can be reused by someone else with little change
• can be published on the web
• can estimate unknown parameters

• and much more…

A module is an R script with 3 parts:

1. Metadata - a list of 15 things

   • Name, Author, Description, other for human reader
   • parameters, input objects, output objects for R to "understand"

2. doEvent - 2 types of things here

   • schedule events
   • run functions

3. Anything else

   • custom functions
   • initial data preparation steps

Essentially 2 steps

1. Create a simList using simInit()
2. Run spades()

All the necessary information is contained within the simList

What might be needed for a DES to run…

- start and stop times
- data
- paths
- which modules to use
- parameters
- a schedule of events
- outputs

• Will be covered in detail next

• We are working with R, so we can use any data structure or file format that R can understand

• SpaDES has some helpers for loading data, but in general, the module should be explicit

  • e.g., downloadData("caribouMovementLcc", path = tempdir())
• A module takes input data, changes them, and provides outputs

• like a function, but with the addition of "time"

• Some challenges …

Numerous challenges exist with data

• messy
• ownership
• large
• permissions
• errors
• other

SpaDES doesn't necessarily solve these issues, but in some cases it helps.

• package help docs (e.g., overview of SpaDES package):

?SpaDES

• package vignettes (link)
• SpaDES wiki (link)
• SpaDES user group (link)
• bug reports (link)