Subject: [FFC-dev] restriction on constants

From: Kristian Oelgaard <[email-masked]>
Date: Fri, 13 Jul 2007 15:55:11 +0200

Hi,

Is there a reason for constants to be restricted to ('+/-') as default?

The reason I'm asking is the following:

If compiling

element = FiniteElement("Lagrange", "triangle", 1)
v = TestFunction(element)
c = Constant("triangle")

L = dot(grad(v),grad(c))*dx

using tensor contraction the result is correct since the values in the reference
tensor for the grad(c) part will all be zero -> no code generated -> no need for
Jinv*_**

If compiling the same form with quadrature, the resulting *.h file cannot be
compiled with DOLFIN because quadrature has no concept of tracking zeros at
compile time -> generate code -> where Jinv*_** is needed.

This causes a problem since the default restriction for a constant transform is
"0", so e.g. Jinv0_00 will be needed, but since we're integrating over 'dx' the
jacobian code snippet only (and so it should) contains Jinv_** terms which will
lead to a c++ compile error.

So it would be nice to return to the old definition of Constant() for which I
think there was no restriction, or make the default restriction for constant (in
ufcformat.py) equal to that of None i.e. ""

Or maybe there's a reason for these restrictions so I should come up with
another solution?

Kristian

---

From: Anders Logg <[email-masked]>
Date: Mon, 23 Jul 2007 23:45:13 +0200

> Is there a reason for constants to be restricted to ('+/-') as default?

Yes, since they are DG0 functions and as such potentially discontinuous.

> lead to a c++ compile error.

Could we call remove_unused just for the quadrature code? (It should be 
fairly fast since the code is so short.)

> Or maybe there's a reason for these restrictions so I should come up with

We can't go back to the old definition since we decided (for simplicity) 
not to have constants in the UFC specification (since it can be covered 
   by Functions).

One option could be to add a new type of element ConstantElement and 
then have

element = FiniteElement("constant", ...)

that instantiates a ConstantElement. This element just returns a single 
value and we could treat it specially to avoid having restrictions on it.

Could that work?

/Anders

> Kristian
> 
> _______________________________________________
> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev