State event at each sample step of CombiTimeTable

[Oliver Lenord]

Simulating a simple CombiTimeTable with a time series of step size ~=0.01 leads to time events at each sample step. his slows down the simulation significantly.

The attached model contains for test cases using the CombiTimeTable with data from a file, a matrix as parameter each with a sample step of exactly 0.01 and slightly larger with 0.010000037. Test have been carried out with the step size exactly 0.01 or not. In all cases the comparison of OMEdit against Dymola shows the following:

Dymola statistics:

Number of (U) time events : 0
Number of state events : 0
Number of step events : 0

OMC Statistics:

time events 0
state events 799

For larger models the simulation time of OMEdit is multiple times slower than Dymola.

[Francesco Casella]

The event generation in the ​CombiTimeTable code:

    when {time >= pre(nextTimeEvent), initial()} then
      nextTimeEventScaled = Internal.getNextTimeEvent(tableID, timeScaled);
      nextTimeEvent = if nextTimeEventScaled < Modelica.Constants.inf then nextTimeEventScaled*timeScale else Modelica.Constants.inf;
    end when;

As far as I understand, OMC still trivially implements time events as state events, by means of zero-crossing functions. This is a very old issue that I already marked as a blocker for release 2.0.0, see #2152.

[Oliver Lenord]

Dymola is creating neither state events nor time events.

Is it really the same case as #2152?
Or is there something one could learn from Dymola to gain performance?

[Francesco Casella]

This is the simulation log of your test case with Dymola 2020x:

Integration started at T = 0 using integration method DASSL
(DAE multi-step solver (dassl/dasslrt of Petzold modified by Dassault Systemes))
Integration terminated successfully at T = 8
   CPU-time for integration                : 0.018 seconds
   CPU-time for one grid interval          : 0.036 milliseconds
   CPU-time for initialization             : 0.001 seconds
   Number of result points                 : 2100
   Number of grid points                   : 501
   Number of accepted steps                : 20
   Number of f-evaluations (dynamics)      : 20
   Number of crossing function evaluations : 1319
   Number of Jacobian-evaluations          : 18
   Number of model time events             : 799
   Number of input time events             : 0
   Number of state events                  : 0
   Number of step events                   : 0
   Minimum integration stepsize            : 1e-005
   Maximum integration stepsize            : 2.99
   Maximum integration order               : 1

As I understand it, there are indeed 799 time events. I would be surprised of the contrary, since there is a when statement triggered at each time corresponing to the values of the first column of the table.

[Francesco Casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0