ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On Wed, Mar 4, 2009 at 8:45 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Wed, Mar 04, 2009 at 08:15:53AM +0100, Martin Sandve Alnæs wrote:
>> On Wed, Mar 4, 2009 at 12:31 AM, Kristian Oelgaard
>> <k.b.oelgaard@xxxxxxxxxx> wrote:
>> > Quoting Anders Logg <logg@xxxxxxxxx>:
>> >
>> >> On Tue, Mar 03, 2009 at 09:10:50PM +0100, Martin Sandve Alnæs wrote:
>> >> > On Tue, Mar 3, 2009 at 12:18 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>> >> > > Is there a way to transform an expression to remove ListTensor from
>> >> > > the tree? I'm struggling with the monomial transformation.
>> >> > >
>> >> > > Take for example the following expression:
>> >> > >
>> >> > >  inner(as_tensor([v[0], v[1]]), as_tensor([u[0], u[0].dx(1)]))
>> >> > >
>> >> > > This might be rewritten as
>> >> > >
>> >> > >  a = v[0]*u[0] + v[1]*u[0].dx(1)
>> >> > >
>> >> > > This I can handle, but not the version containing ListTensor.
>> >> >
>> >> > You have something similar in FFC, right?
>> >> > vec and mat or something?
>> >> > How do you handle those?
>> >> >
>> >> > Martin
>> >>
>> >> The corresponding thing in FFC is regular Python lists. For example,
>> >> here's the grad() operator:
>> >>
>> >> def grad(v):
>> >>     "Return gradient of given function."
>> >>     # Get shape dimension
>> >>     d = __cell_dimension(v)
>> >>     # Check if we have a vector
>> >>     if value_rank(v) == 1:
>> >>         return [[D(v[i], j) for j in range(d)] for i in range(len(v))]
>> >>     # Otherwise assume we have a scalar
>> >>     return [D(v, i) for i in range(d)]
>> >>
>> >> At some later point, the list will appear as an argument of a dot
>> >> product or it might be indexed (with a fixed index). The result of
>> >> both operations will remove the list and return a scalar expression.
>> >>
>> >> So when a form has been defined correctly, the resulting expression is
>> >> always a scalar which does not contain any lists. What makes this
>> >> simpler in FFC might be that only fixed indices (ints) are allowed as
>> >> indices in a list, whereas UFL allows general indices to be used.
>> >>
>> >> In particular, the following is not allowed in FFC:
>> >>
>> >>   a = grad(v)[i]*grad(u)[i]*dx
>> >>
>> >> One must write one of the following:
>> >>
>> >>   a = dot(grad(v), grad(u))*dx
>> >>   a = v.dx(i)*u.dx(i)*dx
>> >>
>> >> The important point here is that dot() will pick out the elements in
>> >> the list one by one and return something that is not a list.
>> >>
>> >> I don't know if it would be a too severe restriction to disallow
>> >> general indices in a ListTensor.
>> >
>> > If I understood it correctly, it should be
>> > 'general indices OF a ListTensor' ??
>> >
>> > Kristian
>>
>> That's what I think he meant too. And if I understand this
>> correctly, arbitrary limitations like that is not an option in UFL.
>> Any tensor _valued_ expression can be indexed, and that's
>> the way it should be. That's also the whole point of the ListTensor,
>> to make subexpressions into a tensor valued expression.
>> The alternative is an inconsistent language and special cases
>> all over the place. The limitations of the tensor representation
>> is one of the reasons I got into this in the first place :-P
>
> Would it help to expand IndexSum into a sum of terms, adding more Sum
> nodes to the tree, each one with a fixed index value? This should (at
> least in some simple cases with limited nesting) result in Indexed
> nodes with children that are ListTensor and FixedIndex, which would
> make it possible to just pick out the correct item and remove
> ListTensor from the tree.

Yes, that's basically what I've been thinking. My thoughts now are:
1) Implement a general expand_index_sums, just to get this part right
2) Make a specialization of this that only expands the index sums
where the index ultimately applies to a ListTensor

If you index a ListTensor with a fixed index, the subcomponent is
already being extracted as a simplification.

Martin