changes to SNES

[Lisandro Dalcin]

On 9/4/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> On Fri, 31 Aug 2007, Lisandro Dalcin wrote:
> > 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.

Yes, I finally ended realizing that, thanks.

>    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 :-)

Well, I reimplemented this using vec copies. Do you really think it
can actually impact performance in actual, nontrivial applications? I
would prefer to maintain this approach, this way the 'vec_sol' in SNES
is ALWAYS the vec passed to SNESSolve(), the same for function vector.

BTW, I'm also getting rid of the SNESConverged_{LS|TR}. The inner
trust region tolerance convergence test is done inside the inner trust
region loop in SNESSolve_TR. The only two convergence tests provided
by PETSc will be SNES{Default|Skip}Converged(), the
'snes-ops-converged' pointer will never be NULL now (if users pass
NULL to SNESSetConvergenceTest, SNESSkipConverged is set).

Is all this fine?


>
>    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?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594