[petsc-dev] attaching field information to PetscLayout?

[Barry Smith]

On May 14, 2011, at 3:09 PM, Jed Brown wrote:

> On Sat, May 14, 2011 at 21:47, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> Can these split ISs have communicators different from that of
> PetscLayout (this is something I use in GASM,
> for example)?
> 
> I guess I always thought of the field information in PetscLayout as having semantic meaning to the user. I also thought these ISs would be strictly non-overlapping and addressing locally owned values.

Dmitry asked: What will be the meaning of overlapping splits?

Matt wrote:  boundary conditions (if you want). 

Jed wrote later:  think that has different semantic meaning and thus deserves a different mechanism. I don't know whether it belongs in PetscLayout, but I think it is a different beast from defining "fields" that have semantic meaning to the user.



Barry responds: we could require non-overlapping splits but I am not sure if that is necessary or desirable. For example, the first IS might denote velocity variables, the second IS might denote pressure variables the third IS might denote locations with fixed boundary conditions. All of these things have "semantic meaning" to the users. Only some of them may have meaning to the PCFieldSplit. If we could use the same mechanism for all of them that might be better than having different mechanisms for "marking" different "meanings".

   Barry




> In that context, there is no particular disadvantage to always using global ISs, and I think it would help keep the code simple. If you are going to solve part of the problem on a sub-communicator, you can define that subcomm as all those processes that have non-empty local part in the IS. If you have a huge number of splits (such that individual splits on longer have semantic meaning), then I think it is a different purpose.