changes to SNES

[Lisandro Dalcin]

On 9/4/07, Matthew Knepley <knepley at gmail.com> wrote:
> If we want to change from he existing scheme, why not replicate it with
> calls to VecPlaceArray()?

Because this can interact bad with user code? Nested calls currently
generate an error.  Isn't all this a case of premature optimization?.

I'm inclined to think that two vec copies are not expensive compared
with computing actual functions/jacobians, solving linear systems
(perhaps next doing line search/ trust region), and even computing
VecNorm's in many places. Does this reasoning make sense?


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


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