This is a bug https://gitlab.com/petsc/petsc/-/merge_requests/5424 <https://gitlab.com/petsc/petsc/-/merge_requests/5424> repeated calls to XXXSetFromOptions() with changed options should always propagate down to all the sub solvers regardless of how much a pain it may be to do, otherwise it provides a terrible user experience.
> On Jul 13, 2022, at 12:14 PM, Matthew Knepley <[email protected]> wrote: > > On Wed, Jul 13, 2022 at 11:02 AM Barry Smith <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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/>
