[petsc-dev] TSSolve web page JED and EMIL READ THIS!

[Barry Smith]

> On Feb 11, 2015, at 8:32 PM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:
> 
> Hong, I could stop by your office tomorrow to chat a bit more about the "funky system" I'm talking about.
> Is tomorrow good for you?
> Dmitry.
> 
> On Wed Feb 11 2015 at 8:30:47 PM Hong Zhang <hongzhang at anl.gov> wrote:
> This is a good heads-up for me. Actually I wanted that our adjoint models could handle forward integrations like this:
> TSSolve(ts,u);
> TSStep(ts);
> TSSolve(ts,u);
> 
> Then the reverse run would look like:
> TSAdjointSolve(ts);
> TSAdjointStep(ts);
> TSAdjointSolve(ts);
> 
> This flexibility should be very useful for “funky systems”.

  This is not going to work because the user is doing other stuff (like moving the particles) outside of the Solve and Step code and hence the adjoints simply won't work because they don't capture the complete integration process. Supporting the above is ok (though it makes the code a bit more complicated to pull the adjoint handling in the step instead of the solve) but really doesn't add any functionality you don't have over just keeping the adjoint stuff in the Solve version. 

  Barry

> 
> On Feb 8, 2015, at 8:41 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> >
> >  If the number of degrees of freedom do not change and they have essentially the same "meaning" regardless of which process they are on then we can "hide" inside the Vec object (and Mat object) the fact that they move around between processors so TS shouldn't care.
> >
> >  BUT note that if the user manages the calling of TSStep() themselves then the user has to similarly manage calling the TSAdjointStep() stuff correctly themselves backwards. And if they are ad hoc combining TSStep() for the field with some "push particle" crap for the particles then likely all the TSAdjoint stuff goes out the window. Hence my desire for TS to treat the entire field+particle stuff as one "big old" set of ODEs so users get all the good stuff (like Adjoints and proper coupled error control) for free.
> >
> >
> >
> >
> >> On Feb 8, 2015, at 8:29 PM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:
> >>
> >> This is a bit off-topic, but I'm dealing exactly with this sort of "funky system" -- particles+field.
> >> Since degrees of freedom do move between processors, it's unclear how it fits into the current
> >> TS framework short of rebuilding the TS every timestep. That's a bit inconvenient, since now I
> >> have to do my own error and timestep size control etc.  It might be too late to do anything about
> >> TS to help this, but I'm also hoping to use TSAdjoint with this system, so it may be good -- before
> >> TSAdjoint becomes to rigidly entrenched -- to think about how to accommodate these systems.
> >>
> >> On Sun Feb 08 2015 at 8:16:30 PM Barry Smith <bsmith at mcs.anl.gov> wrote:
> >>
> >>> On Feb 8, 2015, at 8:11 PM, Jed Brown <jed at jedbrown.org> wrote:
> >>>
> >>> Barry Smith <bsmith at mcs.anl.gov> writes:
> >>>>  Why can't TS handle that? Users always prefer to use the lowest
> >>>>  level thing available, that doesn't mean it is right.
> >>>>
> >>>>  In the language of TS what does a "funky system, liked mixed
> >>>>  particle-field," mean, does it require a little more API on our
> >>>>  side? I'm much rather have Emil and Jed control the time-stepping
> >>>>  then some ignorant user.
> >>>
> >>> Dofs move to different processes at each stage.  That isn't compatible
> >>> with Vec.  Do we need to overhaul Vec before users can integrate such a
> >>> system?
> >>
> >>   Well eventually.
> >>>
> >>> Practicality wins over purity.
> >>
> >>  I never said remove TSStep() or make it completely private. I just want to limit its use to when it is really needed by the user.
> >>
> >>
> >
>