ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Kristian Oelgaard wrote:
> Hi,
>
> Is there a reason for constants to be restricted to ('+/-') as default?

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

> 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.

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

> 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?

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