ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Good point, but all things that I'm planning to add onto FFC will just
be shortcuts to things that one can already do today.

One example is the mesh size h. One can do stabilization already today:
Garth has implemented stabilized convection-diffusion in DOLFIN with
FFC, and Johan has stabilized Navier-Stokes. To do this, they just
declare a piecewise constant Function h in FFC (which is part of the
basic functionality, to have arbitrary user-defined functions in the
forms). The problem is that they then need to create a Function h in
DOLFIN and manually implement that the value of h should be the mesh
size on each cell. To simplify, I just need to add a predefined
Function in FFC, something like

    h = Function("mesh size")

This won't add to the complexity of FFC, since it's just an add-on
that works on top of the existing machinery.

Same thing with adding new operators grad, div, rot. They can also be
defined in terms of the existing language.

/Anders

On Fri, Sep 02, 2005 at 08:35:29AM -0500, Robert C.Kirby wrote:

> 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
> >>
> >
> >
> 
> 
> _______________________________________________
> 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/