November 30th, 2016 by Namkyeong Kim
Written by: Garron Fish – Chief Engineer
When a Modelica model is translated in Dymola, the process involves a Modelica code of the Dymola model that translates into a C code, and then this C code compiles and links into an executable called dymosim.exe. Typically, if the model fails, then an error message is created in the simulation log. However, sometimes an issue can cause dymosim.exe to crash and you get the message, as shown in Figure 1.
Figure 1. Windows dialog box that opens when a Dymola model executable crashes.
There are several reasons why this error can happen. But, the most common reason is a memory related issue, such as a memory accessing issue (the program is accessing memory and it should not be). Another can be a memory allocation/deallocation issue, for example a Modelica model with a huge number of states demanding more memory than is available).
Moreover, If the model is created from commercial libraries and/or with the Modelica Standard library and you are not utilising external code of your own (i.e. functions that link to C or Fortran code), then I recommend that you create a simple model that has this behaviour and email it to Dymola support. If external functions are used, then first create a test project to reproduce the issue. If these approaches do not work, then this article can be used to step through the dymosim.exe code and determine what line of code is causing the problem.
Note: To do the following step you will need administrator rights.
To be able to step through the C code, the dymosim.exe file needs to be compiled using a debug option. For doing this, firstly it is highly recommended that you create a backup copy of the ‘<Dymola installation directory>\bin\build.bat’ file.
This can be done by the following simple two steps below,
Followed by, right-click the copied build.bat file in your preferred location, and then click Edit. Search for /Ob1 and delete all these entries in this file.
Figure 2. Deleting the /Ob1 entries in the build.bat file copied in your preferred location.
Once all the /Ob1 flags have been removed from the file ‘build.bat’, then save it. After that manually copy this edited file back to the folder <Dymola installation directory>\bin. If you are using Dymola 2017 or Dymola 2017 FD01, then add /ZI to the compiler flags and /DEBUG to the linker flags to the Simulation Setup Compiler options as in Figure 3.
Figure 3. Compiler and linker setting used to create a debug version of dymosim.exe
If your version of Dymola is older than Dymola 2017 you will need to modify build.bat by adding /ZI to all the set CL and adding /DEBUG to all the set LINK.
If you are making use of Dymola functions that contain external code, then open your Dymola work directory and delete all exe files in this directory to make sure that previous compiled versions of the external functions are not utilised. Type cd in the Dymola command line to determine the work directory.
To debug the dymosim.exe, open Visual Studio and goto File->Open->Project/Solution and select .exe file types and select dymosim.exe from your Dymola work directory. Then, open <Dymola installation directory>\Sources\dsblock4.c in Visual Studio by using File->Open->File. Search for return dsblock_tid in dsblock4.c and add a breakpoint at this point.
Figure 4. Opening dymosim.exe as a project and adding a breakpoint into dsblock4.c
If you have created any external c function you can open the corresponding .c files and add breakpoints. If the code is compiled as .lib files, then build the .lib using the debug flags above. Then load the symbols using Debug->Options and selecting Symbols and loading the .pdb file containing the symbols, and open the source C code and add breakpoints.
Now press F5 and the model should simulate to the desired breakpoints and you can step through the code to find what is causing dymosim.exe to crash.
Remember to revert to the original version of build.bat.
Written by: Garron Fish – Chief Engineer