Matthew Knepley wrote: > Really? This is ugly. It is not an algorithm, it is just sticking a > whole bunch of known shapes into a database.
Yes, but it is what most mesh-generators provide, it is low-memory, and is conducive to efficient query and modification, especially those involving a geometric model. Since I care about higher than second order elements, I disagree with the solution presented in Section 2.3 to the extent that many degrees of freedom (nodes or modes) need to be associated with each entity. When setting up a function space, I assign an anisotropic order to every mesh entity, reduce with a minimum rule (for continuity), label everything with a global offset, broadcast, and then build the element assembly matrix (a Scatter/IS is not enough because an element dof may correspond to a linear combination of global dofs). When building the element assembly matrix, I do something similar to you, where each region only looks directly at it's faces, faces at edges, etc, but I orient them based on vertex connectivity rather than storing an orientation for each relation. In the end, I don't see how to avoid writing something specific to each topology you want to handle, but you do not have to write anything special for each order. > We have a real algorithm that can compute all this on the fly with > simple rules. I assume you are talking about storing one-level downward adjacencies (region->faces, faces->edges, edges->vertices) and orientations, and inferring the rest. This is perfectly valid but you still have to make the same sort of arbitrary choices. It changes the complexity of certain operations and changes what sort of operations need to be special-cased on topology. The Sieve source has plenty of special casing and doesn't support the zoo, so I'm not convinced that it is the One True Way. Jed
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
