I'll open a pull request Il 01/ott/2015 10:28 PM, "Barry Smith" <[email protected]> ha scritto:
> > Matt is at least partially right, having this as a SNESType is > questionable. It is actually a specific nonlinear preconditioner PLUS a > specific set of options for the NewtonLS SNES method. I also understand why > Peter did it this way because there is no clean "other way" to provide this > functionality that is not ad hoc. > > I think the correct short term fix is to add a SNESDestroy_ASPIN() that > does delete the npc and then calls the SNESDestroy_NewtonLS() > > Stefano, > > Are you willing to make a pull request or patch to do this? > > Thanks for letting us know about this problem > > Barry > > > > On Oct 1, 2015, at 12:43 PM, Matthew Knepley <[email protected]> wrote: > > > > On Thu, Oct 1, 2015 at 7:42 AM, Stefano Zampini < > [email protected]> wrote: > > I just noticed that the behaviour of a code like this > > > > SNESSetType(snes,SNESASPIN) > > SNESSetFromOptions(snes) > > > > is not the same as > > > > SNESSetType(snes,SNESNEWTONLS) > > SNESSetFromOptions(snes) > > > > when -snes_type newtonls is specified at command line. In both cases, > the snes will be of type SNESNEWTONLS, but in the first case, the snes > object will also have a nonlinear preconditioner embedded in, since > SNESASPIN creates snes->pc, and there's no SNESDestroy_ASPIN. > > > > What is the correct approach to fix this? Should the nonlinear > preconditioner be destroyed by the SNESSetType interface or by the specific > implementation of ASPIN? > > > > I wish Peter had not done it this way. His reason was that a special > Jacobian action can be defined for > > Newton -L NASM, but we should just do this with a flag rather than a new > SNES type. > > > > Matt > > > > > > -- > > Stefano > > > > > > > > -- > > 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 > >
