<div class="gmail_quote">On Sun, May 15, 2011 at 05:33, 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=":2dj">Would it be dangerous to be adding fields to a PetscLayout shared by<br>
many Vecs/Mats (hence, PCs)?<br></div></blockquote><div><br></div><div>I think PetscLayout should be strictly immutable after PetscLayoutSetUp().</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2dj">Yes, in fact, a field, at least in my mind, is more than just<br>
combinatorial information (IS), and might<br>
involve some linear-algebraic information (e.g., if getting the<br>
corresponding subvec or updating<br>
the containing vec requires a linear transformation).</div></blockquote><div><br></div><div>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).</div>
</div>