<div class="gmail_extra">On Sat, Nov 10, 2012 at 3:49 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":5ci">I am not sure I understand. Labels just define point sets. If you want<br>
to segregate point<br>
sets by dimension, that is fine. Nothing in the interface is sensitive<br>
to this, nor should it be.<br></div></blockquote><div><br></div><div>I can think of only one way in which numbering points by stratum versus dimension makes a tangible difference: whether contiguous ranges can contain unsorted mixed-dimensional points. I want to understand whether this is actually important and whether there is a different use case that is important. If not, then we could entirely discard the concept of stratum, sort points by co/dimension, and query based on labels.</div>
<div><br></div><div>Where is stratum as a concept irreplaceable?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5ci"><div class="im">
>><br>
>> You don't need coordinates for interpolation?<br>
><br>
><br>
> Are we talking about the same interpolation? If I have cell-to-vertex<br>
> connectivity, I can create the faces without coordinates, yes.<br>
<br>
</div>Ah, we are not. Mesh interpolation.<br>
<br>
The way I have done interpolation, you have to know the mesh dimension,<br>
DMComplexGetDimension(), and then it assumes that height 0 stuff is cells<br>
of that dimension.</div></blockquote></div><br></div><div class="gmail_extra">Then we're basically identifying stratum with dimension, suggesting that we should be able to remove stratum from the API in favor of co/dimension.</div>