Exploring The Open Source World - What Is Moja FLINT All About, Anyways? (Simulation Units, Local Domain, Synchronized Events) 3/🧵
Simulation Units, Processing, Specific Purpose, Carbon Stocks, Domain Characteristics, Synchronized Events
Simulation Units (SU)
About
"A unit for which a module is applied.
"A Simulation Unit (SU) can represent a spatial area, such as a pixel, forest stand, emissions source (livestock)"
"When SU refers to a geographically referenced area (Land Unit - LU)"
Simulation Units
FLINT overall manages processing of SUs over time
While SUs form the basis, they are hardly used for reporting (Local Domain is used instead).
Land Unit
Contains information for,
- Unit's Area
- Land Type
- Age Of Vegetation
- Species
- Carbon Pools
Local Domain (LD)
About
"Local Domain (LD) sits on top of SU, acting as a collective bounded for a specific need."
Example would be, reporting on changes in carbon stocks for a region.
How Are LDs Used In FLINT?
They have three main functions,
- They are used to "house" the variable values for all SUs they represent
- An LD controller assigns values to SUs in a simulation
- They receive outputs SUs, update Domain Characteristics
Example Scenario
As discussed before, FLINT applies modules to individual SUs, determining sock/fluxes for individual pools.
However, scale of SUs results in large resolution for reporting purposes, needing to be aggregated.
To comply, outputs can be specified to be summed at various spatial scales for national and international compliance obligations.
Given an example, if the user wishes to determine the carbon stock change over a period for a region where SU is represented by a pixel (25m x 25m).
FLINT uses pool specific modules to draw the current values of each variable associated with a pixel, within the given region.
Operations are then applied to these variables by the module at the pixel level, associating the outputs to the pixel.
For the output, a summation of the new values for each pixel by module, producing a database of carbon stocks and fluxes for each pool over time for the region.
Synchronized Events (SE)
"In situations where there is an inter-dependency between simulations, we need a way to synchronize the related SU"
For example, a one simulation updates the second simulation in some way through a trigger.
Given 1,000/10,000 pixels affected by a fire event, now in order to determine if a pixel should apply a module, it is necessary to know how many other pixels have been selected to have the fire module applied.
Handling Synchronized Events
Included in the FLINT is a synchronized server. This server uses a set of user-inputted criteria to identify particular SUs for which a module, will, or could, be applied.
The module can be applied to all SUs that meet the criteria, or the module can be attributed to a sub-set of the identified SUs using a pre-determined criteria (e.g., randomly, weighted, or based on a unit characteristic).
During a simulation, the module is run, and the outputs computed.
Notably, this is carried out in a simulation. For example, where a disturbance event has occured, and only spatial tabular data is available, the simulation process is run to identify SUs that meet the criteria of the state disturbance event.
The criteria maybe,
- Forest Age
- Species
- Region
Once identified, FLINT will run a disturbance module on the simulations that meet the criteria up till the effect of the disturbance event has been modeled.
Other systems, such as Australia's Full Carbon Accounting Model, do not have this ability to apply tabulated spatial data during a simulation.
The data must rather be process separate from the model before it can be applied.
