<div class="gmail_quote">On Sun, May 15, 2011 at 22:39, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2fn">Should overlapping splits and splits on subcommunictors be<br>
allowed within PetscLayout?</div></blockquote></div><br><div>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.</div>
<div><br></div><div>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?</div>