changes to SNES

[Matthew Knepley]

On 9/4/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> 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.

If we want to change from he existing scheme, why not replicate it with
calls to VecPlaceArray()?

  Matt

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


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener