Subject: [UFL-dev] form algebra

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 28 Jan 2009 15:05:24 +0100

Hi,

do we expect UFL to reduce the forms:

a = 0.5*v*u*dx - 0.5*v*u*dx = 0      (currently: 0.5*v*u*dx + -1*0.5*v*u*dx)
a = 0.5*v*u*dx + 0.5*v*u*dx = v*u*dx (currently: 2*(0.5*v*u*dx))

or should that be taken care of by the form compilers?

Also, is it possible to get all terms as a Sum of Products (expanded)?
As I see it the form compilers currently receive an arbitrarily nested
expression (Integrand).
Consider:

element = FiniteElement("Lagrange", triangle, 1)
element1 = FiniteElement("Lagrange", "triangle", 5)

v = TestFunction(element)
u = TrialFunction(element)

f = Function(element)
g = Function(element1)

a = (g + f)*v*u*dx

which I would like to have expanded into

a = g*v*u*dx + f*v*u*dx

because each Product will need a different number of quadrature points for exact
integration.
Or does the design allow for a better approach that I currently miss?

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 28 Jan 2009 15:59:18 +0100

> or should that be taken care of by the form compilers?

UFL does some simplifications, and I wouldn't mind these
particular examples to work as you wish here. But I want
to be very careful about doing automatic transformations
that are irreversible.

> Or does the design allow for a better approach that I currently miss?

This kind of expansion is not an option, since it is irreversible
and not necessarily wanted. Sum and Product are binary operators
by default, but in principle they can have more than two operands.
A few places in algorithms may currently be implemented assuming
only two operands, but I think I've marked them all with TODO.
So this kind of expansion should be implemented as an algorithm.
I actually attempted this (see flatten), but the current implementation
has some flaws w.r.t. indexed expressions. I'm about to implement
the IndexSum design mentioned in a previous email, hopefully this
might be easier then.

Also, one of the main reasons for making UFL in the first place is
that sums of products are _not_ a general enough representation.

Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 28 Jan 2009 16:58:34 +0100

> to be very careful about doing automatic transformations

OK.
 
> So this kind of expansion should be implemented as an algorithm.

Yes, that's what I was asking for, not a different representation of the form.
Sorry for the confusion.

> the IndexSum design mentioned in a previous email, hopefully this

OK, I'll have a look at that.
 
> that sums of products are _not_ a general enough representation.

OK, I'll worry about that later though.

Kristian