> On Nov 9, 2017, at 11:13 PM, Jed Brown <j...@jedbrown.org> wrote:
>
> "Smith, Barry F." <bsm...@mcs.anl.gov> 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.
Yes
> 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.
Yes.
But you are not directly answering my question. Should we change the code
to not propagate if already set?
>
>> 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 <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
