<div class="gmail_extra">On Sat, Nov 10, 2012 at 3:12 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":584">Yes, I agree completely with batching of this kind, which is why my integration<br>
functions look like they do. However, the topology information is not<br>
really needed<br>
in these kernels. Instead you are packing discretization information, like<br>
FEM coefficients, or geometric information like Jacobians, which are<br>
all controlled<br>
by PetscSection, not by the DMComplex.</div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">At the time you call an element residual kernel, you definitely need that information. Now the question is how much should bubble up to higher levels.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Because I think topological dimension is an important attribute (I think the library should be able to distinguish tets from quads), I was only proposing using topological dimension more explicitly. Karl suggests one step further in delineating the specific topology. My concern with that is keeping a contiguous index space. If there is sorting by cell topology, you no longer have to store size explicitly for each point in the coneSection.</div>