[petsc-dev] SNESSetKSP and SNESDestroy

[Smith, Barry F.]

   Yeah, this is a bug in the PETSc design. But I don't see any simple solution. Given the models of reset, SNESSetKSP() is dangerous because it only increases the reference count and has no control over the reset process. At times I've regretted SNESSetKSP() and been tempted to remove it.

    As Matt says if you can move the SNESCreation outside the loop the problem will be resolved.

    As an alternative hack you could change the code as follows:

>> 
    KSP dummy;
    KSPCreate(...,&dummy);
>> KSP ksp;
>> KSPSetUp(ksp);
>> while(cond) {
>>         SNES snes;
>>         SNESCreate(&snes);
>>         SNESSetKSP(snes, &ksp);
>>         SNESSolve(snes);
            SNESSetKSP(snes,dummy);
>>         SNESDestroy(&snes);
>> }
It should work even if you don't setup dummy. But perhaps it is picky and you may need to add a matrix to dummy etc (don't worry it doesn't copy the matrix).

  Barry




> On May 30, 2019, at 9:51 AM, Stefano Zampini via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> 
> I meant SNESDestroy should call KSPDestroy
> 
> The reason for having the XXXReset methods called by the XXXDestroy is mostly code reuse, and it may lead to troubles.
> The Reset concept is not uniform throughout the library.
> 
>> On May 30, 2019, at 3:59 PM, Stefano Zampini <stefano.zampini at gmail.com> wrote:
>> 
>> I think snes reset should call ksp destroy. I don't see the case for which this can lead to troubles 
>> 
>> Il Gio 30 Mag 2019, 15:43 Matthew Knepley via petsc-dev <petsc-dev at mcs.anl.gov> ha scritto:
>> 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/
>