Glossary

Acausal

Can refer to the order of computation of variables (computational causality) which is not defined in a Modelica model, but partially deduced during a compilation stage known as "causalization" and completely determined during a simulation by numerical solvers. For example, the equation "F = ma" only gives the constraint relating 3 variables, whereas the assignment "F := ma" is explicitly saying that the output "F" should be calculated by multiplying the inputs "m" and "a". For causal models, a separate expression "a := F/m" must be used if "a" should be computed from "F" and "m". Can also refer to the nature of a model with regard to time (physical causality). In a physically causal model the future values of the state variables are determined by the current state of the model. In a physically acausal model, the current state can be constrained by the future evolution of variables. Modelica models including dependent continuous state variables are physically acausal model and a state reduction step is necessary to determine a set of "causal" continuous state variables. Discrete state variables are not subject to physical acausality in Modelica.

Adapter

An adapter is a specific kind of model that is used to define the relationship between standard and external port variables. The package Simcenter Amesim contains several examples of adapters. An adapter model can be used simply to connect variables, but may also apply transformations such as unit conversions and modifications to accommodate different sign conventions. In addition, an adapter can modify the state variables, e.g., by defining a derivative of the position variable in the Modelica source model in order to provide the speed variable at the Simcenter Amesim port. Finally, an adapter must define the causality of the variables on the port in order to conform to the causal structure of C-based Simcenter Amesim submodels.

Algorithm

An algorithm section is a series of assignment operations (e.g., x:=1). Unlike equations (x=1), the sequence of operations is defined in terms of local knowns (inputs) and unknowns (outputs). In this way, the developer may treat algorithms like a script whereby it is possible to perform operations such as control loops, while statements and multiple assignments to the same variable.

Annotation

An annotation is piece of additional information that can be attached to several parts of a model, like an equation, a class or a component declaration. For example, annotations can be used to specify graphical information for icons or diagrams, or to add html documentation. Annotations can also be used to provide information about how to simulate a model (e.g., simulation duration or preferred solver tolerance). See also Vendor-specific annotation.

Assignment

An assignment in Modelica, signified by the ":=" symbol, states that the left hand side (local output) can be computed from the right hand side (local input). Equations, on the other hand, use the symbol "=" to express a relations between variables without specifying which are the inputs / outputs.

Attribute

An attribute is a piece of information that gives information about a predefined type. For example, the built-in class Real contains attributes such as min, max, units, etc. Attributes of a class are pre-defined, meaning that the developer can only change the values assigned to the attributes of a component, but not the attributes themselves.

Base class

A base (or parent) class is any Modelica class that is intended to be reused and extended by a child class. For example, the electrical library defines a partial model of an electrical system with two pins without defining the relationship between the current and voltage variables defined therein. The child class can then inherit the variable declarations and equations from the base class and add to them, e.g., by adding v=i*r; to balance the system of equations. See also Child class.

Causal

See Acausal.

Child class

A child class is any Modelica class that is derived from another one, e.g., via the extends keyword. In this way, child classes can add declarations or equations to the parent (base) class in order to add features of interest to the parent class. See also Base class.

Class

A class is a software term for description that can be used to create ("instantiate") an object of a particular kind. Modelica defines several kinds of classes: packages, models, blocks, connectors, functions, records, or types.

Code generation

Code generation refers to the process by which the Modelica compiler outputs the .c and .spe files that are used by Simcenter Amesim for simulation.

Compilation

Compilation is the process by which a model is converted into something that can be executed (i.e., invoked by a numerical solver to produce simulation results). The process of compilation has several steps, and is described in more detail within the Modelica Platform manuals.

Component

A component is a way to refer to an instance of a class that has been declared within a model. For example, a battery model may consist of several components such as a resistor, a capacitor, a voltage source, etc.

Connector

A connector is a specialized class that only declares a set of variables (no equations are permitted). Models and blocks may have one or several connector instances (ports), which can be related using "connect equations". Port variables can be given the prefix flow to indicate that the variables connected together must sum to zero. Otherwise, connected variables share the same value.

Declarative language

A declarative language such as Modelica is one in which the relations between variables is declared via a group of equations. This is in contrast to imperative (or procedural) languages such as C whereby the sequence of operations to be executed is specified. See also Acausal and Causal.

Derived class

See Child class.

Diagram

A Diagram (or sketch) is a graphical representation of how components are connected together within a block or model class. The Diagram annotation is used to store this graphical information within the class.

Dynamic state selection

A dynamic state selection strategy is one that changes over the course of the simulation. That is, different variables are chosen to be the continuous state variables as the simulation progresses. This does not imply that the number of state variables changes over time. See also State selection.

Equation

An equation is a relation between variables using the symbol "=". Unlike assignments, there is no concept of inputs (knowns) or outputs (unknowns), but only the declaration of the relation. This is the algebraic constraint on the system of equations (DAE's) that must be solved during simulation. See also Assignment.

Equation sorting

Equation sorting is the process by which the compiler determines the structurally strongly connected sets of equations in a model. For example, Tarjan's method can be used to rearranging the system of equations into block lower triangular (BLT) form.

Equation tearing

Equation tearing refers to a class of semi-numerical algorithms that can be used to break algebraic loops in a system of equations. Consider for example the system of equations x = f1(y) and y = f2(x). One can use equation tearing to set an initial guess x=x0, then calculate y=f2(x0) then x = f1(y), and iterate on x until the system converges (i.e., |x-x0| < ε ). It is the job of the compiler to manipulate equations to optimize a model with regard to particular criteria (e.g., the sizes of strongly connected equation systems or the numerical accuracy in the computation of residuals).

Evaluate parameters

An evaluated parameter is one which is assigned a value during the compilation process. This is done to optimize the generated code, and can be particularly effective when conditional expressions can be eliminated by fixing the value of a parameter, and thereby knowing that certain logical branches will never be invoked. In Simcenter Amesim, a compiler option is available to force the evaluation of all model parameters in order to improve the simulation efficiency. Additionally, the Evaluate=true annotation (described in Section 17.3 of the Specification) can be used to indicate whether or not a parameter should be evaluated.

Event

An event is an "interesting" point in time during a simulation, corresponding for instance to a behavioral change that occurs instantaneously, e.g., when a bouncing ball model detects that the ball has hit the ground. Events trigger numerical discontinuities that must be handled by the simulator, e.g., by using iterative methods to precisely locate them. See also Zero-crossing function.

See Programming events section for details.

External connector

An external connector is an extension of pure Modelica used by Simcenter Amesim to indicate that it will be connected to an Simcenter Amesim port. External connectors are used in adapter models to indicate things like the port type or causality. See also Adapter.

Flat Modelica

Flat Modelica is a term that refers to the intermediate output of the compiler after the "flattening" stage. At this point, all equations and variables from referenced or inherited components have been assembled into a single ("flat") system of equations. While this often resembles Modelica code, it is not true Modelica. Additionally, each Modelica tool has its own intermediate representation of the flattened model, and so Flat Modelica is not a standard format.

Guess value

During initialization, the simulator must find a set of values for all the variables that brings the residuals within tolerance. The Modelica model can provide information on the initial values for any variable via the start attribute. By assigning fixed = false to that same variable, information is sent to the compiler to indicate that the provided start value is only an initial guess for an iterative solver and is allowed to change. In contrast, setting fixed = true indicates that the start value is known and should not be considered an iteration variable when solving the initialization problem. More details are provided in the Modelica Compiler documentation.

Icon

An icon is a graphical representation of a model or block. Whenever an instance of that class is added to another model, its icon will be displayed. In Simcenter Amesim, a class icon is displayed next to its name in the Library Tree.

Imperative language

See Declarative language.

Index reduction

Index reduction is the process of reducing the higher index problems (i.e., problems where the Jacobian of the algebraic constraint equations is singular) in order to make the modified DAE system solvable. Formal methods such as the Pantelides' Algorithm can be used to create an index-1 problem by introducing derivative terms for some of the constraint equations.

Inheritance

Inheritance refers to when one class inherits the properties of another, with the assumed purpose of adding new functionality. In Modelica, the line extends BaseClassX; means that the child class will include all the variable / component declarations and the equations in the base class.

Instance

An instance is the object that is created when a class is declared (used).

Model

A model is a collection of variables and constraints that define their relationships in the form of Differential Algebraic Equations (DAE's).

Modelica Language Specification (MLS)

The Modelica Language Specification is the document that defines the syntax and semantics of the Modelica language. It is defined and maintained by the Modelica Association, an open community of developers. The document is available on the Modelica website at

Modelica Standard Library (MSL)

The Modelica Standard Library is a freely distributed package of Modelica models created and maintained by the Modelica Association. It is intended to be used as the basic building blocks of more complex Modelica models and can be downloaded from

Modification

A modification is what happens when an attribute or element of a component is changed from its default value. For example, Real x(min=10); declares an instance of type Real, but modifies its min attribute to a value of 10.

Multiple inheritance

When a class extends from more than one child classes, this is referred to as multiple inheritance. This could be done, for example, to extend from the Modelica.Icons. Example to display that icon and also extend from another class, e.g., to inherit the basic variables and equations of an electrical model.

Object-oriented

Modeling languages such as Modelica make use of this concept to leverage certain aspects of object-oriented programming paradigm (e.g., inheritance, encapsulation and extensibility).

Package

A package is a collection of Modelica classes and constant components. Packages are primarily used to organize groups of similar models into hierarchical libraries. Packages can be "stand-alone" (i.e., all contained classes are part of the same .mo file), or "structured" (i.e., some of the contained classes may exist as separate .mo files under specific naming conventions).

Parameter

A parameter is a variable (declared with the prefix parameter) whose value does not change during the course of a simulation. It may, however, change between multiple runs of the simulation. For example, mass is often treated as a parameter because it doesn't change during the simulation, but the analyst may wish to sweep through multiple values of mass to understand its impact on the behavior of the system.

Parent class

See Base class.

Partial model

A partial model is a model that is not completely defined (e.g. insufficient number of equations), and thus cannot be directly instantiated. This is often used to create base classes with commonly used variables and equations, but leave the specific behavioral equations in the child classes. For example, the electrical library uses a partial model to define current and voltage in two-pin base class, but leaves the behavior equations like v=iR or der(v)=iC in the child classes. The keyword partial is used to clearly indicate to the compiler that this model should not be instantiated, because it is known to be incomplete.

Port

An instance of a connector class. See also Adapter.

Prefix

A prefix (or type prefix) is a keyword that is placed before a component or variable type to add specific properties. For example, the prefix discrete can be used to define a discrete variable, and the prefix flow can be used to define a flow-variable.

Procedural languages

See Declarative language.

Protected

The keyword protected can be used to create a section of private declarations. Unlike public sections, a Modelica tool can place certain restrictions on how protected elements are accessed or modified. See the Modelica Language Specifications for more details on the kinds of restrictions imposed.

Public

See Protected.

Redeclaration

A redeclaration is a modification that changes the definition of an inherited replaceable element, keeping the same element name. For example, the electrical library's StepVoltage model includes the declaration:

Copy

extends VoltageSource(
redeclare Sources.Step signalSource(height=V));

where the replaceable component signalSource within VoltageSource is redeclared to be of class Step. This is one way to use inheritance for increased model reuse, while allowing customizations for the particular needs of a given child class.

Replaceable

A replaceable element is one which may be redeclared (see Redeclaration). For example, if model A includes the declaration replaceable Resistor res1; from the electrical library, then model B can include an instance of model A with a modifier to change the instance res1 to another type-compatible class, e.g., model A (redeclare HeatingResistor res1);. This is legal because the interface for class HeatingResistor is type-compatible with Resistor.

Semantics

Semantics are the rules that define what a particular collection of terms means. Whereas syntax defines how to arrange terms to construct valid programs, semantics drive program interpretation. For example, the code 5=true; conforms to the syntax rules of Modelica, but its interpretation would "go wrong" if attempted. See also Syntax.

Singular system

A system of equations is singular if the associated matrix does not have an inverse. This type of error typically occurs when trying to solve a system where there are too few linearly independent equations for the number of unknowns.

Start value

See Guess value.

State selection

A state selection strategy is the process of identifying which variables within a model should be considered the continuous state variables. State selection also includes the potential for identifying algebraic constraints to eliminate continuous state variables (sometimes called "state reduction"). For example, if two inertias are coupled via a clutch, their rotational speeds (while both being potential state variables) are not independent. A good state selection strategy should identify this algebraic constraint and select only one of the two inertia speeds as a state variable. The user can guide the compiler to (not) choose certain variables as candidate state variables via the modifiers like:

• T(stateSelect=StateSelect.prefer), or

• x(stateSelect=StateSelect.avoid)

See Section 4.8.7.1 of the Modelica Language Specification for more details.

Static state selection

A static state selection strategy is one that is entirely performed during compilation. That is, selection of which variables will be considered state variables is made during compilation and will not change during the course of the simulation. See also State selection.

Structural analysis

Structural analysis is the stage of compilation whereby a dependency graph is constructed between the equations and the variables. This is used to determine an efficient way to sort and solve the system of equations.

Structured class

A Modelica package can be saved as a hierarchical directory structure (a "structured class"), or as a single file (a "non-structured class"). When a package is structured, the name of the package class should match the name of the folder in which it is stored, e.g., a package class named MyModels should be stored as a package.mo file inside a folder named MyModels. The first line of a package.mo file contains the within clause to identify its place in the package hierarchy. See Section 13.2.2 of the Modelica Language Specification for more details. The Modelica Editor gives you the option of how to store files when using the New class dialog.

Symbolic manipulation

Symbolic manipulation refers to methods that manipulate mathematical expressions in their analytical form to derive exact solutions. This is in contrast to methods like floating point arithmetic that solve an equation numerically.

Syntax

Syntax is the set of rules that defines how certain words or symbols are allowed to appear in a program, without defining any meaning to the resulting phrase. See also Semantics.

Vendor-specific annotation

A vendor-specific annotation is information that can be useful for tool-specific actions. The convention is that such annotations are preceded by two underscores followed by the company or tool name. For example, annotation(__imagine(port(port_type=elect))) tells Simcenter Amesim that a particular connector should be generated as Simcenter Amesim electrical port in the generated submodel is being generated.

Zero-crossing function

A zero-crossing function is a function relating discrete quantities with non-discrete quantities and defining when events occur during the simulation of a Modelica model. For example, if a model includes something like when y <= y_limit… then the function f(y, y_limit) = y – y_limit is a zero-crossing function, which will flip from positive to negative when the expression of interest becomes true (i.e., the function crosses zero). An event can be anticipated if its corresponding zero-crossing function is explicit with respect to time, otherwise, a simulator may try to precisely locate events using iterative methods, e.g., via Golden Search or Regula Falsi methods. See Programming events section for details.