While this blog post certainly isn’t as glamorous as Ford v Ferrari, the topic of understanding errors v warnings in the Dymola environment is important. Over the years, new users of Dymola (often trainees) have asked me questions about ‘errors’ that they’ve seen in the translation log. Many times, the ‘errors’ they are referring to are actually just warnings that the Dymola’s Modelica translator has issued. It seems that the yellow yield sign is unnerving enough for many new users to make them think that something has gone completely wrong. Recognizing the difference between the two makes new user’s reaction to errors v warnings a little more relaxed. We have written previous posts about translation logs, and even about the cleanliness of translation logs, but in this post we are just focusing on the difference between errors and warnings.
Errors v Warnings background
In the software engineering world, the difference between errors and warnings seems to be second nature. Many software engineers see warnings from compilers on a daily basis. With this kind of exposure, they have grown to recognize that warnings aren’t necessarily show-stoppers.
With that said, most software engineers also recognize that eliminating these warnings is in their best interest. A translation log with many warnings is generally something to avoid. In an ideal world, your translation logs will show neither errors nor warnings, such as the one below.
Most Dymola developers are NOT software engineers. I’ve met Dymola developers with many different backgrounds. These backgrounds range from Mechanical Engineers to Nuclear Physicists and quite a few in-between. While there have been a few software engineers, they are definitely not the norm.
Errors are show-stoppers. When there is an error in the translation process, the process is halted, and you cannot proceed. Errors generally indicate that something is substantially wrong and nothing worthwhile will result from completing the translation/compilation process. Sometimes, errors are due to variable type inconsistencies. Often times, errors are due to unbalanced equations and unknowns. It is also not uncommon for the compiler to have issues finding dependent resources. When an error shows up, you will need to debug and fix the problem in order to proceed.
While warnings are something that are good to eliminate, some warnings are fairly benign like the one below.
The warning above is simply telling the user that there are not enough initial conditions selected/enforced to allow integration to function. In order to proceed, the translator has picked what it believes to be a reasonable initial condition(s) which allows the integrator to start. Even though this sort of warning is fairly benign, not taking the time to eliminate this warning is not advised. Allowing your models to have warnings is a slippery slope. It won’t take long to have 55 warnings, which will cause you to miss the 56th warning which may clearly indicate a modeling mistake. That 56th warning may indicate that your model has something which if not corrected, will yield incorrect results. Here is a warning which clearly indicates that the user has made a modeling mistake, and should be fixed.
I hope this blog post is useful in helping you new users traverse the errors v warnings terrain. I also hope you choose to eliminate as many warnings as possible in your future models! 🙂
If you have any questions about this topic or another, please reach out to email@example.com and we will get back to you promptly!
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.