ufl team mailing list archive

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

Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:

> On Wed, Jan 28, 2009 at 3:05 PM, Kristian Oelgaard
> <k.b.oelgaard@xxxxxxxxxx> wrote:
> >
> > 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?
> 
> 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.

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

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

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

OK, I'll have a look at that.
 
> Also, one of the main reasons for making UFL in the first place is
> that sums of products are _not_ a general enough representation.

OK, I'll worry about that later though.

Kristian
 
> Martin
>