changes to SNES

[Barry Smith]

On Fri, 31 Aug 2007, Lisandro Dalcin wrote:

> Barry, Matt
> 
> Do you know/remember why SNES has both

  The implementations swap vector pointers to avoid having to 
copy vectors inside the loop of the solvers. The non-always one
ALWAYS points to the input vectors that user provided in the SNES calls,
the always ones point to the vector that currently holds the 
solution or function value (this is sometimes the non-always one
and sometimes a work vector that was obtained internally by 
VecDuplicate() from the input one.).

   It "may" be possible to eliminate this construct and keep the 
no-copy rule, but I never saw it as mattering that much. If you 
can truly eliminate it but keep clean code and no copies inside
the solver loop that would be a fine change. Just don't mess it up :-)

   Barry

> 
> 1- "vec_sol", and  "vec_sol_always"
> 
> 2 - "vec_func", and "vec_func_always"
> 
> Is this extrictly needed? Do you remember some corner case needing this?
> 
> 
> 
> On 8/31/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >   Lisandro,
> >
> >      The changes sound fine for petsc-dev, improving the
> > reference counting. But this is too large a change for a patch.
> > Patches are supposed to be minimulistic changes that fix particular
> > problems that are impacting end users.
> >
> >    Barry
> >
> > On Fri, 31 Aug 2007, Lisandro Dalcin wrote:
> >
> > > There are some things broken in SNES, and others that could be
> > > improved. In particular, I am going to make sure SNES take ownership
> > > and correctly manage reference counting of all the user provided
> > > vectors, that is:
> > >
> > > - function vector (passed in SNESSetFunction)
> > > - solution vector (passed in SNESSolve/SNESSetSolution)
> > > - afine vector (passed in SNESSolve/SNESSetRhs)
> > >
> > > All this is similar to what I did in the past for KSP
> > >
> > > I almost sure all those changes are completelly backward compatible.
> > > For example, the user was in charge of calling VecDestroy() with the
> > > provided function vector, but after calling SNESSolve. Now, users are
> > > able to call it after SNESSetFunction is called, so they do not need
> > > to mantain a reference to the function vector. The same applies to
> > > solution and afine vectors.
> > >
> > > So I want to ask you: can I push this in release-2.3.3?
> > >
> > >
> > >
> > >
> >
> >
> 
> 
>