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.

[beutlich]

@PMehrfeld @christiankral @hubertus65 @wischhusen @MartinOtter @HansOlsson

For now, I fixed it in a pretty pragmatic and straight-forward way by always generating time events in case of linear interpolation (analogously to constant segments), i.e., option 3 of http://doodle.com/poll/9s7zhtnmguev5c8m. Here are my reasons.

• Too many users stumbled upon this problem within the last year. The users either expect the CombiTimeTable to behave like the TimeTable or like it did in the closed-source Dymola Tables implementation of MSL v3.2. Users were not that familiar with the provided work-around of sample-point replication to force generation of time-events. Often users could not be convinced to apply the workaround.
• General guideline: In case of doubt, prefer accuracy over performance. There still is CombiTable + Clock for the interpolation w/o time events (promising a better performance).
• A usual table matrix with equidistant sample points can be used for all different smoothness options and assuring the expected accuracy.
• Furthermore, the block SignalBlocks.Sources.Curve from the proprietary SimulationX library also has an optional consideration of time events for linear interpolation (where generation of the time events is the default behaviour).
• I have several open issues on the C-Sources/Tables (even asked for paid work) and want to close all issues that do not require any API change of the external functions before I move on.

I'll keep #1627 open (as enhancement) to add the behaviour to only generate time events at discontinuities and interpolation w/o time events one day. I won't introduce a new choice for the Smoothness enumeration for these alternatives as the Smoothness enumeration also is used for CombiTable1D and CombiTable2D where the alternatives are not applicable. Instead a new parameter will be introduced which requires an API update of ModelicaStandardTable external functions.

I did not run the regression on and I hope that @GallLeo can provide them for ModelicaTest.Tables.CombiTimeTable if required.