"Smith, Barry F." <[email protected]> writes: > Jed, > > Please articulate in a bit more detail. From what I can interpolate you > are saying > > 1) that if we only propagate the outer matrices to inner matrices that the > user has not set we will get a better more intuitive interface for users > > but > > 2) the whole idea of propagating in is probably flawed.
The idea of having only two matrices, Amat and Pmat, is flawed. A composite preconditioner, for example, may need more. Having users unwrap solvers to manually set matrices is ugly, but in lieu of a better way (like named auxiliary matrices that can be requested by nested preconditioners), we should honor the user's manual choices. > My interpretation is that, since it unlikely we are going to immediately come > up with a better abstract than propagating we should fix 1) and leave 2) for > the future. Is this a reasonable thing to do, that is do not stop improvement > because perfection is better? Or is there something else we should do? > > Barry > > > >> On Nov 4, 2017, at 8:52 PM, Jed Brown <[email protected]> wrote: >> >> PCSetUp_Composite propagates the outer matrices to the inner PCs. >> >> while (next) { >> ierr = PCSetDM(next->pc,dm);CHKERRQ(ierr); >> ierr = PCSetOperators(next->pc,pc->mat,pc->pmat);CHKERRQ(ierr); >> next = next->next; >> } >> >> >> You can get the desired behavior by calling PCSetUp before >> PCCompositeGetPC. >> >> Perhaps the code should be changed to only propagate the outer matrices >> if they haven't been set yet. But propagating matrices like this is a >> poor abstraction in general because it conflates configuration with the >> supply of problem information. We don't want the FormJacobian in a time >> integrator to need to reach into the SNES -> KSP -> PCComposite to set a >> different operator; it doesn't even have enough information to do that. >> >> Pierre Jolivet <[email protected]> writes: >> >>> I’d like to use PCCOMPOSITE to define a preconditioner as the sum of two >>> preconditioners with different operators. >>> My current code works with a PCSHELL, but I don’t know how to setup the >>> PCCOMPOSITE appropriately to get the same results. >>> Attached is a reproducer (using complex scalars). >>> $ ./SHELL_v_COMPOSITE -fSp S.bin -fMp Mp.bin -fLp Lp.bin -ksp_view -pc_type >>> shell -ksp_type preonly >>> $ ./SHELL_v_COMPOSITE -fSp S.bin -fMp Mp.bin -fLp Lp.bin -ksp_view >>> -ksp_type preonly -pc_type composite -pc_composite_type additive >>> -prefix_push sub_0_ -pc_type ksp -ksp_ksp_type preonly -ksp_pc_type jacobi >>> -prefix_pop -prefix_push sub_1_ -pc_type ksp -ksp_ksp_type preonly >>> -ksp_pc_type jacobi -prefix_pop >>> What looks weird to me is that for the PCSHELL, the operators for both PCs >>> are of the correct size (36588 and 36814 nonzeros respectively), while for >>> the PCCOMPOSITE, it looks like the same operator is duplicated (-ksp_view >>> tells me that both have 36814 nonzeros which is not what I get with >>> -mat_view ::ascii_info). >>> Any idea on how to fix this? >>> >>> Thanks, >>> Pierre
