A model that does not run is very frustrating. Troubleshooting non-model related Dymola failures can sometimes be difficult. If the model code itself is valid, then a separate issue is causing failure. In this post I will outline some typical issues we have seen through support questions here at Claytex and how to remedy them. We will assume the user has a valid Dymola license already installed.
External libraries
Typically, if a user opens a model containing models from a library they cannot access, then Dymola loads what it can minus the missing dependency. When viewed from the diagram layer, missing components are indicated with a red square X. This occurs when the model is loaded and Dymola is unable to load the dependent libraries. Predictably, this will cause a failure to simulate. Troubleshooting this type of problem starts by determining which dependency is missing, and then determining why that is the case.
Missing library dependencies usually manifest in one of two ways:
- The library is not on your ModelicaPath
- You do not have a license for the library you wish/need to use
Library not on the path
The ModelicaPath is an environment variable established to inform Dymola where your libraries are stored. If a library dependency occurs and the library is not on the path, then Dymola will be unable to automatically load it. Fortunately, troubleshooting your ModelicaPath isn’t terribly difficult.
Updating the ModelicaPath to include a path to the missing libraries or manually loading the missing libraries fixes the issue. The ModelicaPath can be updated either in the Windows environment variable editor, or within the ‘Library Management‘ GUI within Dymola. Manual loading of a library can be achieved using the Dymola GUI, but also can be automated by writing a Modelica function.
From time to time Dymola may load an older version of the dependency which it finds on the path. In that case, a different error explained later in this post will be triggered.
Missing license file
As standard, Dymola ships with a substantial array of model libraries. Some of these libraries require the purchasing of an addendum license for use. In other cases, libraries developed by a third party – such as VeSyMA Motorsports library from Claytex – that are not included in the Dassault Systems installer may have their own licensing requirements, which will require a license directly from the vendor. In this case the licensing mechanism for the third party library must be installed and running properly. If this isn’t the case you may get the following popup.
When developing a model for distribution, be sure to know whether the recipient has access to the required library licenses. If third party licenses are limited in an in-house development setting, consider moving them to a server so they can be shared between the user base. Alternatively, consider the format in which the model is being distributed. Advanced options such as FMUs and executables enable Dymola models to be distributed between users in a relatively simple manner. However, if distributed in this manner, the model remains in a packaged state and cannot be modified in the same way as modifying a standard Dymola model.
Version support – Libraries and Dymola Troubleshooting
Dymola, like many software packages, is not static and is constantly evolving with each release. Under-the-hood changes are not uncommon with Dymola releases. Sometimes these are performance improvements made by the Dassault Systemes’ developers themselves, other times Dymola has to evolve in step with the Windows computational environment. In addition, the base libraries supplied with Dymola can and do evolve from release to release.
Effects can range from translation process differences (requiring model adjustments) to changes in how external objects are handled. Error reporting can therefore range from a change in model performance/ behaviour to a cryptic compiler error message if the error relates to an external object rendered unusable.
When customers purchase Claytex libraries, library maintenance is recommended with the purchase. There are several reasons for this. Third party vendors, such as Claytex, build and test library releases against the latest and specific version of Dymola. We go though an in-depth quality assurance process for each library release with the specific target Dymola version and generally the most recent previous version. Libraries are also tested as a release block, meaning versions cannot be mixed and matched.
Support for older library versions on current Dymola versions cannot be guaranteed, neither can current library versions on older Dymola versions. Therefore keeping up-to-date Dymola and library versions in sync is recommended. Using the current versions of Dymola and libraries at any given time is also encouraged to take advantage of new features, improvements and bug fixes. Claytex libraries come with conversion scripts to help you update your existing libraries to the new Claytex version. A little time taken at each release can save a lot of headaches down the road!
Relinquishing networked licenses
As I touched on before, using networked licenses hosted on a central server is a common solution to licenses shared by a user-base. More specialist licenses, like Dymola’s Binary code export or Source code export are good candidates for hosting on a network server. Sometimes, that license can be inaccessible on the server.
When the networked Dymola licenses are accessed, a hold is put on the license on the server. Effectively, the license has been loaned out and is presumed to be in use. Another user cannot use the same license, even if the instance of Dymola it is deployed to is sitting idle; the instance of Dymola using the license has to be closed for the license to be freed on the server. Troubleshooting this scenario sometimes requires help from whomever manages the license server as the logs may need to be interrogated to determine the cause.
Closing remarks
There can be various non-model related issues which cause a no-go situation for simulating a Dymola model. As with any software Dymola and its libraries rely upon a licensing system, which can cause issues to spring up somewhat unexpectedly. Version support is also important to consider, given the stack modern software is built upon. If you are confident in the model’s code, then hopefully this post gives you some options to consider while troubleshooting!
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.
