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