Opened 10 years ago
Last modified 7 years ago
#2946 new defect
events are treated badly
Reported by: | Lennart Ochel | Owned by: | somebody |
---|---|---|---|
Priority: | critical | Milestone: | Future |
Component: | Run-time | Version: | trunk |
Keywords: | Cc: |
Description
I attached four models to show why OpenModelica treats events badly:
model test1 parameter Real p = 1.5; Real t = if time < p then time else p; Boolean d = t > p and t >= p; Boolean e; algorithm e := true; if t > p then e := false; end if; annotation(experiment(StartTime = 0, StopTime = 3)); end test1;
test2
is equal to test1
but without variable d.
test3
is equal to test1
but with if t > p then
as condition in the algorithm section.
test4
is equal to test3
but without variable d.
I attached also the simulation results of OpenModelica and Dymola for variable e of all four examples. I think Dymola handles the examples correctly. OpenModelica handles at least the first three examples different.
Attachments (3)
Change History (14)
by , 10 years ago
Attachment: | EventExamples.mo added |
---|
by , 10 years ago
Attachment: | EventExamples_OM.png added |
---|
by , 10 years ago
Attachment: | EventExamples_Dymola.png added |
---|
comment:1 by , 10 years ago
comment:2 by , 10 years ago
The fix also uncovers more issues, so that I cannot commit it as it is right now.
follow-up: 4 comment:3 by , 10 years ago
My understanding is that this kind of model ultimately relies on the fact that the zeros of the zero-crossing functions are computed exactly, but in general you cannot rely on that, as it is impossible to represent exact solutions of Real equations on a finite-precision floating point representation.
comment:4 by , 10 years ago
Replying to casella:
My understanding is that this kind of model ultimately relies on the fact that the zeros of the zero-crossing functions are computed exactly, but in general you cannot rely on that, as it is impossible to represent exact solutions of Real equations on a finite-precision floating point representation.
I agree. The model can be improved by applying noEvent to the if-condition that belongs to variable t:
model test1 parameter Real p = 1.5; Real t = if noEvent(time < p) then time else p; Boolean d = t > p and t >= p; Boolean e; algorithm e := true; if t > p then e := false; end if; annotation(experiment(StartTime = 0, StopTime = 3)); end test1;
Therewith, t cannot get greater than p anyway. test1
and test2
are now working as expected.
comment:5 by , 10 years ago
Milestone: | 1.9.2 → 1.9.3 |
---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:10 by , 8 years ago
Milestone: | 1.11.0 → 1.12.0 |
---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:11 by , 7 years ago
Milestone: | 1.12.0 → Future |
---|
The milestone of this ticket has been reassigned to "Future".
If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.
If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".
In both cases, a short informative comment would be welcome.
I did some changes to the evaluation of zero crossings, which fix all the models mentioned above.