>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
