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

[Kai Germaschewski]

Hi Jed,

I looked at this a couple of months back -- and never really did do much to
change it, though I think there is at least a bit of discussion on this list
a few months back. I concur, for all I remember, that Pre- and PostStep were
worthless, and that TSStep should be killed (or make it do what it says,
that is, do one step). I think I actually still have the patches floating
around somewhere, but I never cleaned this up enough to dare submitting it.
A TS implementation can then either override just the step and does the
TSSolve do basically a standard loop, or it may override the entire solve if
the general implementation is not feasible. One might argue that this is
over-abstracting things, though.

Either way, TSStep should be a TS internal interface and the public function
should go away. Pre/PostStep should so what their name says, though I'm not
entirely sure what the needs may be for schemes that do multiple partial
steps.

On a general note, somehow I don't think it's right to start making those
changes 5 minutes before a release, unless there's a real good reason. Also
if you make incompatible changes, do them in a way that they break existing
code instead of causing silent corruption/nonsense. But I realize that this
isn't quite the PETSc philosophy ;)

--Kai




On Tue, Mar 2, 2010 at 2:37 PM, Jed Brown <jed at 59a2.org> wrote:

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



-- 
Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245F
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100302/c9417170/attachment.html>