Making flexible models: utilising the replaceable model declaration
One of the easiest ways of handling the propagation of a plethora of parameters from model variants designed to be replaceable (sharing a base class) is the replaceable model declaration. As my colleague demonstrates in a previous blog post, such a declaration is extremely useful in enabling the developer to build flexible, efficient models capable of handling multiple use cases. It is easy to see from a model reuse stand point the benefits of this.
However, the apparent downside of using the replaceable model declaration is that when a different model variant is chosen from the list of compatible models, any parameterisation of the preceding model variant held at the top level of the model is overwritten by the new model top-level declaration. If the parameterisation of the two models is entirely different, this is not an issue. Alas, replaceable models are linked by their base class, which inevitably means that some parameterisation will be common between variants. When you would like to retain the user-inputted values whilst switching the model variant, you’d have an apparent issue…
The effect of redeclaring a replaceable model on the parameter inputs at that level
A good example is the parameterisation of a suspension bush model as found in the Claytex library. You want to change the model (thus variant) of the bush used, but they share a base class. If you parameterise all the base class variables directly from the propagated replaceable model declaration, then they are lost if you change the declared model variant. So, in our example of a suspension bush, all the orientation parameterisation would be lost if you changed say from a linear model to a non-linear model; parameters you may not want to change when changing the model variant, as the deployment of the bush remains the same.
Separating out the base class parameters
The solution is simple; at the top level/level of parameterisation, declare all of the common parameters you wish to preserve when the variant is changed, which are present in the base class. Instead of linking these parameters to the replaceable model declaration, link them to their respective parameters in the base class constraining clause, as below. Therefore, as the propagated parameters are unaffected by the replaceable model redeclaration, they remain at the level of parameterisation after switching. As links between the propagated parameters and the base class parameters are in the constrainedBy declaration, they do not change either when the variant is switched, therefore the parameterisation of the common parameters is retained despite switching the variant.
Parameters found in the base class are manually propagated to the top level, then linked (and finalised) to the respective parameters in the base class of the replaceable model declaration. This means they are independent of the main replaceable model declaration, and thus not overridden by a change of model variant.
This little trick makes it a lot easier to harness the replaceable model declaration to create flexible models capable of deployment in various use cases with different variants, whilst avoiding extra unnecessary work re-parameterising the same parameters each time or losing updated settings.
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