Changes between Initial Version and Version 1 of Ticket #6195, comment 9


Ignore:
Timestamp:
2021-11-08T16:43:24Z (3 years ago)
Author:
Francesco Casella

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6195, comment 9

    initial v1  
    2323What 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.
    2424
    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.
     25Then 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.
    2626
    2727It 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
     29In 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.