.BusinessSimulation.UsersGuide.Tutorial.UnitsInBusinessSimulations

How to make use of the unit framework

Information

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

Understanding Units in Business Simulations

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.

Unit Application in the Business Simulation Library

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.

Time Units in the Library

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.

Cybernetic and Information-related Units

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 = "").

Extensive Properties of Systems

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.

Conserved Physical Quantities (SI units)

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.

Amounts—Counting Entities

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.

Ecological and Economical Quantities

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.

Data Capacity

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.

Monetary Value

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.

Intensive Properties of Systems

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:

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

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

Notes

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. Examples have been adapted accordingly by defining s === model's standard unit of time thus forfeiting the use of displayUnit.

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.

Revisions

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

Generated at 2026-04-01T18:18:38Z by OpenModelicaOpenModelica 1.26.3 using GenerateDoc.mos