ffc team mailing list archive

[jhoffman@xxxxxxxxxxx]

The same thing is true for operations like 'sqrt' and division. Today we
declare a Function in DOLFIN and manually implement the inverse of the
magnitude of a certain Function w, which is sort of messy. It would be
much cleaner (and be more memory efficient) to be able to write
'1.0/sqrt(sqr(w1) + sqr(w2))' in FFC directly.

I agree that we should be very careful about the design. But that does not
have to be in conflict with having some nice functionality on top of that.

/Johan


> 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/
>
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/ffc-dev
>