[petsc-dev] attaching field information to PetscLayout?

[Dmitry Karpeev]

On Sun, May 15, 2011 at 1:55 PM, Jed Brown <jed at 59a2.org> wrote:
> On Sun, May 15, 2011 at 05:33, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>>
>> Would it be dangerous to be adding fields to a PetscLayout shared by
>> many Vecs/Mats (hence, PCs)?
>
> I think PetscLayout should be strictly immutable after PetscLayoutSetUp().

Okay.  Should overlapping splits and splits on subcommunictors be
allowed within PetscLayout?
I think they should, at least at the PetscLayout level (particular
Vec/Mat/PC/DM objects might
reject overlaps/subcomms, if they violate their semantics).
All it really means at this point is that no checks are made during
PetscLayoutAddSplits
regarding overlaps and communicator equality.  Although it may be convenient
to make sure that the split communicators are actually *sub*communicators.

Dmitry.

Dmitry.
>>
>> Yes, in fact, a field, at least in my mind, is more than just
>> combinatorial information (IS), and might
>> involve some linear-algebraic information (e.g., if getting the
>> corresponding subvec or updating
>> the containing vec requires a linear transformation).
>
> I think this might be snowballing beyond what is reasonable to handle at
> this level. Someone might say that converting [Density,Momentum,Energy] to
> [Pressure,Velocity,Temperature] has some semantic meaning to them and they
> want to tell PETSc about it, but it may be a hard sell to demonstrate that
> an equation of state belongs in PetscLayout. This example isn't even
> contrived though: the relevant Schur complement for preconditioning low-Mach
> Euler is a parabolic operator in the pressure space, despite the fact that
> pressure is not a conserved variable (thus not explicitly present in the
> original system).