[petsc-dev] changes to the TS structure

[Jed Brown]

On Tue, 18 May 2010 20:41:55 -0300, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 18 May 2010 17:08, Jed Brown <jed at 59a2.org> wrote:
> > On Tue, 18 May 2010 14:51:57 -0300, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> >> 1) Could we remove "vec_sol_always" from the TS structure?
> >
> > Maybe, but are we really getting rid of vec_sol_always or just renaming
> > it to vec_sol and being careful not to update vec_sol until after the
> > step has been accepted?  The first doesn't work because you lose the
> > ability to reject a step, the latter is fine, but it means that the
> > method always needs to make private vectors to hold the solution while
> > solving the stages.
> >
> 
> You have a point, but anyway, the reference counting rules in TS is is
> general a mess. I wanted to get rid of vec_sol_always, and make TS
> incref vec_sol. Subtypes should know if the can handle accept/reject
> of steps, and allocate an additional vector for this.
> 
> >> 2) For the case of nonlinear problems, could we have a new "vec_res",
> >> then update Theta and GL to use it?
> >
> > Is there a reason that SNES can't own the residual?  Is it indeed the
> > case that it will only be updated by SNESTSFormFunction?
> >
> 
> SNES will also own the residual. This change is a prelude for other
> one I want to propose: make TSSetIFunction to also require a vector
> for the residual, this will go to ts->vec_res, and in turn will also
> be set in SNES. This would make it possible to have a vec available
> early on in TS/SNES, and with proper reference counting.

Do we really need such aliasing?  I think it would be good for
TSSetIFunction to accept a vector, but I don't think the TS should keep
a direct reference for the same reason that KSP does not keep a direct
reference to the matrices provided in KSPSetOperators.

Jed