ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Mar 04, 2009 at 01:25:36PM +0100, Martin Sandve Alnæs wrote:
> On Wed, Mar 4, 2009 at 9:34 AM, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> > 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
> 
> See the latest commit message.
> 
> I have to prioritize some other things before improving it further.

Thanks. I'll try it out.

-- 
Anders

Attachment: signature.asc
Description: Digital signature