ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>]

Quoting Anders Logg <logg@xxxxxxxxx>:

> I just fixed a bug in UFL for lhs/rhs when applied to mixed problems
> and noticed some strange results for the generated quadrature
> code. Nothing serious, but a bit annoying.
>
> There are two different demos in UFL: Stokes.ufl and StokesEquation.ufl.
> They should give the same results. The results are the same for tensor
> representation, but differ for quadrature. The difference is in the
> following code:
>
> 1. Code generated from Stokes.ufl
>
>   // Number of operations for primary indices = 90
>   for (unsigned int j = 0; j < 15; j++)
>   {
>     // Number of operations to compute entry = 6
>     A[j] += (FE0_C0[ip][j]*F0 + FE0_C1[ip][j]*F1)*W9[ip]*det;
>   }
>
> 2. Code generated from StokesEquation.ufl
>
>   // Number of operations for primary indices = 120
>   for (unsigned int j = 0; j < 15; j++)
>   {
>     // Number of operations to compute entry = 8
>     A[j] += (FE0_C0[ip][j]*F0 + FE0_C1[ip][j]*F1)*-1*-1*W9[ip]*det;
>   }
>
> So we get an extra (-1)*(-1) which I guess should be possible to remove?

Not really, the tree-format of the integrand that the quadrature transformer
receives contains:

Product
(
 IntValue(-1, (), (),{})
 Product
 (
  IntValue(-1, (), (),{})
  Sum
  (
[snip]

one '-1' from F and one '-1' when applying rhs(F).
The quadrature transformer (without optimisation) is not aware of any values, it
just translates UFL objects into strings (you can use the -O option and they
will be removed).
To fix this 'bug' we should let UFL handle float values when expanding indices
and derivatives. Note that this would probably mean that:

-1*x*-1*y --> x*y, OK
2*(x + y) --> 2*x + 2*y, maybe not so nice

In short, it is possible to remove but I don't know if it is worth the effort,
if you want the same code in both cases use the -O option.

Kristian

> --
> Anders
>