This is a glossary of terms used when talking about Dymola and Modelica.
Class
All of the following are defined as a Modelica Class:
- Record – used to define data structures
- Block – fixed causality normally used within control systems
- Types – can be used to extend built-in types. These are also used when creating units
- Model – generic class
- Package – used to define libraries of classes
- Connector – used to define the structure of ports in any modelling domain
- Function – used to represent mathematical functions
State variables
A state variable is a variable which represents the state of a system. For example: for 1d mechanical rotational components, state variables are usually defined as the rotational velocity and the rotational position of a flange. The former tells us what the velocity of the flange is and the latter defines the angular position of the flange. Real state variables are those variables which are differentiated at least once within the equations
Although there may be many candidates for state variables, not all may be needed to track or describe the behaviour of the system. Dymola automatically selects what it thinks are the required state variables but the user can manually override this by using the stateSelect attributes found within most of the parameter dialog box tabs for components
To view the selected states within the model, in the simulation window select Experiment Setup > Translation > List continuous time states selected to view a list of the selected states within the Messages window translation tab
Dynamic State Selection
Dynamic State Selection means that Dymola can change the state variables being used during simulation. During translation, Dymola will analyse the model and determine a number of possible time states from which it will select a subset for simulation. As the simulation progresses, Dymola may choose to select a different set of states. When this happens the solver stops, the new states are selected and then the solver restarts. Using dynamic state selection does cause CPU time penalties but it makes it much easier to get complex models working where it might not be immediately obvious to the user what state variables should be selected. To avoid dynamic state selection the user can manually set the states through the component parameter dialog boxes within the model.