Like many programs, Dymola makes use of a working directory on your computer. Dynamically associated with Dymola, it acts as a location to write files required by Dymola. By virtue of being dynamically linked to Dymola, the working directory is very much a living part of the Dymola process. Therefore, having a solid understanding of how Dymola utilizes the working directory helps us while working with Dymola. We’ll cover both how Dymola uses the working directory and some recommended practices for users. I will also highlight some potential pitfalls and quirks of the Dymola working directory and discuss them as they arise.
How does Dymola use the working directory?
“Dynamically associated” as a computing term refers to a link a program has to another item, in this case a file directory. This type of link enables the program to write files to that location during normal operation. Examples could be results files but cover any file Dymola needs to write to the hard drive. Typically this can include:
- Dymola model elements (flattened Modelica and compiled C code) used to create the Dynosim.exe
- Executable files (Dynosim.exe itself and addendum library external executables used by the Dynosim.exe)
- Build and status logs
- Result files (trajectory files)
- Data outputs (Matlab .mat and text .txt files)
- Compiled FMUs and associated file structure
By default, the working directory is set to a folder within your “Documents” directory called Dymola. A user can change this to another location if they desire from within the Dymola application. It is generally considered sensible to leave the active working directory as the default location, as there are seldom write permission issues or other oddities which can occur with different locations on the hard drive. Dymola produces multiple files (some small, some large depending on the model) during translation, compilation, and simulation and if they are left in this default location it helps keep everything tidy on your computer.
How can users use the working directory?
Essentially, the working directory is a “known location” to Dymola (and its generated binaries) and can be used as the root of a local path built into a model. It thus can be used to avoid hardcoded paths to data files used by models. If the file is located in the working directory, then it can be referenced by name only in Dymola and will be read without issue. This can be useful if you want to change the data read by a model without having to reconfigure the model itself, although as explained below, this method should be used with caution. Any file output from a Dymola model, such as a result snapshot in .mat file can also be found in this working directory.
What should users be aware of regarding the working directory?
If a model is malfunctioning without a clear reason, it is not uncommon for experienced Dymola users to be heard discussing the need to “clear the working directory”. What this alludes to, is clearing out all of the previously compiled sub functions/executables and forcing Dymola to re-create them while running the model in question. These functions/executables are often external c code functions supplied in some Dymola libraries, which get compiled as executables by Dymola when a model containing them is run. As this code can be updated between library releases, they sometimes need to be re-compiled by Dymola with the new specifications. While this should happen automatically, sometimes they are not correctly deleted and recompiled. At times, a cryptic error message, usually pointing to class which is an external c function, can be provided. Manually clearing the working directory forces the new, correct functions to be created by Dymola.Helping Helen
Having to sporadically clear the working directory means that it is not an ideal long term place to store data or custom items. In short, it is nice for the user to be able to simply select all of the files in the working directory and delete them. It is therefore advisable to store data used by models or licenses in a separate folder to this directory to avoid accidental deletion. The same goes for important results files; with every run of a Dymola model, the existing result set from the previous run of the model is automatically overwritten. Therefore, it is good practice to copy any important results files out of the working directory immediately after simulation.
Sometimes, Dymola will automatically move the working directory if libraries are “opened” instead of “loaded” or loaded from a script. In these cases the working directory is silently changed to the loading location of the script or library. In opening scrips, it is good practice to add a line manually resetting the Dymola working directory to the desired location! A misplaced path for the working directory can lead to many files cluttering places they don’t belong (often in folders containing actual code from your revision control system… which can cause quite the headache!).
Closing remarks
While this may be a dry subject, knowledge of the working directory of Dymola, and how Dymola uses it, is important. Being aware of how and where relative paths can be used in Dymola can allow users to leverage this to their advantage. Clearing the working directory is often advisable when a model fails to run with a confusing or cryptic error message, especially if it refers to an external C function. Hopefully, you picked up one or two ‘nuggets’ from this post that will help you in the future.
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.
