Hi Jed,<br><br>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.<br>
<br>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.<br>
<br>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 ;)<br>
<br>--Kai<br><br><br><br><br><div class="gmail_quote">On Tue, Mar 2, 2010 at 2:37 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We have some nonsense going on with TSSolve and TSStep (which do the<br>
same thing, so one needs to be killed).  Both of these only call<br>
TSStep_XXX once, and the stepping loop is handled internally.  So<br>
TSSetPreStep and TSSetPostStep are pretty worthless, you're just setting<br>
a callback to be run immediately after *you* call TSStep, so you might<br>
as well call these yourself.  Does anyone actually use these?<br>
<br>
I think these should be run before and after *each* step, not each call<br>
to TSStep.  The reason I brinng this up is that a viable use case is to<br>
run semi-implicit integration where F_fast is integrated implicitly and<br>
F_slow is done explicitly.  One way to do this is to set a PostStep that<br>
integrates the explicit system up to the end of the step.  Another is to<br>
bury explicit integration in function evaluation for the explicit<br>
system, but you need to know when to complete the step.  Dana says he<br>
has actually done this to get second order accuracy for a stiff system<br>
while still doing transport explicitly, though it sounds like that may<br>
have been as much for political reasons as because the fully coupled<br>
implicit system, would actually perform worse if someone was to write<br>
the implicit code for it and split preconditioning appropriately.<br>
<br>
I'd like to make Pre and PostStep meaningful before the release (this<br>
should be trivial once we agree on where they should sit).  I'd also<br>
like to hear comments about how TS should behave, at some later point, I<br>
want to clean it up a bit, and probably get rid of all the<br>
implementation specializations for linear systems (which can be<br>
abstracted as a special case of a nonlinear system so that the user<br>
interface doesn't change).<br>
<br>
I'd also like to add a TSInterpolate to evaluate the state at arbitrary<br>
points inside a step (to support the partly explicit treatment above,<br>
and because it will be necessary if we want to integrate continuous<br>
adjoints [1] and delay differential equations --- we don't support any<br>
of this stuff yet, but I want to think about what the interfaces would<br>
look like.)<br>
<br>
Jed<br>
<br>
[1] As far as I know, existing software to integrate continuous adjoints<br>
(e.g. CVODES and IDAS from Sundials) use an interpolation scheme that is<br>
not compatible with the forward integrator.  The fact that naive<br>
interpolation of states can produce something very different (think of<br>
concentrations in a reactive flow, in which case the average of two<br>
subcritical mixtures could be explosive) is one reason why discrete<br>
adjoints are attractive.  Availability of compatible high-order<br>
interpolation would make continuous adjoints attractive as well (unless<br>
I'm missing something).<br>
</blockquote></div><br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245F<br>phone:  +1-603-862-2912<br>
fax: +1-603-862-2771<br><br>