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: casella Owned by: wbraun
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 casella 8 years ago.
foo.mo (600 bytes) - added by casella 8 years ago.
Correct .mo file
ticket4254.PNG (84.1 KB) - added by lochel 8 years ago.

Download all attachments as: .zip

Change History (17)

Changed 8 years ago by casella

comment:1 Changed 8 years ago by wbraun

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

Changed 8 years ago by casella

Correct .mo file

comment:2 Changed 8 years ago by casella

Sorry, of course I attached the wrong foo.mo

Changed 8 years ago by lochel

comment:3 Changed 8 years ago by lochel

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

comment:4 Changed 8 years ago by lochel

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

comment:5 Changed 8 years ago by lochel

  • Owner changed from somebody to lochel
  • Status changed from new to accepted

comment:6 follow-up: Changed 8 years ago by casella

Aha, it seems it's the noEquidistantTimeGrid flag

comment:7 in reply to: ↑ 6 Changed 8 years ago by lochel

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 Changed 8 years ago by casella

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 Changed 8 years ago by wbraun

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 Changed 7 years ago by adrpo

  • Milestone changed from 1.12.0 to 1.13.0

comment:11 Changed 6 years ago by casella

  • Milestone changed from 1.13.0 to 1.14.0

comment:12 Changed 6 years ago by wbraun

  • Component changed from Run-time to Backend
  • Milestone changed from 1.14.0 to 1.13.0
  • Owner changed from lochel to wbraun
  • Status changed from accepted to assigned

comment:13 follow-up: Changed 6 years ago by wbraun

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in PR2726.

comment:14 in reply to: ↑ 13 Changed 6 years ago by casella

Replying to wbraun:

Fixed in PR2726.

Thanks Willi!

Note: See TracTickets for help on using tickets.