[petsc-dev] PCFIELDSPLIT with inner -ksp_reuse_preconditioner

[Matthew Knepley]

On Wed, Jul 13, 2022 at 1:53 PM Barry Smith <bsmith at petsc.dev> wrote:

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

Yes, that makes sense.

  Thanks,

     Matt


> 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> 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> 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
>>
>>
>>
>
> --
> 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/>
>
>
>

-- 
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/4d882c1e/attachment.html>