Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
modelica-trac-importer opened this issue Jan 15, 2017 · 9 comments
Assignees
Labels
bug Critical/severe issue L: C-Sources Issue addresses Modelica/Resources/C-Sources

Comments

@modelica-trac-importer
Copy link

modelica-trac-importer commented Jan 15, 2017

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
Copy link
Author

Modified by dietmarw on 30 Aug 2015 08:11 UTC

@modelica-trac-importer
Copy link
Author

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
Copy link
Author

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
Copy link
Author

Modified by beutlich on 31 Aug 2015 09:33 UTC

@modelica-trac-importer
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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 modelica-trac-importer added the L: C-Sources Issue addresses Modelica/Resources/C-Sources label Jan 15, 2017
@modelica-trac-importer
Copy link
Author

Modified by beutlich on 31 Aug 2015 14:04 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Critical/severe issue L: C-Sources Issue addresses Modelica/Resources/C-Sources
Projects
None yet
Development

No branches or pull requests

6 participants