.. highlight:: xml .. _operation-modelbase-xml: Operation model =============== The operation model document contains the definitions for the forestry operation models used in the simulation. It serves two purposes: as a documentation for the models, and as "glue" between the simulator and the model libraries (:ref:`operation-model-library`). An example of the document contents is given below, for a comprehensive description of all the possible content options see the `schema document `_. Data continuation and abbreviated content expressed as …: The root level tag contains a reference to the schema document which is used to validate the content of the XML document:: The models are divided into named operation groups, each group containing several model definitions:: … The model definition begins with the name of the model, which must match the name of the model in the model library. In case the type of the model is ``model`` (see below for alternatives), the model library name and implementation language are given. The cash flow handler may either be the model itself, the simulator or ``none``. In the ``model``-case the model itself returns the prediction of the cash flow associated with the operation. In case of ``simulator`` the simulator get's the cash flow prediction from a cash flow table (:ref:`cash-flow-table-xml`), and if the cash flow handler is set to ``none`` there won't be any cash flow results stored for the operation model. If interaction is set "on", the model can modify the simulation data objects at different levels; i.e., the thinning model removes trees from the simulation. To put it in other words, if interaction is "off", only operation results are processed (not cashflows, simulation effects etc.):: … low_thinning SimoOperations.py python model on Metadata about the operation models consists of the verbal description of the model:: … Basic implementation of a thinning model. Removes diameter classes systematically starting from the smallest diameter class. Next up is the definition about the data that is passed to the operation model. For each data level a group is defined which contains the level name and the level attributes collected for each object on the data level:: … comp_unit Remainlimit_upper Remainlimit_lower stratum tree Another operation model input data category is parameters. The parameter values are set in the model chain documents (:ref:`model-chain-xml`); i.e., they do not get their values from the simulation data:: … target_density track_width Operation models can also get parameter tables as input data. Parameter tables are defined in model interface like this:: … thinning_preference_order log_reduction A weight to be applied to the operation results can also be defined; i.e., it's the multiplier for the result attribute values:: … AREA comp_unit The operation model results are either operation results (operation_result) or data attribute values (data, see below). The operation results can have classifier values associated with then; e.g., the harvested volume classified by the species and the timber assortment. The classifier values can be taken either from data (variable name, data level) of from the cash flow tables used for the operation model (cashflow_classifier):: … Volume SP stratum assortment Variation: operation model type ******************************* If the model type is `cash_flow`, the model definition is straightforward: the vital details are the model name and the optional result weight. The actual cash flow table (:ref:`cash-flow-table-xml`) used for the model is set in the model chain (:ref:`model-chain-xml`):: … grass_suppression Mechanical grass_suppression - heinays AREA comp_unit Variation: operation result type ******************************** If the model result type is `data`, the data level is defined for the results as well as the data attributes that the operation model returns:: … existing stratum stand_value LOGp COMWOOD V_LOG Variation: result variable type ******************************* Default result variable type is `scalar`, but if operation results should be distributed to different points in time, result variable type should be `date_array`. The result data structure constructed by the simulator will be different for scalar and date_array variables. It is the responsibility of the operation model implementation to return correctly built result data structures back to the simulator. Below is a scalar result variable (it would be scalar also without the type attribute):: … stand_value Below is a date_array result variable:: … C_flow