[petsc-dev] PCFIELDSPLIT with inner -ksp_reuse_preconditioner

[Barry Smith]

  Some of the ugliness of SetFromOptions in some of the nested solvers :-(

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001132795f0 libpetsc.3.017.3.dylib`KSPSetFromOptions(ksp=0x00007f899f149a70) at itcl.c:324:19
    frame #1: 0x0000000112eddda4 libpetsc.3.017.3.dylib`PCSetUp_FieldSplit(pc=0x00007f899f08d870) at fieldsplit.c:1087:32
    frame #2: 0x0000000112dfb874 libpetsc.3.017.3.dylib`PCSetUp(pc=0x00007f899f08d870) at precon.c:991:5
    frame #3: 0x0000000113285834 libpetsc.3.017.3.dylib`KSPSetUp(ksp=0x00007f899e95f670) at itfunc.c:401:3
    frame #4: 0x000000011328b5e9 libpetsc.3.017.3.dylib`KSPSolve_Private(ksp=0x00007f899e95f670, b=0x00007f899f0dec70, x=0x00007f899f0ce870) at itfunc.c:835:3
    frame #5: 0x000000011328aa66 libpetsc.3.017.3.dylib`KSPSolve(ksp=0x00007f899e95f670, b=0x00007f899f0dec70, x=0x00007f899f0ce870) at itfunc.c:1066:3
    frame #6: 0x000000010e7c94e8 ex1111`main(argc=12, args=0x00007ff7b1739328) at ex1111.c:33:3
    frame #7: 0x000000011703751e dyld`start + 462

The SetFromOptions doesn't always traverse all the sub-methods suitably calling SetFromOptions on them because they may not have been created by the time that
the SetFromOptions is first called. In this case, the PCSetUp_FieldSplit() creates the sub solvers and calls the options database on them after the initial call to PCSetFromOptions_FieldSplit() 

I've attached a patch that should fix this particular issue. I ran it with your test code, and it seemed to resolve the issue and ran the test suite, and it did not break anything.

A redesigned/implemented PETSc would need some thought on how to improve the SetFromOptions model to prevent this kind of difficulty.

Barry




> On Jul 13, 2022, at 8:40 AM, Pierre Jolivet <pierre at joliv.et> wrote:
> 
> Hello,
> A user(*) wants to switch back and forth with the option -fieldsplit_1_ksp_reuse_preconditioner, but it’s generating results that I don’t understand.
> In the following example I solve three successive linear systems.
> If I run
> $ ./ex1111 -pc_type fieldsplit -fieldsplit_pc_type lu -log_view -info -options_view -switch false
> -fieldsplit_1_ksp_reuse_preconditioner is always false, and I properly get:
> 1) convergence in a single iteration every time 
> 2) [0] PCSetUp(): Setting up PC with same nonzero pattern for the last solve
> 3) MatLUFactorNum         3 in -log_view
> 
> Now, if I run
> $ ./ex1111 -pc_type fieldsplit -fieldsplit_pc_type lu -log_view -info -options_view -switch true
> -fieldsplit_1_ksp_reuse_preconditioner is set to true for the second solve and switched back to false for the last solve.
> I (wrongfully, IMHO?) get:
> 1) convergence in 2 iterations for the last solve (instead of 1?)
> 2) [0] PCSetUp(): Leaving PC with identical preconditioner since reuse preconditioner is set (which should not be set for the last solve?)
> 3) MatLUFactorNum         1 (instead of 2?)
> 4) #PETSc Option Table entries:
> -fieldsplit_1_ksp_reuse_preconditioner false (though from -info, cf. point #2 just above, this option value is true?)
> 
> Does it make sense or do you agree that something is off?
> 
> Thanks,
> Pierre
> 
> <ex1111.c>
> 
> (*) https://community.freefem.org/t/supply-petsc-numbering-for-shared-memory-block-matrix/486/18

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220713/0bb9b858/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-fieldsplit-recall-setfromoptions.patch
Type: application/octet-stream
Size: 1641 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220713/0bb9b858/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220713/0bb9b858/attachment-0001.html>