Wrong combiTimeTable output when using fixed time step integrator with time step greater than table resolution

[modelica-trac-importer]

Modified by dietmarw on 30 Aug 2015 08:11 UTC
Hi,

I'm using Euler integration in Dymola 2016 to simulate a model that uses combiTimeTables. The fixed time step is one minute, however the .mat file input data (sometimes) changes on a very fast time scale: within 10 seconds. This means that two events should occur within one integration step, since the integrator has a fixed time step.

The current combiTimeTable implementation does not seem to handle this properly. I looked into the C code and I think I found part of the problem, but the code documentation makes it difficult to interpret what is going on:
The problem seems to be that somehow after the 'two events within one time step' the 'nextTimeEvent' variable is no longer updated. Moreover 'nextTimeEvent' becomes equal to pre(nextTimeEvent) at the time of the double event. I think this causes 'CombiTimeTable_getValue()' to bug out since it reaches the following piece of code:

if (nextTimeEvent == preNextTimeEvent &&
                        tOld >= nextTimeEvent) {
                        /* Before event iteration: Return previous
                           interval value */
                        size_t i;
                        if (tableID->smoothness == CONSTANT_SEGMENTS) {
                            i = tableID->intervals[
                                tableID->eventInterval - 1][0];
                        }
                        else {
                            i = tableID->intervals[
                                tableID->eventInterval - 1][1];
                        }
                        y = TABLE(i, col);
                        return y;
                    }

The comment seems to suggest that the function will return the 'previous' value (pre(combiTimeTable.y)) and this is indeed what I see: after the double event all combiTable outputs are delayed by one event.

The attached file shows what is wrong. The first graph shows the correct combiTimeTable output (top) and the bugged output (bottom). The second graph shows nextTimeEvent and pre(nextTimeEvent):

[[Image(Screen Shot 2015-08-29 at 15.19.33.png​)]]

I hope using this information this can be fixed? Otherwise I can try to attach a clear example.

NOTE: I am using the code version from https://trac.modelica.org/Modelica/ticket/1682#comment:16 and I did not test if version 3.2.1 of MSL has the same bug.

Thanks!

---

Reported by filip.jorissen on 29 Aug 2015 13:21 UTC
Hi,

I'm using Euler integration in Dymola 2016 to simulate a model that uses combiTimeTables. The fixed time step is one minute, however the .mat file input data (sometimes) changes on a very fast time scale: within 10 seconds. This means that two events should occur within one integration step, since the integrator has a fixed time step.

The current combiTimeTable implementation does not seem to handle this properly. I looked into the C code and I think I found part of the problem, but the code documentation makes it difficult to interpret what is going on:
The problem seems to be that somehow after the 'two events within one time step' the 'nextTimeEvent' variable is no longer updated. Moreover 'nextTimeEvent' becomes equal to pre(nextTimeEvent) at the time of the double event. I think this causes 'CombiTimeTable_getValue()' to bug out since it reaches the following piece of code:

if (nextTimeEvent == preNextTimeEvent &&
tOld >= nextTimeEvent) {
/* Before event iteration: Return previous
interval value */
size_t i;
if (tableID->smoothness == CONSTANT_SEGMENTS) {
i = tableID->intervals[
tableID->eventInterval - 1][0];
}
else {
i = tableID->intervals[
tableID->eventInterval - 1][1];
}
y = TABLE(i, col);
return y;
}

The comment seems to suggest that the function will return the 'previous' value (pre(combiTimeTable.y)) and this is indeed what I see: after the double event all combiTable outputs are delayed by one event.

The attached file shows what is wrong. The first graph shows the correct combiTimeTable output (top) and the bugged output (bottom). The second graph shows nextTimeEvent and pre(nextTimeEvent).

I hope using this information this can be fixed? Otherwise I can try to attach a clear example.

NOTE: I am using the code version from https://trac.modelica.org/Modelica/ticket/1682#comment:16 and I did not test if version 3.2.1 of MSL has the same bug.

Thanks!

---

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

[modelica-trac-importer]

Modified by dietmarw on 30 Aug 2015 08:11 UTC

[modelica-trac-importer]

Comment by anonymous on 31 Aug 2015 07:00 UTC
Replying to [ticket:1768 filip.jorissen@…]:

I hope using this information this can be fixed? Otherwise I can try to attach a clear example.

Indeed, a clear example really would be helpful. Thanks.

[modelica-trac-importer]

Comment by filip.jorissen on 31 Aug 2015 08:05 UTC
I attached an example. It produces correct results with Euler and dT=10s, but wrong results for dT = 30s

[modelica-trac-importer]

Modified by beutlich on 31 Aug 2015 09:33 UTC

[modelica-trac-importer]

Comment by beutlich on 31 Aug 2015 12:37 UTC
Can you please confirm that tbeu/ModelicaStandardTables@8fa16bd fixes this problem. You can get precompiled Linux binaries from https://drone.io/github.com/tbeu/ModelicaStandardTables/files.

[modelica-trac-importer]

Comment by filip.jorissen on 31 Aug 2015 12:50 UTC
Yes it fixes the problem.

Thank you for the swift resolution!

Filip

[modelica-trac-importer]

Comment by beutlich on 31 Aug 2015 14:04 UTC
Resolved by 66d075c in trunk and merged by 9a194eb to maint. branch.

[modelica-trac-importer]

Changelog modified by beutlich on 31 Aug 2015 14:04 UTC
Modelica Standard Tables: Fixed the event detection of CombiTimeTable when using a fixed time step integrator with a step size greater than the event resolution of the table

[modelica-trac-importer]

Modified by beutlich on 31 Aug 2015 14:04 UTC