Have you ever picked up someone else’s Dymola models (or even ones you’ve built in the past) and thought to yourself – WHAT A MESS!? – or WHAT IN THE WORLD WAS I DOING HERE?! Organization is the first step to eliminating this sort of response.
When creating models within Dymola (similar to most programs) if one isn’t disciplined it is easy to wind up with an end product that severely lacks organization. In Dymola this is often the case in the code layer. Whether this is due to adding components via the diagram layer, copying and pasting items from other models, or simply expanding a model’s complexity over time the code layer is often left in a sadly disorganized state.
Some things that are often neglected:
- Multiple public versus protected sections
- Parameter and variable declarations in random groups/locations
- Orphaned parameter declarations
- No default values defined for constants or parameters
- No descriptions in variable declarations
- Remnants of equations that didn’t work (commented out)
In order to avoid this, it is good practice to stick to a well thought out/consistent model code structure. While not strictly necessary (Dymola is flexible on much of this) it will make your models easier to follow/understand. Future work on the model (whether it is by you a year after coding or by another developer) will be easier if the model is left in a ‘clean’ state.
Once the model is functioning properly and nearing completion I like to spend a little time re-organizing the code to make it adhere to the structure that I’ve evolved to over the years. The following is the generalized format to which I like to adhere:
Final remarks
While it’s not 100% necessary, taking a few minutes to clean up your code layer at the end of the project is one step in a best practices approach to Dymola modeling. Simple code layer organization is a big part of this… and something that would make your mother proud. So do it!!!
Once the structure is nicely organized it’s probably a good time to look over the documentation for the model, model description, variable declaration descriptions, and component declaration descriptions. It’s pretty common for people to slack on those as well! 😉
Now it’s time for me to go back and practice what I preach. I don’t remember doing this on my current project… oops! #facepalm
Written by: 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