PLECOTUS-FAQ
- What does PLECOTUS stand for?
- 2. What kind of forest growth models are supported by the PLECOTUS-Framework?
- How does the plugin-mechanism work?
- What 's the Time-Chain good for?
- What are visitors?
The PLECOTUS-Project was named after the bat Plecotus aureatus, a bat found in Eurasia noted for its long ears. Since the project had to be named somehow, PLECOTUS seemed better then abbreviations like FIS (Forest Information System) which are widespread and normally not appealing. So, a bat came to be project mascot.
2.) What kind of forest growth models are supported by the PLECOTUS-Framework?
The model family supported by the PLECOTUS framework is static, discrete and may be stochastic or deterministic. The level of abstraction is not fixed but scalable. The growth process of trees can be modelled from molecular level to highly abstract representations. PLECOTUS provides best support for single-tree forest growth models.
3.) How does the plugin-mechanism work?
The PLECOTUS-Framework provides extendable objects of type 'GenericStand' and 'GenericTree'. Both objects carry attributes commonly collected in field studies, such as height and diameter for a 'GenericTree'. Their interfaces define operations which are likely to be required in any forest growth model, such as radius of the tree shaft at a certain height. How these basic operations are implemented is left to plugins. Plugins have to be written for GenericTree objects and for the GenericStand object. When a GenericTree object is signalled to call its diameterAt(..) function, it forwards this call to its plugin. By changing plugins in the background, the behavior of a GenericTree object can be changed at runtime. Every plugin, i.e. objects of type 'Extension', have a name. This name must be unique. A GenericTree object has a list of suitable plugins of which one can be set to be the active plugin. The active Plugin then defines runtime behavior.
4.) What is the difference between Extension and Plugin?
There is none. Plugins are implemented as Extensions of PlecotusObjects. Using the PLECOTUS-Framework, simulation is done by statechanges in communicating PlecotusObjects.
5.) What 's the Time-Chain good for?
The time-chain is a mechanism that elegantly solves interdependencies between state transitions of simulation in time. In a sequential program, objects change state one after another, hence information about the prior state of an object is lost while it might still be needed. The time-chain provides a transparent infrastructure for storing and retrieving previous states of a simulation object. It can be enlarged and shortened dynamically to remember any number of previous states.
6.) What are visitors?
Interaction with a forest stand is modelled using the visitor pattern. Foresters, beetles etc. can be interpreted as 'visitors' to a stand. A visitor traverses the hierarchical model structure enabled by the plugin-mechanism. Actions, such as thinning, are taken during the visit of a stand. The model of a visitor going into a stand is very intuitive. Furthermore, the question of which visitor is responsible for what action is decoupled from the action itself, e.g. a forester might assume the role of a 'StandThinningVisitor' or 'StandValueAssesingVisitor'. Thus, actions and visitors can be reused more easily. It is further possible to design hierarchies of interventions, a 'FemelHarvestingVisitor', for example, might inherit from 'HarvestingVisitor'. Note that visitors relying on types, not implementation (plugins), can be exchanged between models. Furthermore, visitors implemented as threads are basically software agents which can interact with each other and the forest stand.
