Makes perfect sense.
Thanks,
Pierre
> On 5 Nov 2017, at 2:52 AM, Jed Brown <j...@jedbrown.org> 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 <pierre.joli...@enseeiht.fr> 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
