Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#4254 closed defect (fixed)

Wrong numerical handling of conditional equations

Reported by: Francesco Casella Owned by: Willi Braun
Priority: blocker Milestone: 1.13.0
Component: Backend Version: v1.12.0
Keywords: Cc:

Description

Please simulate the attached test model.

The variable s, which is the result of a double integration, crosses the zero threshold at time = 0.1.

Based on the equations, the variable Pw should be zero until that moment, and then start growing afterwards. The result reported in the attached figure is instead obtained:

  • at the previous time step (time = 0.0741), Pw is zero
  • at time = 0.1 before the event, Pw is shown to be 0.05
  • at time = 0.1 after the event, Pw is again zero as it should be

The value of Pw just before the event is totally bogus. I'm not sure if this is a problem with the solver or with the result file generation.

Attachments (3)

plots.png (10.8 KB ) - added by Francesco Casella 8 years ago.
foo.mo (600 bytes ) - added by Francesco Casella 8 years ago.
Correct .mo file
ticket4254.PNG (84.1 KB ) - added by Lennart Ochel 8 years ago.

Download all attachments as: .zip

Change History (17)

by Francesco Casella, 8 years ago

Attachment: plots.png added

comment:1 by Willi Braun, 8 years ago

It seems that the model doesn't fit to the plot, since it contains only variable x.

by Francesco Casella, 8 years ago

Attachment: foo.mo added

Correct .mo file

comment:2 by Francesco Casella, 8 years ago

Sorry, of course I attached the wrong foo.mo

by Lennart Ochel, 8 years ago

Attachment: ticket4254.PNG added

comment:3 by Lennart Ochel, 8 years ago

I cannot reproduce your signals, please see ticket4254.png.

comment:4 by Lennart Ochel, 8 years ago

Okay, now I can reproduce the signals. For some reason the simulationFlags annotation got not considered.

comment:5 by Lennart Ochel, 8 years ago

Owner: changed from somebody to Lennart Ochel
Status: newaccepted

comment:6 by Francesco Casella, 8 years ago

Aha, it seems it's the noEquidistantTimeGrid flag

in reply to:  6 comment:7 by Lennart Ochel, 8 years ago

Replying to casella:

Aha, it seems it's the noEquidistantTimeGrid flag

Well, not really. If you omit that flag, then the difference is still present, but you have to zoom in to see the difference.

comment:8 by Francesco Casella, 8 years ago

Right. With equidistantTimeGrid the last step before the event is much longer, so the effect is much bigger. Maybe that is a useful clue?

comment:9 by Willi Braun, 8 years ago

As far as I see, this is connected to #3851, since it's seems that the linear algebraic system evaluate a zerocrossing literally.

comment:10 by Adrian Pop, 7 years ago

Milestone: 1.12.01.13.0

comment:11 by Francesco Casella, 6 years ago

Milestone: 1.13.01.14.0

comment:12 by Willi Braun, 6 years ago

Component: Run-timeBackend
Milestone: 1.14.01.13.0
Owner: changed from Lennart Ochel to Willi Braun
Status: acceptedassigned

comment:13 by Willi Braun, 6 years ago

Resolution: fixed
Status: assignedclosed

Fixed in PR2726.

in reply to:  13 comment:14 by Francesco Casella, 6 years ago

Replying to wbraun:

Fixed in PR2726.

Thanks Willi!

Note: See TracTickets for help on using tickets.