Written by: Theodor Ensbury – Project Engineer
Dymola has various ways of implementing switchable components with various configurations, specifications and versions. One such example, replaceable model declaration propagation, was presented in a previous blog post; the record class of Dymola models can also be used to perform a similar task. In addition to controlling the declaration of subcomponents, records can also contain all the parameters which will be passed through to the subcomponent. Use of partial base records enables the user to quickly add configurations and specifications which will then be immediately available across the library.
As with any technique, using records versus other methods of creating switchable components offers a unique set of advantages and disadvantages. Parameter values are easily shared at each level the record is passed, with various data sets easily made and used across a library of models. However, the flipside of using records to control all aspects of component switching is that a slightly idiosyncratic method is required.
To illustrate how to use records in this way, let us consider a simple one degree of freedom translational vibrational system, where we want to switch between a spring and a spring damper. In order to do this, we will need to implement a record structure and create a switchable component to switch between the spring and spring damper.
Figure 1: Test model to demonstrate the capabilities of records in parameterising and controlling components. Note the declared spring record is currently replaceable.
Outwardly the only difference between the model presented in figure 1 and a traditional translational one is the presence of the partial switchableRecord. However, rather than parameterising the switchableSpring model individually, the switchableRecord is redeclared (to either of springRecord or springDamperRecord, from the baseRecord as explained later), populated and then passed into the switchableSpring model akin to a single propagated parameter. The switchableSpring, as we will see, is constructed in a specific way to harness and utilise this functionality, containing both the spring and spring damper models we wish to switch between.
The parameterising record and base class
In the test model presented in figure 1 we can see the switchableRecord is declared as replaceable. As other records are to be extended from it, it is a partial record; therefore, it is required to be declared as replaceable when declared within a model. Partial records have similar inheritance characteristics compared to partial models, meaning that all parameters declared at this level are present in all records extended from it. However, there is one key difference between record and model inheritance. Whereas two replaceable models can have differing variable declarations within them, records cannot, as they are primarily designed to be used to preserve data structures. This is why all variables to be used in all permutations of the end model must be declared in the baseRecord.
Therefore, within our baseRecord we declare all parameters to be used by all permutations, including any Booleans used to control the configurations of the model.
partial record baseRecord parameter SI.TranslationalSpringConstant c "Spring stiffness"; parameter SI.TranslationalDampingConstant d "Damping coefficient"; parameter Boolean includeDamping "Boolean to control damping declaration"; end baseRecord;
For the standard springRecord, damping is not required. This means we can finalise the includeDamping parameter to false, as well as d to 0. This leaves the only non-defined parameter to be c, which the user can then set when parameterising the spring. To remove confusion for the user, parameters which have a definite value, or are superfluous to the specification of component dictated by the record, are finalised to remove them from the dialog box.
record springRecord extends baseRecord(final includeDamping=false, final d=0); end springRecord;
A similar ethos is applied to the springDamper record. As damping is included d is left for the user to populate as well, with the Boolean includeDamping set as true in the extend statement.
record springDamperRecord extends baseRecord(final includeDamping=true); end springDamperRecord;
The switchable model
The first thing the switchableSpring model must do is to receive the data record containing all of the parameterisation information. As eluded to earlier, this is done in a very simple way, by using a replaceable parameter at the start of the model.
model recordSpringDamper extends Modelica.Mechanics.Translational.Interfaces.PartialTwoFlanges; replaceable parameter recordBlogPost.springRecord data=switchableRecord constrainedby recordBlogPost.baseRecord "Record import parameter" annotation(choicesAllMatching=true);
The value of the parameter should be set to the name of the record which will define it. In our case, that would be switchableRecord, as it is this record which will be redeclared from the baseRecord to either the springRecord or springDamperRecord and populated to define the characteristic desired of the switchableSpring. This has been done in the text layer here but could also be done in the dialog box if so desired, by using the Insert Component Reference option when right clicking on the dialog box for the parameter data, as per figure 2.
Figure 2: How to link the switchableSpring with the switchableRecord.
This means that the parameter data depends entirely on the redeclaration and subsequent population of switchableRecord. All parameters that were set in the springRecord are now held in the switchableSpring model under the parameter data. This means any parameter contained within the parameter data can be accessed in the same way as accessing data from a sub model.
Dymola natively supports the control of model declaration by use of Boolean values; if a component is deactivated by a Boolean, then that component, along with associated connect statements, is removed from the overall model. It is this feature which enables records to control the ability of a component to switch between one sub model and another.
Modelica.Mechanics.Translational.Components.Spring spring(c=data.c) if not data.includeDamping; Modelica.Mechanics.Translational.Components.SpringDamper springDamper(c=data.c, d=data.d) if data.includeDamping; equation connect (flange_a, spring.flange_a) ; connect (spring.flange_b, flange_b) ; connect (springDamper.flange_a, flange_a) ; connect (springDamper.flange_b, flange_b) ;
More components could be declared and controlled in the same way.
Using the test model
The only thing the user now has to do in order to switch the switchableSpring between the characteristics of a single spring or single spring damper is to redeclare the switchableRecord through the Change Class option to either a springRecord or springDamperRecord, and populating the variables presented in the dialog box. However, it must be remembered to delete any inputted damper value when moving from the springDamperRecord to the springRecord, as this parameter is already declared and finalised in the springRecord and would cause a conflict.
If desired, the switchableRecord can be declared as a parameter, like the parameter data in the switchableSpring, to enable the declaration of the record to be used to be located at a higher level. If this is done, then the record can be redeclared without needing to clear parameters like above, as Dymola effectively overwrites the previous declaration entirely.
The Modelica models and records which comprise the test model described can be downloaded here. All pre-existing models used can be found in the Modelica Standard Library so the example model can be built by any user.
Written by: Theodor Ensbury – Project Engineer