I have now been using Dymola and Modelica since 2007. Since then, I have learned a lot, been able to help users quite often and developed a few application libraries within Dymola. Some of these libraries have been included in the Dassault Systemes Dymola library portfolio for a number of years. Over this time, I have noticed some common (what I consider less-than-optimal) approaches when it comes to simulation software selection, software demo periods, and general approaches to simulation.
Simulation Software Selection
Once upon a time (in a previous job), I was working on developing a Hybrid and Electric Vehicle architecture selection tool for different customers ranging from motorsports to refuse collection trucks. At the start of the project we evaluated different software packages. This evaluation included a few packages, from Dymola (an object orientated symbolic math platform) to Matlab / Simulink.
Since we were short of time and the universities had done a good job of teaching us to use Matlab and Simulink during our undergraduate courses, we went for what seemed to be the obvious choice. The pressure of time and the fact that every team member knew how to use Matlab and Simulink drove us to continue down a (less-than-optimal) path for physical vehicle modeling. IE, the use of a causal programming language as opposed to an acausal modelling tool such as Dymola.
This same pattern is seen every day in many companies throughout the world. Short term, companies seem to think it pays off in terms of minimising learning investment and getting started earlier. However, in my experience using the right tool for the job, whatever that job may be, is absolutely key to reliable, efficient and robust delivery of work results in the short and long term.
In hindsight, using an object orientated tool like Dymola would have been a far better choice.
It often baffles us here at Claytex that Dymola isn’t used more in the OEM world for vehicle development. Motorsport is one of the most unencumbered industries in the world. If a better option exists, industries like the Motorsports are the first to switch. Dymola is irrefutably the most prevalent software used for full vehicle simulation at the top levels of Motorsport. Why hasn’t this trickled down into the road car manufacturers?
Demo Licenses
When the opportunity arises to try new tools, people should make the most of the support that the trial-issuing company has to offer. Trials are often time limited so it is important to make the best use of that time to achieve clearly defined goals.
At Claytex we do our absolute best to provide top notch support during demo periods. We believe Dymola is a great tool for many applications in Automotive, Aerospace, HVAC, Automation, Fluid Power, Nuclear Power, and too many other domains to mention.
At it’s core, Dymola is a acausal symbolic math engine. The object orientated nature of Dymola allows tremendous flexibility in the use of the Modelica language across multiple fields of physics, and can result in some very efficient multi-physics simulations. Our Dymola libraries provide an excellent starting point for automotive simulations in most of these areas. There are a number of other third parties which provide application libraries in different fields, plus there are numerous open source Modelica libraries that can be found on GitHub for modeling things such as Thermal Hydraulic Energy Systems etc.
Yourself
Try to be open minded about trying new ways of approaching your job. I often find myself in a stubborn mindset, and have to remind myself to keep an open mind. If you don’t have an open mind, it’s difficult to grow.
Ask for advice from experts if you have any questions or doubts. Sometimes just picking up the phone or sending an email with a question will not only help you on your current task, but also may open other doors in the future.
Be careful when making assumptions that a different software product does the job in the same way as the previous one. This is especially true if you have spent much time trialling a software product. One or two errant assumptions could cause you to decide not to use the trialled product. Don’t be afraid to let the software company know about something that appears to be errant or inferior. The actual error may be in your assumptions. Software suppliers and developers should be there to help.
Make use of expert groups on the web as they will contain members with a wide range of experiences and application areas that might be able to help you.
If the budget allows, look into getting some up-front training. You will gain invaluable skills that will give you a much better understanding of the software and help you improve and speed up your modelling. What you will try to learn in a day you will probably learn in an hour or two through training with an expert.
Do not assume that just because a simulation has completed with no crashes/errors that this is giving you the correct answer. Often tools that are “honest” or have been set up properly will prevent calculations being made for unphysical situations, and therefore give you warnings or errors when this ocurrs. Spreadsheet style “number crunchers” that produce results from a series of unchecked and unasserted calculations will not give you the true picture of how your modelled system will behave in physical terms. You will realise that what you thought was working fine is actually not when you impose physical constraints to it. Dymola is a good example of this as most physical models in its application libraries do have physical validity checks and constraints built into them.
Conclusion
Whether you’re working with Dymola and our VeSyMA Suite of libraries, or a competitor’s product, I hope some of the items discussed in this blog post help you become a better, more efficient, or more versatile engineer.
Alessandro Picarelli – Engineering Director
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.