Previous topic

Aggregation definition

Next topic

Lexicon translation

This Page

Expression definition

The expression definition document defines reporting variables and output types in expression output.

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 …:

While expression definition is very close to aggregation definition, there are some key differences:

  1. Expression definition does not support reporting periods, nor grouping.
  2. It is always grouped by id, iteration and branch.
  3. If a certain key combination has no value, it is dropped from the results.

The root level tag contains a reference to the schema document which is used to validate the content of the XML document:

<expression_definition xmlns="http://latitude.mmvar.helsinki.fi/simo"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.simo-project.org/simo
         ../schemas/expression_definition.xsd">

First, you must define the initial date of the simulation (as YYYY-MM-DD) to get meaningful results:

<initial_date>2009-01-01</initial_date>

Next, discount rate is defined for outputs that needed discounting, such as net present values of income from harvests etc.:

<discount_rate>3.0</discount_rate>

Single expression definition can include multiple expressions. The syntax for defining the reported variables is similar to optimization task subobjective and constraint syntax. Below is an example of a very simple report, where harvest volumes, between first year (1) and last year (-1) are reported:

<expressions>
      <item>
         <expression>sum[1:-1](operation:Volume)</expression>
         <label>Harvest volume</label>
      </item>

It’s also easy to give conditions to certain values, though in that case, it should in most cases be given to all the values so that the expression doesn’t fail:

<item>
         <expression>avg[1:-1](comp_unit:Age[comp_unit:MAIN_SP eq 1] * comp_unit:AREA[comp_unit:MAIN_SP eq 1])</expression>
         <label>Average age</label>
      </item>

The conditions must be given so that if the result variable is from operation results, the condition variables can be either operation results or simulated data. If the result variable is simulated data (i.e. from level ‘comp_unit’), the condition variables can be only from the same level. Here’s a valid and invalid example.

Valid:

<item>
         <expression>sum[1:-1](operation:Volume[operation:assortment eq 1 and comp_unit:MAIN_SP eq 1])</expression>
         <label>Average age</label>
      </item>

Invalid:

<item>
         <expression>sum[1:-1](comp_unit:V[operation:assortment eq 1 and comp_unit:MAIN_SP eq 1])</expression>
         <label>Average age</label>
      </item>

The expressions can be more complex as in optimization tasks (note that cash_flow, PV and PV_land are discounted in the below syntax):

<item>
         <expression>
            sum[1:60](operation:cash_flow:discount) +
            sum[60:60](comp_unit:PV:discount * comp_unit:AREA) +
            sum[60:60](comp_unit:PV_land:discount * comp_unit:AREA)
         </expression>
         <label>NPV</label>
    </item>