On 31 March 2016 at 01:07, Abhyankar, Shrirang G. <[email protected]> wrote:

...

...

Oh! Very good point. Then, the only way to know is the postevent callback flagging the timestepper about it.

The restart will only work when TSEvent is used. What about without TSEvent?

Well, I was thinking only about the issues related to TSEvent. What other use cases you have in mind?

I assume there are a lot of users who would not be using TSEvent as it is a recent development. They would be using either a poststep callback to force the discontinuity or repeatedly calling TSSolve multiple times. Also, there was a thread, probably last year, on outputting the states at specific time points. One could set up events on those specific time-points, but the method does need to restart.

...

...

Well, A VecGetArray()/RestoreArray() on the solution would still work, even if the postevent callback does not actually modify the state. However, this is sounds like a bad API for users to flag the restart.

How about an additional check on RHS function vector state, similar to what¹s been done with the solution vector state?

I think that makes no sense. Let me put an example. Suppose you have this ODE:

dU/dt = -U + (t<1) ? 0 : 1

Then you code it all in IFunction (i.e, do not use RHSFunction at all) and use an implicit solver. Then we use TSEvent to force the solver pass through t=1, we do not change state, but the continuity of the solution changes anyway because of the time-dependent term. If we are integrating with let say BDF(p) p>=2, the solver has to be restarted. In this use case, I think the only way for the solver to know a restart is needed, is the postevent function flagging the solver about it.

I was thinking the user could change the RHSfunction in the post event callback, but that looks cumbersome and would involve an extra IFunction call at each time-step. So, having a flag in the postevent callback seems to be the most convenient. Shri

In other use cases of events, you are only interesting in accurate detection of them for the solver to not "step-over" the event time, but then you do not change state, rhs, nothing, and you can continue timestepping without need of restart, BDF(p) p>=2 can happily continue keeping its previous history.

-- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa

Office Phone: +966 12 808-0459