[petsc-dev] attaching field information to PetscLayout?

[Dmitry Karpeev]

On Sun, May 15, 2011 at 4:18 PM, Jed Brown <jed at 59a2.org> wrote:
> On Sun, May 15, 2011 at 22:39, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>>
>> Should overlapping splits and splits on subcommunictors be
>> allowed within PetscLayout?
>
> Is there something useful you can do with overlapping splits without knowing
> whether they overlap and without also having access to non-overlapping
> splits. PCASM treats the overlapping and non-overlapping decomposition as
> separate entities. I'm not opposed to having information about overlapping
> splits in PetscLayout, but if it's going to be used in a semantically
> different way, then perhaps it should be treated that way when stored in
> PetscLayout.

Good point.  Any overlapping split begets a nonoverlapping split eventually
and that's what should be stored in PetscLayout, since it requires no further
semantics or (linear) transformation to effect.  Then MatNest can be constructed
directly using that layout, I suppose.

The overlapping logic goes elsewhere (MatSetValuesLocal).

> Do you have thoughts on managing something like PCFieldSplit for low-Mach
> Euler? Where should the code for that sort of transformation (involving
> linearized equation of state) reside? What should the MatGetSubMatrix() or
> MatGetSchurComplement() look like when the requested subspace involves this
> transformation?