[petsc-dev] composite vs. shell

[Jed Brown]

"Smith, Barry F." <bsmith at 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.  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 <jed at 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.jolivet at 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