ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Yes, the intention is that we should look closely at Matt's new mesh
component and if possible completely throw out all our mesh stuff and
wrap the new mesh component in DOLFIN.

When you're ready Matt, pick a name (Sieve?) and put it on fenics.org.

My only worries is that (i) the new mesh component will be not be
limited enough in its scope and force us to throw out more than just
the mesh component and (ii) it will be impossible to install... ;-)

/Anders

On Wed, Aug 31, 2005 at 05:53:08AM -1100, kirby@xxxxxxxxxxxx wrote:
> 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
> 
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/ffc-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/