<div class="gmail_extra">On Sat, Nov 10, 2012 at 12:45 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=":6xy">It just depends on what you want your assumptions to be. I am all for<br>
experimenting. The<br>
foregoing strategy is good because closure continues to work as<br>
advertised, and all our<br>
integration code is still dim-independent, but the assumption that<br>
height 0 things are all<br>
cells breaks down. This is not so bad, since we usually want to group<br>
cells by material<br>
anyway, using a Label, so I am fine with this.</div></blockquote></div><br></div><div class="gmail_extra">Okay, my complaint is that "stratum" is an additional concept that has no established use in the current lexicon and the generality of which doesn't really help the user because they have to do different things for codim 0 and codim 1 anyway. If we are not causing extreme hardship or irreparably crippling the flexibility of their code, I think the interface should give access to by codim instead of by stratum.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Now in the P1 case, the faces do not store any data, therefore closure(some_cell) returns the same thing going directly to vertices as if the intermediate dimensions were populated. I think that by definition, this sort of mesh does not support getting faces of a cell, therefore it's correct to not store the cell -> boundary-face relation. The user can ask to interpolate the mesh if they want.<br>
<br>I'm not sure about the multi-domain case where the user wants a high-order discretization in one domain and a P1 with non-interpolated mesh in another. The benefit of non-interpolated doesn't seem so clear in this case.</div>