One advantage of Dymola and Modelica which is often talked about is the ability to build flexible and adaptable models. Models that, with the minimum preparation, can be used for a different task or have their effects change swiftly, following a simple reparameterisation. But how is that achieved? This blog will run through some of the commonly applied modelling techniques that you can use to improve the re-usability of your models by making them more adaptable.
Base classes and replaceable declaration
Component redeclaration is a powerful principle of Modelica, enabling models sharing a common base class to be changed for one another. Base classes contain common parameters or interface objects a family of models will contain. Such a class will be denoted as partial, indicating to the Dymola compiler and check function that it essentially is an incomplete model and is required to be extended. More detail needs to be added to complete functionality. This is done because a partial model can contain an unbalanced number of unknowns and equations, owing to its purpose as a foundation class for a family of models containing all common and shared features.
Figure 1: Partial models are most commonly found as base classes
Additionally, all partial models are required to be declared as replaceable when deployed inside another model. Once more, this is because of the partial declaration inside the base class. This means that any child model with the common parent base class can be redeclared as that component with the change class declaration. Therefore, changing between components within the model is simple and quick.
Figure 2: Template models often will contain partial base classes declared as replaceable, like in this vehicle template example from the VeSyMA library.
Conditional component declaration
Using a Boolean parameter, model declarations, connectors and connections themselves can be controlled conditionally and be adaptable. In effect, this means that you can instruct a model to not declare a certain component, removing it from the model code entirely. As this is a fully supported feature in Dymola, all connect statements featuring the removed component are removed as well.
Figure 3: Heat ports, needed for thermal effects, are often conditionally declared, especially if the component may not always be required to have thermal effects. This means the port can be removed from the model if the Boolean is set to false, removing it from the compiled model code along with any connect statements and parameter links.
This means components can be removed or enabled simply by changing one Boolean parameter. As this action effects the model code, the model needs to be recompiled before running, so this technique is unsuitable for making post-compilation changes to a model’s behaviour. The same principles apply for connectors and connections, meaning how components connect to one another can also be conditionally controlled.
Figure 4: An example of conditionally removed components and connectors. On the left, is the original model with all elements enabled; the right shows the same component in deployment, with various components conditionally removed. Note that the graphical representation of the connections remain, although these are inactive in the model code.
Conditional dialog boxes
In much the same way as a component can be conditionally declared based upon the value of a Boolean parameter, so can a parameter’s dialog box entry. This is particularly useful when conditionally declaring a component, as propagated parameterisation for the component can be disabled when the component is not being declared. Handily, this technique can make use of the same Boolean used to conditionally declare the component, albeit applied in the parameter dialog annotation than applied directly to the parameter declaration.
Figure 5: The heat port component in the image shown in the section above can be conditionally removed. Here, the same Boolean has been included in the temperature parameter dialog annotation, meaning it will be greyed out and disabled, preventing the user from thinking the parameter is active.
Creating “generic” models
Considering the model deployment environment can often provide the developer with a good idea of what technique should be used to make their model adaptable. As conditional component declaration cannot be used for models that are unable to be recompiled (such as real-time models), then another technique needs to be used. This is where the concept of generic models is very useful in certain situations.
Figure 6: This is the Claytex.Mechanics.Translational.SpringsAndDampers.GenericSpring model, designed to allow the characteristic of the spring to be changed post compilation.
Often with models, such as springs, specific parameters can control the response of the model directly. This means that they can be effectively reduced to zero output, therefore zero effect, on the wider system model. With this change effecting the parameterisation of the model, it is simple and easy to do.
A good example is the generic spring model in the Claytex library. Designed to be able to produce a linear, non-linear or force curve response, the overall generic spring model features all 3 types of spring model. When the user changes a Boolean parameter, the parameters passed down from the generic spring level model to the models producing the force are multiplied by zero on models not required for the specific response. This way, fundamentally the model in use has been changed, although there has been no structural change in the model, thus avoiding the need to recompile.
Conclusion
Building adaptable models mindfully from the outset with care towards what adaptability is required, enables developers to build more efficiently. Fewer models are required to be built to cover all the scenarios required. Model reuse saves time, and makes libraries more robust, as less maintenance is required. With less maintenance, there is less chance of bugs creeping into your library, as less used models fall behind more utilised ones. Not to mention, user time is saved with easier to use models which require less rebuilding, or recompilation, between configurations!
Written by: Theodor Ensbury – Project Engineer
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
