[petsc-dev] PCFIELDSPLIT with inner -ksp_reuse_preconditioner

[Barry Smith]

  Matt,

    This does not solve Pierre's problem because when the user calls XXSetFromOptions() later in the run, for example, to change some options for later computations the SetFromOptions on the inner objects do not get called; since the XXSetFromOptions__YYY() does not transverse through them by construction, hence one needs to add code like I have done to make sure that future calls to XXSetFromOptions__YYY()  do transverse them once they have been created.

Barry


> On Jul 13, 2022, at 12:14 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Wed, Jul 13, 2022 at 11:02 AM Barry Smith <bsmith at petsc.dev <mailto:bsmith at petsc.dev>> wrote:
> 
>   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.
> 
> My solution, which is used elsewhere in PETSc, would be for all PetscObjects to have a setfromoptions flag. If it creates a subobject and its own
> flag is set, it calls SetFromOptions on it.
> 
>   Thanks,
> 
>      Matt
>  
> Barry
>> On Jul 13, 2022, at 8:40 AM, Pierre Jolivet <pierre at joliv.et <mailto: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 <https://community.freefem.org/t/supply-petsc-numbering-for-shared-memory-block-matrix/486/18>
> 
> 
> -- 
> 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/20220713/8275bc67/attachment.html>