CombiTimeTable does not generate time events

[modelica-trac-importer]

Reported by hansolsson on 10 Dec 2014 15:56 UTC
As noted in https://trac.modelica.org/Modelica/ticket/1619#comment:8 the trunk version of time tables no longer generates time events in Dymola (and possibly other tools), due to the scaling of time. That decreases performance and accurancy.

The 3.3. Modelica Language Specification in 8.5 states that time>=... and time < ... may generate events. The previous version used time>=... which can generate time events, but the new version contains timeScaled>=...

I have not investigated exactly how to rewrite it.
It is less important than #1619, but should still be resolved before the library is released.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1627

[modelica-trac-importer]

Comment by beutlich on 10 Dec 2014 21:42 UTC
In 70f01e3 for #1473 I did not want to affect the C sources but only the Modelica sources, by purpose. I guess this needs to be edited (or reverted) according to your comment at comment 8 of #1619.

[modelica-trac-importer]

Comment by beutlich on 5 Jan 2015 08:07 UTC
Actually I cannot reproduce the problem in Dymola 2015 32-bit with current MSL trunk (829eaf3) and ModelicaStandardTables compiled with DEBUG_TIME_EVENTS set. If I run ModelicaTest.Tables.CombiTimeTable.Test67 I can see the expected event messages for each of the CombiTimeTable instances.

Log-file of program ./dymosim
(generated: Mon Jan 05 08:51:28 2015)

dymosim started
... "dsin.txt" loading (dymosim input file)
At time 0.000000: 1. time event at 400.000000
At time 0.000000: 1. time event at 6.666667
At time 0.000000: 1. time event at 0.111111
At time 0.000000: 1. time event at 0.004630
At time 0.000000: 1. time event at 400000.000000
... "Test67.mat" creating (simulation result file)

Integration started at T = 0 using integration method DASSL
(DAE multi-step solver (dassl/dasslrt of Petzold modified by Dynasim))
At time 400.000000: 2. time event at 2200.000000
At time 6.666667: 2. time event at 36.666667
At time 0.111111: 2. time event at 0.611111
At time 0.004630: 2. time event at 0.025463
At time 400000.000000: 2. time event at 2200000.000000
At time 2200.000000: 3. time event at 4000.000000
At time 36.666667: 3. time event at 66.666667
At time 0.611111: 3. time event at 1.111111
At time 0.025463: 3. time event at 0.046296
At time 2200000.000040: 3. time event at 4000000.000000
Integration terminated successfully at T = 4000
   CPU-time for integration      : 0.016 seconds
   CPU-time for one GRID interval: 0.032 milli-seconds
   Number of result points       : 505
   Number of GRID   points       : 501
   Number of (successful) steps  : 52
   Number of F-evaluations       : 100
   Number of H-evaluations       : 569
   Number of Jacobian-evaluations: 48
   Number of (model) time events : 0
   Number of (U) time events     : 0
   Number of state    events     : 2
   Number of step     events     : 0
   Minimum integration stepsize  : 0.008
   Maximum integration stepsize  : 1.05e+003
   Maximum integration order     : 1
Calling terminal section
No more time events for time > 4000.000000
No more time events for time > 66.666667
No more time events for time > 1.111111
No more time events for time > 0.046296
No more time events for time > 4000000.000000
... "dsfinal.txt" creating (final states)

These messages are generated by getNextTimeEvent = ModelicaStandardTables_CombiTimeTable_nextTimeEvent.

  when {timeScaled >= pre(nextTimeEventScaled),initial()} then
    nextTimeEventScaled = getNextTimeEvent(tableID, timeScaled, tableOnFileRead);
    // ...
  end when;

[modelica-trac-importer]

Comment by beutlich on 18 Mar 2015 16:43 UTC
Hans, is this issue still relevant for you? You did not answer on my comment:2.

[modelica-trac-importer]

Comment by hansolsson on 10 Apr 2015 15:07 UTC
Replying to [comment:3 beutlich]:

Hans, is this issue still relevant for you? You did not answer on my comment:2.

At least on trunk the issue is still present, and this is still relevant for us.
(I have been busy I didn't have time to investigate the new version MSL earlier.)

You can also see it from the log, it has 2 state events and 0 model time events; it should be the other way.

The naïve solution would be:

  when {time >= pre(nextTimeEvent),initial()} then

However, floating point numbers don't always work as expected (unless timeScale is power of 2 - such as 1).

Here we will take 'nextTimeEventScaled' and ideally generate an event at:
'(nextTimeEventScaled*timescale)/timeScale'.
This can differ from 'nextTimeEventScaled' - in particular it could be smaller than 'nextTimeEventScaled', i.e. generate a time-event too early.