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>
