Re: [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.

fix-fieldsplit-recall-setfromoptions.patch
Description: Binary data

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 <pie...@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