changes to SNES

[Barry Smith]

On Tue, 4 Sep 2007, Lisandro Dalcin wrote:

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

  Lisandro

   One concern is that naive people "benchmark" by running trivial
problems, then copies can have impact.

   If the code passes all tests, testexamples_C, testexamples_xxxx,....
then I am fine with you pushing the simplier code.

   Barry

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