0

I have a simulation that is very slow at certain times (in my example shown below at time=358.65). In the eventlog.txt and dslog.txt there are no entries for this time. As a next step I set GenerateTimers and GenerateBlockTimers to true, but I had to stop the simulation and it seems in this case the Timer results cannot be viewed!?

  • First question: Can I somehow see the Timer results for interrupted simulations? Are they stored in some file?
  • Second question: Are there other ways to find out what Dymola is spending so much time on?

enter image description here After 8E4 seconds (22h) of CPUtime I stopped the simulation.
At simulation time 358.65 no events occured, but a lot of warnings related to negative temperatures and negatives pressures, so I assume the nonlinear solver is going in the wrong direction somehow!? So, I would like to identify the system of equations that is so difficult to solve at time=358.65.

matth
  • 2,568
  • 2
  • 21
  • 41

1 Answers1

3

First question: This is strange, for me after stopping a simulation I can open both, dslog.txt and eventlog.txt and they are containing the respective information.

Second question: There are a couple of ways to investigate the performance of a model. I assume you used some of them, but I'll nevertheless list them for completeness, going from simple to more advanced ones (anybody feel free to extend if I forgot something):

  1. Activate the flag "Include a variable for elapsed CPU time during simulation" in the simulation setup (Translation Tab). This will give you two additional variables, namely "CPUtime" and "EventCounter" in your result. This helps to indicate when a lot of time is consumed (CPUtime) and a possible reason for this (EventCounter). Alternatively you can set OutputCPUtime = true; from the command line.
  2. Check the simulation log for the "number of xxx events" whereas big numbers (> 1000) for state and step events are especially critical.
  3. Given you have many events (and your simulation is very slow at a certain time) it makes sense to interrupt the simulation by opening the command window running the simulation (dymosim.exe) and press CTRL+C twice. Then then you can enable event logging by entering le = true and continue the simulation by entering c. The output should indicate if events occur quickly. If many events occur and time does not advance the problem is likely "chattering".
  4. If that is not the case, the problem could be difficult to solve systems. This can be investigated by activating the flag "Which states that dominate error" in Simulation Setup (Debug Tab). This will indicate which state often limits the step size or causes the dominant error. If this is only a single or few states you can think about simplifying or removing them.
  5. Using profiling by setting
    • Advanced.GenerateTimers=true
    • Advanced.Define.PrecisionTiming=true
    • Advanced.DymosimRealTimePriority=true
    • will generate plotTiming.mos in your working directory. This will define a matrix which can be plotted by typing
    • RunScript("plotTiming.mos",true)
    • createPlot(grid=true, leftTitle="Execution time for step", bottomTitle="Simulation time");
    • plotArray(times[:,1],times[:,2],-1);
    • This creates a plot in which the execution time for every step is shown on the y-axis vs. the simulation time on the x-axis. So if you have a step size of 1ms defined and you want to simulate in real-time you should ensure that there are now marks above 1ms.
  6. More advanced profiling can be done by setting
    • Advanced.GenerateTimers=true
    • Advanced.GenerateBlockTimers=true
    • for which the results are shown in the simulation log.
    • For understanding this dsmodel.c should help (if you have the license to create source files from your model). The c-file contains links to the sections mentioned in the log's output.
  7. From Dymola 2018FD01 on you should be a able to right-click on the simulation result and select "Analyze Numerics" giving a dialog that should be self-explanatory.

For your specific case I think the points 1-4 should help. For 5 and 6 you should have more information in Dymola Manual Section 5.7.5.

Markus A.
  • 6,300
  • 10
  • 26
  • Thanks, this is a very helpful list, even though I had tried most of that already. It seems dslog and eventlog are updated continuoulsy during the simulation, but Timer results are added once simulation has finished successfullly, at least this is the case on my computer. – matth Jan 17 '19 at 09:08
  • Point 5 and 6 are the two points I had not done, and would be interested in, so I have a follow-up question: they seem to have the identical command, could you check? Did you mean BlockTimers vs Timers? And could you explain the generated plot a bit, the documentation in the Dymola manual does not show or even mention that plot, and it is unclear to me even what is plotted (ie axes labels would already help). – matth Feb 04 '19 at 10:38
  • Another comment, you can edit your answer to address it: Does `dsmodel.c` contain more information than `dsmodel.mof`? I had always used .mof for debugging so far. – matth Feb 04 '19 at 10:39
  • 1
    @matth: Thanks for the comments - I edited the answer. Point 6 was plain wrong - classic copy-paste error. And I tried to describe what the plot in Point 5 describes... – Markus A. Mar 20 '19 at 13:16