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.
