Changes between Initial Version and Version 1 of Ticket #6195, comment 9
- Timestamp:
- 2021-11-08T16:43:24Z (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #6195, comment 9
initial v1 23 23 What happens here is pretty clear: the next step at t = 16/22 = 0.727273 is attempted, and of course the assertions is violated because, due to the large time step, the step is wey beyond the event time, i.e. t = 0.7. 24 24 25 Then the solver halves the interval, so it tries (15+1/2)/22 = 0.704545, which is still to far from t = 0.7 to stay within y <= 1.0000000001, and then quits.25 Then the solver halves the interval, so it tries (15+1/2)/22 = 0.704545, which is still to far from t = 0.7 to stay within y <= 1.0000000001, and then it just quits. 26 26 27 27 It seems that we are trying to identify the event time by bisection, which is not particularly efficient but is just fine. However, we should let the solver iterate as many times as it needs to find out the event time without failing. I don't really know why only one iteration is allowed here before giving up. 28 29 In fact, it is fine to check for assertions during these iterations, in order to discard invalid points, but I wouldn't even report them on stdout, as they can generate anxiety on the end-user (like the model is numerically problematic or something), when this is absolutely not the case.