[petsc-dev] SNESSetKSP and SNESDestroy
Matthew Knepley
knepley at gmail.com
Thu May 30 07:42:04 CDT 2019
On Thu, May 30, 2019 at 6:08 AM Pierre Jolivet via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:
> Hello,
> I’m doing a continuation loop with something like:
> KSP ksp;
> KSPSetUp(ksp);
> while(cond) {
> SNES snes;
> SNESCreate(&snes);
> SNESSetKSP(snes, &ksp);
> SNESSolve(snes);
> SNESDestroy(&snes);
> }
>
> For the first iteration, everything is OK.
> After that, it looks like SNESDestroy is messing up with my outer-defined
> KSP(*), i.e., for the code to work I need to comment out the SNESDestroy.
> Is this the expected behavior? (if not, I’ll provide a MWE)
> How to fix this properly, without having leaks by not destroying the
> inner-defined SNESes?
>
> Thanks in advance,
> Pierre
>
> (*) to the outer-defined KSP is attached a PCFIELDSPLIT, first SNESSolve,
> everything OK:
> PC Object: 1 MPI processes
> type: fieldsplit
> FieldSplit with MULTIPLICATIVE composition: total splits = 2
>
> Second SNESSolve:
> [0]PETSC ERROR: PCFieldSplitSetDefaults() Unhandled case, must have at
> least two fields, not 1
I believe SNESDestroy() calls SNESReset(), which calls KSPReset(), which is
wiping out your information.
This pattern is in a lot of places. Destroy calls Reset because it is
natural to reuse the code which tears down
the internal structures. Reset calls reset on subobjects because we also
want to tear down their internal structures (usually).
Reset wouldn't do what we want on resizing if we left subobjects unreset.
However, this chain is causing subobjects to
be wiped clean on Destroy, so that we cannot reuse subobjects.
It would not even work if you change the Destroy to Reset in the
continuation loop. However, I think you can hoist all
the SNES setup outside the loop. If you are changing sizes, then the KSP
needs to be wiped out anyway. If not, then
you do not need to wipe out the SNES.
Thanks,
Matt
--
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
https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190530/8ce1adeb/attachment.html>
More information about the petsc-dev
mailing list