ffc team mailing list archive

[<kirby@xxxxxxxxxxxx>]

I'm afraid that this discussion of what to name various pieces
of information about the mesh will lead to code growth by
accretion-on-demand rather than design.  It will also lead us
into maintaining separate code branches in 2d and 3d. 
Consider instead the following:

First, every mesh entity, whether a vertex, an edge, etc, has
at least two intrinsic geometric features:
1.) its intrinsic topological dimension (a vertex is dimension
0, and so on)
2.) its measure in that dimension (length of an edge, area of
a triangle, etc)

This suggests that "vertex","edge", etc are really instances
(or subclasses if you must) of an abstract "mesh entity" class
that have as member information the topological dimension and
coordinates.

Moreover, every mesh entity has certain topological/connection
information associated with it.  We might need to know what
faces are attached to which tets, which tets share a given
face (think discontinuous Galerkin or high degree Lagrange),
etc.  This connection information can be stored in a single
dictionary for each mesh entity -- Matt Knepley calls it an
"incidence relation".  This dictionary maps topological
dimension to a list of entities of that dimension that are
connected to the given entity.  So, for a vertex, you put "1"
into the indicence dictionary and get a list of all the edges
for which that vertex is an endpoint.  You put "2" into the
dictionary and you get out a list of triangles that form a
patch around the vertex.  For a triangle, you can put in "2"
and get what triangles share an edge, and so on.

This gives a minimal interface that you don't have to maintain
separately for different dimensions of meshes, and you don't
have to haggle over names.  All you have to do is get the
information from the mesh generator and into these data
structures.  Matt's package has this all done (plus
parallelism).  You should keep an eye on when this will be
ready to plug in.

Rob





---- Original message ----
>Date: Wed, 31 Aug 2005 17:57:50 +0200 (MEST)
>From: jhoffman@xxxxxxxxxxx  
>Subject: Re: [FFC-dev] Tensors  
>To: "Discussion of FFC development" <ffc-dev@xxxxxxxxxx>
>
>> I'm planning to add a list of predefined operators and
operands to FFC
>> to simplify and beautify the notation anyway, so this would
fit well
>> into that category.
>>
>> Operators that will be added include grad(), rot() and div().
>>
>> Operands that will be added include h (mesh size) and d
(space dimension).
>>
>> Any other suggestions?
>
>I find it useful to be able use some more geometry
information (in
>particular when we start integrating on surfaces):
>
>vol - volume of cell
>area(i) - area for local face i
>hface(i) - h for local face i
>...
>same for local edges?
>
>It may also be useful to be able to identify a local face from a
>collection of vertices; that is, while visiting a cell in the
assembly one
>might want to get information about the local faces.
>
>On the other hand, we may avoid a lot of this since we intend
to assemble
>separately over faces (and edges), and then vol and h may be
reduced to
>the corresponding functions for the face when looping over
the faces.
>
>/Johan
>
>
>
>
>
>
>
>_______________________________________________
>FFC-dev mailing list
>FFC-dev@xxxxxxxxxx
>http://www.fenics.org/cgi-bin/mailman/listinfo/ffc-dev