Design
Philosophy
Open Stand Model (OSM) is a stand-alone software project developed from scratch in C# with zero dependence on third-party code or unmanaged objects. OSM provides a base object model to allow stand model developers to rapidly design tree-list stand models in different regions or for different modeling purposes.
The concept of building a stand modeling platform to allow others to build and deploy alternate stand models is not a new idea. The Forest Vegetation Simulator (FVS) is probably the most successful example of this concept in action.
The success of FVS in terms of its number of users, many plugin components, and long history of development is also its main issue. Over the past 60 years, FVS has built up an incredible amount of overhead in terms of inputs, supported commands and extensions, and runtime processing steps. Under the hood, FVS source code is built in FORTRAN and C with a mix of object oriented and process-oriented source code, and clear divisions between the base FVS model and regional FVS variants are sometimes difficult to discern.
Given the momentum
of FVS, it is difficult for new eager tree list modelers to deviate much from the
core functioning of how FVS works, which can be a bit frustrating. Key areas
that we set out to improve included:
1)
increased
flexibility of prediction methods used (equation form, machine learning),
2)
flexibility
in terms of the order of operations of how a stand grows from one timestep to
another to facilitate very different modeling approaches used in different jurisdictions
or by different model developers,
3)
engineering
a truly extendable source code object-model to facilitate an easy-to-use plugin
API (application programing interface),
4)
maximize
simulation performance.
For those looking for a lightweight tree-list modeling platform that is extremely flexible in terms of application integration among developers and users, OSM may provide you with clear benefits.
The overriding design philosophy of OSM is to include only the most basic building blocks of a tree-list model with an object architecture that is easy to implement and extend. Any components that are not strictly required for representation of a tree, stand, or simulation have been excluded from the base framework. Extensions can of course be built and directly linked to the base framework, but this responsibility falls on model developers outside of the core OSM development team. Where new features are needed to facilitate a more open and efficient API, the OSM development team is on it.
In terms of source code architecture, OSM provides:
· A software solution developed
completely within Microsoft’s .Net Framework using C#.
· An open-source, free ‘as in free
beer’ software project that modelers around the world can contribute toward.
o
Create
an account on GitHub and email FORUS Research to discuss becoming an
OSM source code viewer or full-fledged contributor.
·
The
source code project is a GitHub private repository project for now, but as source
code users & developers expand, it may shift to a mature public repository.
· An extremely light-weight and high-performance
framework for simulating stand or individual tree development.
o
Stand
and tree dynamics can be projected over unlimited simulation time horizons with
varying number of years per simulation cycle.
· A hierarchical, abstract object
model of a simulation, stand, tree, species, and other basic building blocks of
a tree list simulation model. All of these objects are
packaged into a single light-weight DLL (OSM.CommonModels.dll).
o
This
framework has few preconceived notions about how a stand should develop within
a simulation cycle. Order in which growth, mortality, and recruitment is
applied and how it is predicted is left completely up to the stand model
developer.
· An interface model that exposes public
properties and methods of simulation, stand, and tree objects to allow other
third-party applications to directly link to OSM libraries to control stand
simulations, inputs, outputs, harvesting, and modifications to tree dynamics
during simulation. Because all regional variant models must inherit from these
abstract objects with defined interfaces, third-party applications that can control
one variant will also be able to control other variants.
· A hierarchical command-line model,
similar in look and feel to python, which is relatively easy to read and
interpret by a user. All base runtime objects such as the command model,
harvest actions, and prediction amendments (modifiers) are contained in a
separate DLL (OSM.Management.dll) to avoid unnecessary dependencies on these
components by Variant models. This clear division between the OSM runtime and
base stand model allows other third-party developers to extend the base runtime
or completely redesign a custom command model and/or build a custom graphical
user interface to support client-side simulations for any OSM variant.
·
An
input-output model designed to accommodate both metric and USA unit systems.
· Clear separation between:
o
developers responsible
for the base stand model (OSM.CommonModels.dll) and base runtime model (OSM.Management.dll),
o
second-party Variant
model developers responsible for implementing the stand model predictions (OSM.Variants.X.dll;
e.g., OSM.Variants.Acadian.dll), and
o
third-party developers that
support client-side graphical user interfaces and runtime (Custom.exe).