ffc team mailing list archive

[Robert C. Kirby <kirby@xxxxxxxxxxxx>]

Johan, thanks for the clarification, but I stand by my point with FFC.  
I fear we are "accreting" onto it.  My complaints about C++ are 
organized on the same lines -- it gives the feel of having lots of 
stuff added to it as Stroustrup decided to do it over many years.  You 
get weird syntax, clashing of concepts, and it creates so much 
cognitive dissonance for me.

The point of the mesh package is that we should strive to make our mesh 
as well as what goes on in the FFC syntax well-designed, general, and 
elegant, rather than just saying, "I need to solve this problem, so 
I'll slap on some incremental changes for now".  While things may be 
implemented in that way (we have finite time), the design process 
should be more careful.  Some weak forms, such as stabilizing terms, 
refer to the mesh (such as "h"), and we should not train FFC to worry 
what dimension things are in its syntax any more than is absolutely 
necessary.


Robert C. Kirby
Assistant Professor
Department of Computer Science
The University of Chicago
http://people.cs.uchicago.edu/~kirby
On Sep 1, 2005, at 1:22 AM, jhoffman@xxxxxxxxxxx wrote:

> Rob,
>
> All this is great, and it should be interesting to see Matt's mesh
> package. I'm sure it will be very useful for FEniCS. My understanding 
> of
> our current discussion is that it was related to what mesh information
> that should be avaliable through FFC when defining a form. Not a
> discussion of the possible names for this functionality, I certainly do
> not suggest to include functions like "h_face_x" or similar. I think 
> the
> question was what information about the mesh needed to be avaliable
> through FFC.
>
> /Johan
>
>
> > 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