Translation in Dymola is fundamental in the process of creating a simulation model. All components comprising of Modelica code are assembled and interpreted by Dymola, resulting in C code which is then compiled into some form of binary. It is this binary which is the end product of Dymola simulations. There are various tools in the Modelica and Dymola arsenal that influence the translation process. We will cover a few of these in this blog post.
We as developers can use these tools to manipulate the model’s characteristics to our desires. Many of these tools are already covered in the Claytex blog, such as utilizing inline annotations, adding filters to break up non-linear systems, optimizing state selection and manipulating the derivative used for a function. In this post, I will introduce 3 tools, used more than others, to influence the translation process.
The “HideResult” annotation
Recording of variable values during simulation is usually controlled by assigning the variables to either a public (default) or protected section in the text layer. By definition, this corrals variables at the macro scale. The HideResult annotation however enables the user to suppress the recording of specific variables during simulation.
Primarily, this enables superfluous variables to be omitted from the results set. Less data we aren’t interested in means a smaller result file, with the handling benefits that accompany it. Additionally it enables the developer to suppress variables from being recorded which might confuse the end user. This is particularly useful when developing apps to be distributed. Selectively suppressing sensitive result variables can negate the need to fully encrypt the model.
For more information on the HideResult annotation, please see page 232 of the Modelica language specification (version 3.4).
The “GenerateEvents” annotation
Event generation in a Dymola model is a double edged sword. Often, simulation accuracy is traded for simulation speed, and vice-versa. They are triggered when a state or sign (zero-crossing) changes, with integration halted and the solver iterating to find the precise point of change. Unlike other Modelica classes, by default functions do not trigger events when a state changes or zero-crossing/crossing occurs.
Generally speaking, avoiding events where possible is good practice. Depending upon the system being simulated, events may be required for simulation accuracy, particularly if the model is sensitive to the effect of the crossing. Therefore, the GenerateEvents annotation enables the crossing functions of a function to trigger an event.
By default functions do not trigger events, and thus setting the annotation GenerateEvents = false appears to have no effect. Only when GenerateEvents = true is set can this setting have an effect. For more information on the GenerateEvents annotation, please see page 233 of the Modelica language specification (version 3.4).
The “impure” class prefix
Following the computer science definition of functions as being either pure or impure, Modelica requires impure functions to be designated as such. By default, Modelica considers all internal functions to be pure, i.e. true mathematical functions dependent entirely on their input. Any function with an output (or effect) dependent on anything other than it’s input (such as previous call history, etc.) needs to be designated as impure using the impure class prefix. This is because the solver cannot use this function to generate candidate solutions during the iterative solving process. Therefore, a class prefix is used to indicate this to the Dymola translator.
External functions and purity
External functions are required by Modelica to be specifically designated as pure or impure. This is because the call history of the external function has the potential to affect the answer (therefore unable to be identified as a function input by the translator). As you can imagine, during an iterative process this could have multiple unintended side effects on the solver condition and thus model accuracy, performance and stability.
It is important to correctly designate functions used in the model as impure (or pure) where required. Certain limitations exist regarding the calling of impure functions. They can only be called from:
- Inside another function marked as impure
- Within a when equation or when statement
- The
pure(impureFunctionCall(…))statement, which enables the support of calling impure functions from a pure context - Within an initial equation or algorithm
- Inside variables declared as parameter binding
For a comprehensive understanding of the semantics of using the impure prefix, please see pages 147-149 of the Modelica language specification (version 3.4).
Closing remarks
The Modelica language is an inherently flexible one, with many tools to adapt a model to the developer’s specifications. As these tools effect the translation process, they fundamentally alter the model characteristics. This must be remembered when deploying them, as re-translation, thus re-compilation is required to change their setting. These tools are a benefit in some deployed scenarios, but a potential pitfall in others, so as always we need to be aware of the intended application! Mastering advanced tools such as these can help us create leaner, more stable and effective models. Hopefully, they will be of help to you.
Nate Horn – Vice President
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion