-----Original Message----- From: Lisandro Dalcin <[email protected]> Date: Wednesday, March 30, 2016 at 4:00 PM To: "Zhang, Hong" <[email protected]> Cc: Jed Brown <[email protected]>, petsc-dev mailing list <[email protected]>, Shri <[email protected]> Subject: Re: [petsc-dev] BDF implementation

On 30 March 2016 at 18:50, Hong Zhang <[email protected]> wrote:

...

If there are state changes in the post event callback, then multistep methods would not be a good choice for the application. I would use multistage methods such as RK type instead.

It all depends on the frequency of events respect to the timestep.

...

However, restarting the time stepper may still be necessary for other types of discontinuities, e.g. changes in the RHS function.

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, 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?

...

So I would suggest to do unconditional restart at discontinuity points for safety.

So ARKIMEX has to be fixed. Unless we agree and document that VecGetArray()/RestoreArray() is the way to flag discontinuities in the RHS function.

-- 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