[petsc-dev] TSSet{Pre,Post}Step

[Jed Brown]

We have some nonsense going on with TSSolve and TSStep (which do the
same thing, so one needs to be killed).  Both of these only call
TSStep_XXX once, and the stepping loop is handled internally.  So
TSSetPreStep and TSSetPostStep are pretty worthless, you're just setting
a callback to be run immediately after *you* call TSStep, so you might
as well call these yourself.  Does anyone actually use these?

I think these should be run before and after *each* step, not each call
to TSStep.  The reason I brinng this up is that a viable use case is to
run semi-implicit integration where F_fast is integrated implicitly and
F_slow is done explicitly.  One way to do this is to set a PostStep that
integrates the explicit system up to the end of the step.  Another is to
bury explicit integration in function evaluation for the explicit
system, but you need to know when to complete the step.  Dana says he
has actually done this to get second order accuracy for a stiff system
while still doing transport explicitly, though it sounds like that may
have been as much for political reasons as because the fully coupled
implicit system, would actually perform worse if someone was to write
the implicit code for it and split preconditioning appropriately.

I'd like to make Pre and PostStep meaningful before the release (this
should be trivial once we agree on where they should sit).  I'd also
like to hear comments about how TS should behave, at some later point, I
want to clean it up a bit, and probably get rid of all the
implementation specializations for linear systems (which can be
abstracted as a special case of a nonlinear system so that the user
interface doesn't change).

I'd also like to add a TSInterpolate to evaluate the state at arbitrary
points inside a step (to support the partly explicit treatment above,
and because it will be necessary if we want to integrate continuous
adjoints [1] and delay differential equations --- we don't support any
of this stuff yet, but I want to think about what the interfaces would
look like.)

Jed

[1] As far as I know, existing software to integrate continuous adjoints
(e.g. CVODES and IDAS from Sundials) use an interpolation scheme that is
not compatible with the forward integrator.  The fact that naive
interpolation of states can produce something very different (think of
concentrations in a reactive flow, in which case the average of two
subcritical mixtures could be explosive) is one reason why discrete
adjoints are attractive.  Availability of compatible high-order
interpolation would make continuous adjoints attractive as well (unless
I'm missing something).