Tiny simulation steps after recent nightly build

[stig]

I'm not sure exactly which build caused the problem, but after software updater did its thing sometime last week my models run with a tiny step-size in both DASSL and IDA whereas they have been just fine before. They are quite big models, but usually solve in 3-6 seconds. Now it takes many hours to simulate the same.

I'm on Lubuntu 16.04 and I've used nightly builds from the repo for the last two years or so, updating the packages maybe once a week. It's for this reason difficult to say exactly which version I was using just before I encountered the problem.

The package containing my models is at ​https://github.com/FishSim/LibRAS and LibRAS/Examples/Inline.mo is the one I suggest for testing. Even minimal working examples using my package run incredibly slowly due to tiny steps.

In a short test, I got 495 s spent on jacobian for 560 s simulation time, according to DASSL statistics. Can not tell if this is normal or not, but it seems a bit high compared to MSL examples.

Examples from the MSL run just fine, so I don't think it's my system.

[Martin Sjölund]

I tried to add some automatic testing of the library, but it is missing a uses-annotation. Would be good if ​https://github.com/FishSim/LibRAS/pull/5 was merged.

[stig]

Merged.

[Martin Sjölund]

​https://libraries.openmodelica.org/branches/overview.html now lists this and shows a regression (due to a timeout on the simulations). I only ran 1.11, 1.12 and the master branches with the proper flags (--std=3.3), but hopefully we can fix this before the next release. The backend seems to report a model of the same size, etc...

I am a bit unsure what would be the problem, but there are some delayed signals where the delay is in the thousands of seconds and the simulation starts very slowly in the master.

[stig]

A MWE model without the components that include the delay also solves very slowly compared to "before". It's now ~8 seconds on my system and was <1 s before things broke. Dassl timer says 99.4 % of the time is allocated to simulation, and it takes significantly shorter steps in the early parts of the sim.

[Francesco Casella]

I tried to make some analysis by reducing StopTime to 10, but unfortunately the profiler is currently broken (see #5030), so I can't see where the simulation code is spending most of the time. I suspect something's wrong with the delay operator, but it may also be due to the the coupling between the solver and the delay, or some other issue. In order to say something definite, I need to be able to check the profiling data as soon as #5030 is resolved.

If you could please add the model now taking 8 seconds to your library on GitHub with an experiment(StopTime)) annotation and/or attach it to this ticket, I'd be glad to use it as a starting point for the analysis - the models which are currently available are quite cumbersome and do not make the analysis easy.

[stig]

I uploaded the smaller model to GitHub. It's in LibRAS/Examples/ReactorTest.

Again, this test does not actually involve the delay operator, but is still slowed down significantly compared to before.

​https://github.com/FishSim/LibRAS/blob/master/LibRAS/Examples/ReactorTest.mo

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed