When creating models it can be difficult to work out the best route to getting the best result most efficiently and with the best usability.
Modelica and all the Claytex Libraries use a system of inheritance as described in the 8th Dymola Basics post. This means that extending from a model inherits all its components and variables, which is very important to determine a model’s usability. There is also a post about the differences between Duplicating and Extending. But this post goes into a bit of detail as to when best to use one vs the other method.
Where to start?
The first question is what is the goal for the model? Is it going to be used in a particular place or part of a larger system? If so, it may have to at the very least be extended from an interface.
For example, let the goal be to create an engine model for a vehicle using the VeSyMA Vehicle templates such as in the model below. You would need to directly extend from that interface or from a model extended from that.
If you are not intending to create something that is part of a larger system, then you have more options. If you are creating something semi-novel, that being a system that doesn’t exist but still fits within other systems (maybe a 9 piston engine or a 5 wheeled car) I would recommend finding an interface or template model in the developer libraries that applies to what you’re creating. Most of the time creating systems from other interfaces or templates allows you to utilise other libraries’ models and also experiments.
The final option is to create something from scratch as there is nothing that can be inherited from elsewhere. While there is nothing wrong with this, it does normally mean more work and more integration effort.
Where to start branching/extending from existing models
So you’ve found some templates/interfaces/models that you want to use as a base. Now comes the choice of how you want to use those.
First choice is what “level” of inheritance you want to start branching from. I find the best way to do that is work down from a fully working example model.
Then I start working down the hierarchy to the point where it can be modified to suit your means. That means that you inherit the largest amount possible leaving you with the least amount of work.
Explicitly:
Open a working model
Does the model have all the effects you want to model and the structure you want?
Yes – then try extending from that model and modifying the parameters and redeclare sub-models to achieve the model you want.
No, the structure is right but the subsystems aren’t the ones you want to use. – Try extending and redeclaring the sub-systems first. If the redeclaration is cast in stone, then you should duplicate the model and redeclare the subsystems to the ones you want then parameterise the subsystems.
No, the structure isn’t right – open the model that the model you’re looking at is extended from, by either looking at the Component Browser or the text layer. Then ask the same question again.
Repeat this process down the layers of the hierarchy to a point where you can branch off to make the model you want.
Examples
Let’s continue the example of wanting to have a different engine model. and I will go through 4 different scenarios.
So start from the VeSyMA.Engines.EngineModels.MappedPetrol fully working model. This is a working example, with multiple example use cases, bench tests, and is developer maintained with regular updates.
- Let’s say I want to create an engine with a different torque curve, mass and flywheel inertia. I can extend from VeSyMA.Engines.EngineModels.MappedPetrol and change those parameters as all of that already exists in that model.
- Now I want to create an engine with a dual mass flywheel but everything else is the same. I’d duplicate VeSyMA.Engines.EngineModels.MappedPetrol and redeclare the sub model flywheel to a dual mass model I’ve created that’s extended from VeSyMA.Engines.Interfaces.Flywheel.
- This time I want to create a mapped engine model with a simple emissions table. There are a few options here; if I want to create a one off, then I could extend from the VeSyMA.Engines.EngineModels.MappedPetrol engine and add in an extra block; or I could extend from VeSyMA.Engines.EngineModels.MappedPetrol, add in the emissionsTable interface and make it replaceable and make that a template; or I could duplicate VeSyMA.Engines.Templates.MappedEngine and add in the extra interface block to create my own template. Each has its pros and cons, which we will go into later.
- Finally I want to create a brand new engine that isn’t table based and doesn’t match any of the engines in VeSyMA – Engines; I would extend from VeSyMA.Engines.Interfaces.Engine and create a model/template from there. Extending from VeSyMA.Engines.Interfaces.Engine means that I would still be able to plug my new engine into any bench test or full vehicle within the VeSyMA libraries.
Pros and Cons of Extending vs Duplicating
Extending means that you inherit every architecture characteristic, parameter and variable declaration from the model you’ve extended. This has many benefits and a few things you need to consider.
If you extend from a model in a library that you don’t control, such as extending from the VeSyMA.Engines.EngineModels.MappedPetrol model which Claytex develop, then you inherit any bug fixes and improvements automatically when you update to a new version of the library. Of course this can mean that your models can change slightly as changes occur to the VeSyMA library.
If you have extended a model from a developer library and modified parameters/replaced models, then if parameters or components have changed name then you need to make sure that you run conversion/update scripts provided with the new versions of the developer libraries to ensure that those changes are implemented or it will potentially mean that you will end up with invalid references and links in your models.
Alternatively if you have duplicated the VeSyMA.Engines.EngineModels.MappedPetrol model then you now have more control over that model but at the same time that gives you more code to look after, moving forward. Functional changes to subsystems can cause more problems because while the result is going to be similar for the full engine model, the structure of the model may change from version to version which can break connections or change how models work.
Final Thoughts
My opinion is that the less you need to maintain, the better.
Extending from the highest level you can means that you’re only changing and controlling what you need to. That leaves a lot of the maintenance and testing to the library developers.
Written by: David Briant – 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.
