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.

# Development Rational

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.

# Design Philosophy

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).