9. Glossary¶

This section defines various technical terms that are used throughout the report.

package¶

In Modelica, a package is a collection of models, functions, or other packages that are used to hierarchically structure a Modelica library.

class¶

In Modelica, a class is a term that includes models, blocks, functions and packages.

connector¶

In Modelica, a connector is an instance of a class that is used to connect models and blocks with each other. Connectors can contain constants, parameters and variables, but no equations.

co-simulation¶

Co-simulation refers to a simulation in which different simulation programs exchange run-time data at certain synchronization time points. A master algorithm sets the current time, input and states, and request the simulator to advance time, after which the master will retrieve the new values for the state. Each simulator is responsible for integrating in time its differential equation. See also model-exchange.

continuous-time variable¶

A continuous-time variable is a variable that is a continuous function of time inside each interval \(t_i^+ \le t \le \mathbin{^-t}_{i+1}\).

block¶

In Modelica, a block is a special case of a model in which all connectors are either inputs or outputs.

discrete-time variable¶

A discrete-time variable is a variable that changes its value only at an event instant \(t_i\).

events¶

An event is either a time event if time triggers the change, or a state event if a test on the state triggers the change.

model¶

In Modelica, a model is a special class in which the causality of its connector need not be specified.

model-exchange¶

Model-exchange refers to a simulation in which different simulation programs exchange run-time data. A master algorithm sets time, inputs and states, and requests from the simulator the time derivative. The master algorithm integrates the differential equations in time. See also co-simulation.

zero-crossing function¶

A zero crossing function is a function that is used by solvers to indicate when variables cross a threshold. For example, suppose a thermostat should switch off a heater when the room temperature \(T_r(t)\) crosses a set point \(T_s(t)\). For this case, a zero crossing function is \(f(t) = T_r(t) - T_s(t)\).

Zero-crossing functions are used by numerical solvers to detect where such discrete changes in a model occur. Specifically, at \(t=t_1\), they search for \(\tau \in \arg \min \{ t > t_1 \, | \, f(t) = 0 \}\).

direct dependency¶

A variable is said to directly depend on another variable if there is an algebraic constraint between these variables. For example, consider the model shown in Fig. 9.1. If the input \(u\) changes, then the output \(y_3\) immediately changes, whereas \(y_1\) and \(y_2\) only change after time is advanced. Hence, the output \(y_3\) is said to have a direct dependency on \(u\). Similarly, the state derivative \(\dot x_1\) directly depends on the input \(u\), and \(\dot x_2\) directly depends on the state \(x_1\). The outputs \(y_1\) and \(y_2\) directly depend on the states \(x_1\) and \(x_2\), respectively. Hence, unless time is advanced, if \(u\) is updated, only \(y_3\) needs to be updated, whereas if \(y_1\) and \(y_2\) need not be updated. Such information is useful to detect the existence of algebraic loops, and to implement certain numerical time integration methods such as the QSS methods.

Functional Mockup Interface¶

The Functional Mockup Interface (FMI) standard defines an open interface to be implemented by an executable called Functional Mockup Unit (FMU). The FMI functions are called by a simulator to create one or more instances of the FMU, called models, and to run these models, typically together with other models. An FMU may either be self-integrating (co-simulation) or require the simulator to perform the numerical integration.

Functional Mockup Unit¶

Compiled code or source code that can be executed using the application programming interface defined in the Functional Mockup Interface standard.

rollback¶

We say that a simulator is doing a rollback if its model time is set to a previous time instant, and all its state variables are set to the values they had at that previous time instant.

time event¶

We say that a simulation has a time event if its model changes based on a test that only depends on time. For example,

\[\begin{split}y = \begin{cases} 0, & \text{if } t < 1, \\ 1, & \text{otherwise,} \end{cases}\end{split}\]

has a time event at \(t=1\).

state event¶

We say that a simulation has a state event if its model changes based on a test that depends on a state variable. For example, for some initial condition \(x(0)=x_0\),

\[\begin{split}\frac{dx}{dt} = \begin{cases} 1, & \text{if } x < 1, \\ 0, & \text{otherwise,} \end{cases}\end{split}\]

has a state event when \(x=1\).

superdense time¶

Superdense time \(t\) is a tuple \(t \triangleq (t_R, \, t_I)\), where \(t_R \in \Re\) and \(t_I \in \mathbb N\). The real part \(t_R\) of this tuple is the independent variable for describing the continuous-time behavior of the model between events. In this phase, \(t_I = 0\). The integer part \(t_I\) of this tuple is a counter to enumerate, and therefore distinguish, the events at the same continuous-time instant \(t_R\) [LZ07].