The Units Manager interface allows creation of “project units”.  Project units can be added and deleted using buttons at the top of the interface (Figure).  Equations that convert from Community to Project units and from Project to Community are entered into the table via key strokes or use of a popup calculator.

Figure.  Project units provide additional systems of measure for communities.


Project units have two primary uses.  The first and most straightforward is to be an additional system of measure and reporting for communities.  For example, a “tree” community might have community units of height in terms of feet or meters and project units for other measures like biomass, stored carbon, and timber value.  In this role, equations would only need to be entered to translate from Community to Project units because the project units are only informational.  As the tree community changes in simulations, status is reported in height and related project units. 

The second and more involved use of project units is to serve as a common ground for multiple communities.  This is required for use of the Consumption rule.  For example, a “bear” community with community units of “massiveness in weight” might consume “fish” and “blueberries”, with community units of “fishiness in smell”, and “bushiness in volume”, respectively.  It would be awkward to relate weight, smell, and volume directly.  Instead, a project unit such as biomass in weight can be used for consumption with units for each involved community being converted from Community to Project, consumption occurring in the project unit and then the resulting project unit value being converted from Project to Community.  More details about consumption are available in the Consumption Rule section.   

Project units are also another way results can be aggregated for reporting purposes.  For example, if all communities have a project unit of economic value, EFMSim can track and report an overall value for each and all simulated communities and levels.

Use of project units is optional except when the Consumption rule is applied.  Density is a reserved project unit.  Equations that translate from community units to density must be provided to obtain output related to counts of individuals for communities that recruit during simulations.  For example, if density equations are not provided, a “grass” community that recruits during the simulation will simply occupy the elements that met its conditions for recruitment, which means results can be reported for area but not count.  If a density equation is provided, community units for “grass” will be translated to a density in terms of count per area.  As areas are known, a corresponding count for the “grass” community would be computed and reported.  For non-mobile communities, the density equation also functions as a maximum limit on count per area.  For example, an element the size of a soccer field could hold hundreds of thousands of tree seedlings but only hundreds of juvenile trees and only tens of adult trees.  A density equation that related size to density for these trees will automatically thin the density as the trees mature.  Mobile communities move between elements.  Densities are computed explicitly based on those movements are therefore not bounded by density equations, even if equations are entered in the Project Units interface.