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)

EventExamples.mo (1.1 KB ) - added by Lennart Ochel 10 years ago.
EventExamples_OM.png (48.7 KB ) - added by Lennart Ochel 10 years ago.
EventExamples_Dymola.png (19.9 KB ) - added by Lennart Ochel 10 years ago.

Download all attachments as: .zip

Change History (14)

by Lennart Ochel, 10 years ago

Attachment: EventExamples.mo added

by Lennart Ochel, 10 years ago

Attachment: EventExamples_OM.png added

by Lennart Ochel, 10 years ago

Attachment: EventExamples_Dymola.png added

comment:1 by Lennart Ochel, 10 years ago

I did some changes to the evaluation of zero crossings, which fix all the models mentioned above.

comment:2 by Lennart Ochel, 10 years ago

The fix also uncovers more issues, so that I cannot commit it as it is right now.

comment:3 by Francesco Casella, 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.

in reply to:  3 comment:4 by Lennart Ochel, 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 Martin Sjölund, 10 years ago

Milestone: 1.9.21.9.3

Milestone changed to 1.9.3 since 1.9.2 was released.

comment:6 by Martin Sjölund, 9 years ago

Milestone: 1.9.31.9.4

Moved to new milestone 1.9.4

comment:7 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.5

Milestone pushed to 1.9.5

comment:8 by Martin Sjölund, 9 years ago

Milestone: 1.9.51.10.0

Milestone renamed

comment:9 by Martin Sjölund, 8 years ago

Milestone: 1.10.01.11.0

Ticket retargeted after milestone closed

comment:10 by Martin Sjölund, 8 years ago

Milestone: 1.11.01.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:11 by Francesco Casella, 7 years ago

Milestone: 1.12.0Future

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.

Note: See TracTickets for help on using tickets.