Problem with CombiTimeTable

[modelica-trac-importer]

Reported by christiankral on 14 Oct 2016 15:38 UTC
Consider the attached example. A drive cycle (speed versus time) is read from an external file drivecycle.txt. The signal output of the used CombiTimeTable block is connected with a translational speed source. The simulation is performed for two entire drive cycles (= 2 * 600s = 1200s).

In the vicinity of 800s the acceleration speed.a is calculated incorrectly even though speed.v is computed correctly; see attached PNG.

The same issue occurred using Dymola 2017 and OpenModelica 1.11.0~dev-192-g1d441b1. I therefore conclude that is an issue of the CombiTimeTable and/or tables in general. Someone more familiar with the implementation of tables my assess whether is issue is related with #1627 or not.

---

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

[modelica-trac-importer]

Comment by christiankral on 14 Oct 2016 15:46 UTC
I actually just noticed, that speed is not determined correctly either. Since periodic continuation of the signal is parameterized, the period of the signal is 600s. However, a speed peak is missing in the vicinity of 800s, right there where the acceleration is determined incorrectly.

[modelica-trac-importer]

Comment by beutlich on 14 Oct 2016 17:30 UTC
Will check it the next days.

[modelica-trac-importer]

Comment by hubertus on 14 Oct 2016 21:42 UTC
I think this is related to #1627. Everything looks correct when I add a clock source and a 1 sec. sampler to get events in sync with the changes in the file.

[modelica-trac-importer]

Comment by beutlich on 16 Oct 2016 19:40 UTC
Indeed, this is a duplicate of the reopened #1627. Please read the discussion beginning from comment 15 of #1627. If you use the attachment:drivecycle_events.txt with replicated sample points you get the expected results. You can also set the macro DEBUG_TIME_EVENTS to gain debug output on the time event detection.

I see (and already saw) that this case is urgent. There was a poll six months ago (http://doodle.com/poll/9s7zhtnmguev5c8m) where only a few people from MAP-Lib took part. Unfortunately, only Hubertus and I prefered option 3 or 4, but majority voted for alternative 2. For me, the design decision from 2013 seems wrong: It is not about simulation efficiency but simulation accuracy. Thus I am in dilemma right now, that the current workaround requires modified table data, the voted solution requires a modified model, but my preferred alternative is a fix of the ModelicaStandardTables.

[modelica-trac-importer]

Modified by beutlich on 17 Oct 2016 06:54 UTC

[modelica-trac-importer]

Comment by otter on 17 Oct 2016 08:20 UTC
Replying to [comment:4 beutlich]:

Indeed, this is a duplicate of the reopened #1627. Please read the discussion beginning from comment 15 of #1627. If you use the attachment:drivecycle_events.txt with replicated sample points you get the expected results. You can also set the macro DEBUG_TIME_EVENTS to gain debug output on the time event detection.

This is a slightly different problem (and not a duplicate): When using periodic continuation, then in general the table output is discontinuous at the periodic continuation point. This means a time event should be generated at these points. Please, make a bug fix, so that time events are generated at periodic continuation points (note, this is completely independent from the solution used for #1627, and also independently from the utilized interpolation method).

I see (and already saw) that this case is urgent. There was a poll six months ago (http://doodle.com/poll/9s7zhtnmguev5c8m) where only a few people from MAP-Lib took part. Unfortunately, only Hubertus and I prefered option 3 or 4, but majority voted for alternative 2. For me, the design decision from 2013 seems wrong: It is not about simulation efficiency but simulation accuracy. Thus I am in dilemma right now, that the current workaround requires modified table data, the voted solution requires a modified model, but my preferred alternative is a fix of the ModelicaStandardTables.

This is a general problem, independent of the tables: Algebraic variables of Modelica models are usually not included in the step-size control of the integrator of the Modelica tools. This means that any algebraic variable that is quickly changing (it may also be a smooth, analytic curve; including a smoothly interpolated table) may result in a wrong simulation result because the integrator makes a too large step-size. The only clean way to fix this is to extend the Modelica tools so that all time varying variables in a model are utilized in the step-size control. To do this is most likely a large effort for tool vendors and could reduce the efficiency of simulations.
Changing the MSL to fix deficiences of Modelica tools in rare application cases looks not like a good solution to me.

I would suggest to implement option 2 (adding an option to the tables to define whether linearly interpolated points induce time events and keep the current default option to not generate time events).

Independently of that, always generate time events at periodic continuation points.

[modelica-trac-importer]

Comment by beutlich on 17 Oct 2016 09:00 UTC
Replying to [comment:6 otter]:

This is a slightly different problem (and not a duplicate): When using periodic continuation, then in general the table output is discontinuous at the periodic continuation point. This means a time event should be generated at these points. Please, make a bug fix, so that time events are generated at periodic continuation points (note, this is completely independent from the solution used for #1627, and also independently from the utilized interpolation method).

There already always is a time event at the interval boundary. It is written in the article (subsection 2.1), commented in the code and can be seen with DEBUG_TIME_EVENTS.

It is a duplicate of reopened #1627. Please run the model attachment:TestCombiTimeTable.mo with attachment:drivecycle.txt​ and with attachment:drivecycle_events.txt​ to see the difference. Still, my (and Hubertus') preferred solution is to fix it in the ModelicaStandardTables (alternative 4 from the poll).

[modelica-trac-importer]

Comment by beutlich on 22 Oct 2016 12:20 UTC
otter I really would like to fix it by alternative 4, that is change the existing behavior of ModelicsStandardTables w/o the user's need to touch data or model. Form the poll it was Hubertus and me who where in favour of it and Hans who was not sure which one to choose. I hope that is will be finally alright for you. Thanks for your feedback.