Subject: [UFC-dev] Function names

From: Anders Logg <[email-masked]>
Date: Fri, 8 Dec 2006 21:35:00 +0100

I'd like to add another thing to the UFC: identifiers for coefficients.

Right now, coefficients are defined only by position: w[0], w[1], ...

If one could somehow ask the UFC for a string for function i, this
would improve the possibilities for integrating the UFC into a
just-in-time compilation framework.

Here's a specific example. In FFC, one will be able to write things
like

    jump(v)

for the jump of v across an interior facet, which is used in DG
methods. The jump is really defined in terms of two functions: the
given function v and the facet normal n = n(x):

    jump(v, n) = v^{+} n^{+} + v^{-} n^{-}

If we could specify coefficients by name, then the compiler (FFC)
could automatically create the function n when someone calls jump()
and give the function n the name "facet normal". Then the system that
uses the UFC could check if there is a function named "facet normal"
and in which position it is located, say w[3], and supply the
coefficients.

The change would be to add an extra member function to ufc::form:

    /// Return a string identifying argument function i
    virtual const char* function_signature(unsigned int i) const = 0;

I would also suggest changing "description()" everywhere to
"signature()". This signals that the string returned is something that
identifies the object, not only gives a description (which is weaker).

/Anders

---

From: Ola Skavhaug <[email-masked]>
Date: Sat, 9 Dec 2006 00:51:22 +0100

> and in which position it is located, say w[3], and supply the

Isn't it possible to calculate the facet normal based on the geometric
information in a cell? I am generally a bit skeptic to allow char*
communication through the interface. Maybe it is a sign of a flaw in the
design? Could we implement the same thing using another approach?

> identifies the object, not only gives a description (which is weaker).

Explicit is better than implicit (tm). Strong is better tant weak. How do we
inteprate signature? Is it a signature that can be used to uniquely identify
(construct) an instance from a type (a-la Python's __repr__)?

Ola
 
> /Anders
> 
> _______________________________________________
> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev

---

From: Anders Logg <[email-masked]>
Date: Sat, 9 Dec 2006 10:19:19 +0100

On Sat, Dec 09, 2006 at 12:51:22AM +0100, Ola Skavhaug wrote:
> Anders Logg skrev den 08/12-2006 f?lgende:

A facet normal on the reference cell does not map to a facet normal on
a physical cell, so if we have an integral involving facet normals on
a facet, it does not directly translate into an integral involving
facet normals on the reference cell.

We could use the Piola mapping for this but that would require more
work.

> (construct) an instance from a type (a-la Python's __repr__)?

Yes, exactly. For instance, the signature of a ufc::form would be a
signature that completely determines the form in the UFL form
language. It does not matter yet that UFL has not been specified. We
can still specify in the interface of UFC that a function should
return a UFL signature.

/Anders

---

From: Anders Logg <[email-masked]>
Date: Tue, 12 Dec 2006 11:48:50 +0100

> can still specify in the interface of UFC that a function should

After some more discussions, I'm now fairly convinced the function
signatures will not be needed. I'm happy if we just keep the current
signatures.

If there are no objections, I'll change "description" --> "signature".

/Anders