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
