dolfin team mailing list archive

[Jed Brown <jed@xxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature