## UnitsInBusinessSimulationsHow to make use of the unit framework |

This information is part of the Business Simulation Library (BSL). Please support this work and ► donate.

In business simulations, unit consistency is crucial for model verification. Modelica, being a *cyber-physical modeling language*, offers the attributes `quantity`

, `unit`

, and `displayUnit`

to ensure accurate unit application in your models:

`quantity`

specifies what the measurement signifies. For instance, the unit`N.m`

could represent either*energy*or*torque*. Understanding the quantity provides context and guides measurement methods.`unit`

is the scale for measurement comparison. For example, comparing 10`g`

and 10`kg`

demonstrates different magnitudes, while seconds [`s`

] and meters [`m`

] are incompatible units.`displayUnit`

allows using*compatible*units for ease of value input and output, while the internal calculations use a standard*base unit*(often SI units).

While the strict SI unit adherence in physical models might not fully translate to the "softer" sciences, adopting a balanced approach can be beneficial:

- The significance of
*meaning and measurement procedures*(like quantity) cannot be overstated. For instance, Forrester [2] identified the following six main quantities*personnel, material, money, capital equipment, orders, and information*. - In social science modeling, where preferences and possibilities are numerous, modelers often have the final say in non-SI unit choices.
- However, employing
`displayUnit`

is highly recommended for clarity and error minimization. Remember, in large-scale models developed by different teams, consistent unit use is essential for accurate integration of various model components.

In the BSL, assigning units to a variable, like `x`

, automatically applies these units to related variables (e.g., `y`

) in equations such as `x = y`

. This principle ensures consistency in unit determination, akin to the numerical value derivation from known values and equations. A well-constructed model will systematically derive the units of output variables from the input units, guaranteeing a coherent unit system and enhancing model reliability. An output with incorrect units is an indicator of potential equation errors.

Most elementary classes in our library include a `replaceable type OutputType`

. This can be set easily via a dropdown in SystemModeler, facilitating user-friendly selection of `displayUnit`

or `unit`

next to a predefined `quantity`

. This early setup aids in quick identification and resolution of any unit discrepancies. In some components `OutputType`

is also used to define parameters.

Modelers might still simply opt for `Units.Unspecified`

, equivalent to Modelica's `Real`

, and customize the `quantity`

and `unit`

attributes as needed. Nevertheless, we recommend to follow some guidelines for using the Business Simulation Library effectively.

In the following, we will categorize predefined `types`

into four separate categories: Time units, cybernetic- and information-related quantities, extensive and intensive properties of systems, and finally rates of change with regard to the before mentioned quantities.

Modelica's `time`

variable is unchangeable and *always in seconds*, ensuring unambiguity across different model integrations. Consequently, all time-related types in the BSL use `unit = "s"`

.

For convenient input and output, we define time units like `yrCal`

(the mean Gregorian calendar year will display as `y`

in System Modeler), `mo`

(Gregorian month), and `qtr`

(Gregorian quarter year), which will minimize deviations in long-term simulations (see Notes below). Other units of time are less ambiguous and also available, e.g., `wk`

(week), `d`

(day), `h`

(hour), and `min`

(minutes). These exact units of time can be used, should this kind of precision really be required in a simulation.

In cybernetics, units and quantities often become irrelevant, with many controllers using dimensionless variables—typically normalizing values so that the units in the resulting ratio cancel out. The following types can be understood in this fashion:

Modelers can adapt these types to a wide range of cybernetic and control applications. Note that only `Information`

will have a non-empty quantity attribute, all other types in this section are purely numeric quantities (`quantity = ""`

).

While we will be modeling at a much higher level of abstraction, it seems helpful to observe thermodynamic reasoning in making a distinction between *extensive quantities* and *intensive quantities*. Extensive properties of a system vary with its *size* and all of these quantities are typically collected in *stocks*, which earns them the label "conserved quantities." In the library, we will have all conserved quantities known to physics next to some extensions all of which extend from the basic type `ExtensiveQuantity`

.

Humanity and its economic system are tightly embedded within a biological and physical environment. Therefore *physical* stocks and their in- and outflows should be accounted for properly [21]. The library follows the Modelica Standard Library in explicity accounting for these important conserved physical quantities as defined by the International System of Units (SI):

Unfortunately, as far as SI is concerned everything that is "counted" is considered to be *dimensionless*, i.e., the base unit is simply `1`

. This fails to distinguish *integer-valued counts* of elementary entities from *real-valued ratios* like `rad, m/m`

etc. Following Flater's recommendations [29], we will distinguish *counts* from dimensionless *ratios* by introducing **new base units** for counts of elementary quantities, data capacity, labor, and monetary value.

In the Business Simulation library, we will take the liberty to introduce a new base unit `each`

for counting the number `N`

of "elementary entities, individuals, or systems." The type `Amount`

thus is an immediate analogue to the way a chemist uses `mol`

to *count* amount of substance.

The base unit `each`

will be represented by `#`

in System Modeler to clearly distinguish a count from ratios and other dimensionless quantities. It has the following derived units: `pair`

, `dozen(doz)`

, `score`

, `gross`

, `ream`

, `thousand(k)`

, `million(M)`

, `billion(B)`

, and `trillion(T)`

. Since the SI prefixes `k`

, `M`

, and `T`

cannot be used for dimensionless quantities with unit `1`

, there will be no ambiguity regarding their use as counting units.

The chemist's mole is a *parametric* quantity. Unless we are told what is being counted, e.g., certain molecules, atoms or particles, the given amount is useless information. Since Modelica does not know parametric quantities, we should either use a variable's (or component's) *name* or its `quantity`

attribute to clearly indicate what we are counting. In the latter case, it seems reasonable to distinguish the following essential quantites in economic and ecological models:

All of these quantities will have `unit = "each"`

with two notable exceptions. *Labor* will be accounted for using the newly defined base unit `FTE`

, while *UnitScaleIntangibles* are a special kind of intangible assets normalized to the unit range.

Above, we already introduced cybernetic and information-related quantities, which are essentially dimensionless. In some lose analogy, we might talk about "weighing" whatever information we have. This naturally leads to the new base unit `bit`

and its derived unit `byte`

—both of which can be used with SI prefixes to measure `DataCapacity`

.

Value in economic models may be either expressed as (dimensionless) *utility* or in *monetary* terms. For the latter, the following `types`

are defined in the `Units`

package:

All of these monetary units are defined as *base units* using three letter codes according to ISO 4217 as unit names: `XXX`

, `USD`

, `EUR`

, `GBP`

, `JPY`

, `CNY`

. While all monetary units use `quantity = "Money"`

, a modeler needs to specify how different currencies are to be exchanged—there is obviously no static conversion factor.

Contrary to extensive quantities, intensive properties of a system (base type: `IntensiveQuantity`

) do not change with its size. A typical example is temperature. After dividing a certain volume of hot liquid into two identical ones, the amount of *entropy* in each half will be half that contained in the original volume, while the temperature—neglecting the cooling during the process—will have remained identical for both volumes.

The library contains the following intensive (physical) quantities:

With the exception of `time`

we have so far talked about properties of systems—either accounted for by its states or functions thereof. To specify flows in system dynamics we need to introduce *process quantities* pertaining to processes changing the states of a system.

In correspondence with the main physical quantities that are conserved, the following physical flows are defined in the library:

`VolumeFlowRate`

`MassFlowRate`

`EnergyFlowRate`

`MomentumFlowRate`

`AngularMomentumFlowRate`

`Velocity`

`EntropyFlowRate`

`ElectricCurrent`

Our non-physical extensions necessitate the definition of corresponding flows as well:

`Rate`

`AmountRate (quantity = "Throughput")`

`LaborGrowthRate`

`DataTransferRate`

`MonetaryFlow`

`MonetaryFlow_USD`

- ...

- Some links provided for base units, derived units, and quantity-related display unit definitions of the library will only work "in product", i.e., for users having Wolfram System Modeler (WSM) and the Business Simulation Library (BSL) installed.
- The use of non-SI units requires definition of custom
*derived*and*base units*. Presently, only Wolfram System Modeler 14 is tested to allow this flexibility and convenience. Modelers may always take recourse to using standard SI units with the BSL, which are supported by all Modelica tools. - Whenever we speak about "years" within the BSL, we will always mean
*average calendar years*(365.2425 days). The reason for this choice is that in Modelica time will always be accounted for in seconds; we might accordingly want to use the amount of seconds that most closely represents an average year over arbitrary time spans. Using average calendar years will thus maximize the chance that adding the amount of seconds to an actual start date will result in the correct end date for a simulation that spans several years—the mean absolute error for using`yrCal`

will typically be less than 0.5 days.

Copyright © 2020 Guido Wolf Reichert

Licensed under the EUPL-1.2 or later

- Changes in unit hierarchy and type definitions in v2.1.0 and v2.2.