[petsc-dev] BDF implementation

[Abhyankar, Shrirang G.]

>On 31 March 2016 at 01:07, Abhyankar, Shrirang G. <abhyshr at anl.gov> 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