3

In Dymola, I'm able to do something like:

when time > 100 then
    assert(false,"Simulation taking too long");
end when;

to stop simulations based on the time variable itself.

However, what i'd like to do is stop the simulation based on elapsed CPU time. Dymola has a way to output the CPU time and it shows up in the results as CPUtime, but I don't know how to access the variable. In other words, this is what i'd like to do, but the CPUtime variable isn't in scope:

when CPUtime > 100 then
    assert(false,"Simulation taking too long");
end when;

Any suggestions, either how to access CPUtime, or other workarounds to kill simulations based on cpu time?

Matt
  • 363
  • 1
  • 7
  • Dymola 2022 can stop simulation based on maximum wall-clock time (not CPUtime), maybe that is useful for you? https://www.3ds.com/products-services/catia/products/dymola/latest-release/ – Priyanka May 26 '21 at 16:31
  • Alternatively, you can use system calls to get the wall clock time and write your own tic-toc function. Then use terminate() operator to terminate the simulation. – Priyanka May 26 '21 at 16:45
  • related: https://stackoverflow.com/questions/61375492/modelica-total-time-calculation-of-simulation-and-equation-initialization – Priyanka May 26 '21 at 16:46
  • related: https://stackoverflow.com/questions/58320730/modelica-print-current-time – Priyanka May 26 '21 at 16:47
  • Yes the new Dymola 2022 features look perfect here, thanks for pointing that out. I also tried the tic/toc type solution, but I could only get it to work interactively (say in a script environment) rather than as a model within a simulation. May need to give that another go – Matt May 26 '21 at 17:03

1 Answers1

2

As already noted:

You can set this in Dymola 2022 in the simulation setup, or alternatively by setting Advanced.Simulation.MaxRunTime.

It's wall-clock time, which means that if you have a parallel simulation it will stop after 10s has passed and not when the cores together have spent 10s, and if you for some weird reason have a long sleep-call in the model it will still end.

(This was already noted in the comment - thanks Priyanka. However, stackoverflow for some reason warns that answers in comments may be lost.)

Hans Olsson
  • 11,123
  • 15
  • 38
  • Such a "weird reason" may be an incorrect external function or FMU that does not return properly. – Dag B Jun 03 '21 at 17:03