Previously on the Claytex Tech blog, we have deconstructed the Simulation log, explaining what each of the quantities identified within it relates to. But what about the Translation log? What is it? What do the quantities described there actually relate to? And more importantly, how can I use the information described there to improve my models?
In a nutshell, the Translation log details the internal structure of the last model translated in Dymola. As such, it can be used to guide the user in making various improvements to their model, from improving model efficiency to making it more robust.
For a detailed explanation regarding the translation process, and what it looks like under the hood, please see this previous edition of the Claytex Tech Blog. Here in this post, we will take a more practical view, relating translation log terms to modelling concepts.
Five key sections
A successfully translated model has a translation log of at least 5 entries. Various non-standard actions can create further entries, but in this post we will focus on the 5 present in every Dymola model. Initially, the model the log relates to is detailed, forming the first entry. Following this, Dymola determines whether the model can be translated. In a similar process as the model check functionality, Dymola counts the number of scalar unknowns in the model, then adds up the number of scalar equations present. If the numbers do not match, then symbolic manipulation cannot be performed, so the translation process is terminated. If they do match, then the actual translation process can begin. Confirmation of this process forms the second entry.
Moving onto the third and fifth headings in the translation log brings us to the most important information the log contains.
Expanding the third heading, Statistics, unfurls a plethora of data relating directly to the structure of the model we have translated. Each of the three descriptive headings relate to a separate aspect of the model; the model pre-translation (Original Model), the simulation model post-translation (Translated Model) and the separate model built to determine the initialization conditions of the simulation model (Initialization problem).
Model Statistics – Original Model
Before the symbolic manipulation stage occurs during translation, the model is simply the collection of Modelica code the user has assembled using the Dymola interface. Model statistics presented as part of the Original Model section relate directly to this un-manipulated model.
Model Statistics – Translated Model
To properly understand the Translated Model statistics, some knowledge of the symbolic manipulation process is required. Previous blog posts explain in detail this process, but in simple terms, Dymola seeks out states (state variables) within the model and uses these states to build a model of differential, linear, and non-linear systems to be solved.
Therefore, of immediate importance is the number of states a model has. While not a hard and fast rule, the fewer states a model has the quicker it will be. The number of Time-varying and Alias variables refer to the numbers of variables being calculated as dependants of the states. A general trend can be considered, that the smaller the model the quicker it will be. This makes logical sense, as there are less computational actions to be made.
In the second half of the entry, we see the numbers of linear and non-linear systems as well as the number of numerical Jacobians in the model, with both pre and post translation numbers given for the linear and non-linear systems. Primary importance to the modeler can be attributed to the post translation figures, as these are what is present in the model to be simulated. Linear systems are equation sets that can be solved in a linear fashion, using the Ax = b matrix method. A straightforward computational solve, the modeler should still be aware that each linear system will be an additional, albeit small, time penalty. On the other hand, the presence of non-linear systems in a model will slow its performance substantially owing to the advanced solving they require. Dymola attempts to create analytic Jacobian matrices during translation as part of the non-linear system solving process. However, in cases where Dymola cannot determine the analytic Jacobian it will instead calculate a numerical Jacobian. While the use of a numerical Jacobian can work just fine, this approach will generally be more computationally expensive due to the fact that additional calculation steps are required to generate the matrix. Minimizing the number of non-linear systems and numerical Jacobians in a model will make it quicker and more stable.
The flag Advanced.LogNonLinearIterationVariables can be set either from the Translation tab of the Simulation Setup window or from the commands window to enable the iteration variables of the non-linear systems to be displayed in the simulation log.
Model Statistics – Initialization problem
Start conditions for dynamic simulations are often of critical importance. With Dymola models containing literally tens, if not hundreds of thousands of variables, manually setting each variable’s start condition would be an impossible task, even for the best intern. Thankfully, Dymola has an inbuilt method of calculating the start conditions for variables the user has not set, the initialization problem. Exactly how it sounds, this is a separate model Dymola compiles (and runs) to determine the main model’s start conditions. As a result, it is subject to the same modelling considerations as the main model, where minimizing non-linear systems and numerical Jacobian will generally yield efficiency and stability benefits.
Settings
An addition to the translation log in recent versions of Dymola is that of the Settings heading, detailing various Boolean flags which affect the translation process of the model. Certain flags appear in this section if their value differs from the default setting.
Selected continuous time states
As mentioned previously in this post, the number of states a model has within it can have a sizeable effect on simulation performance. This section of the translation log lists all the statically selected states within the model, as well as a listing the groups of states Dymola uses for Dynamic State selection. The static list of states can provide the user some guidance as to potentially superfluous model functions which could be eliminated to improve speed (at the risk of changing the system dynamics). If present, the Dynamically selected continuous time states section is of particular importance. Dynamic state selection occurs when Dymola has not been instructed to use specific variables as state variables and is unsure which states will be optimal to select. If dynamic state selection is listed during translation, Dymola may chose to pause integration of the model and switch state variables during simulation. State selection is explained further in this previous blog post. By selecting stateSelect = always on the desired state variables in the Dynamically selected continuous time states section, the dynamic state selection can be eliminated.
Closing remarks
As with anything Dymola related, a sizeable chunk of information is presented to the user all at once, which can be somewhat difficult to digest at first glance. Hopefully, this short guide enables you to unlock some more performance from your models or make them more robust!
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