Subject: [UFL-dev] ListTensor

From: Anders Logg <[email-masked]>
Date: Tue, 3 Mar 2009 00:18:40 +0100

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.

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 09:02:54 +0100

Nothing implemented, no.
I'll have to think about it.

Martin

On Tue, Mar 3, 2009 at 12:18 AM, Anders Logg <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmsaVAACgkQTuwUCDsYZdEhNACbBmD2+FcNT7zHrIXIfQlKYdOl
> pNUAoI+//ZSnHMNXDUbYBnCjSYCK7kbF
> =4bc7
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev
>
>

---

From: Anders Logg <[email-masked]>
Date: Tue, 3 Mar 2009 09:54:55 +0100

Thanks.

-- 
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 03 Mar 2009 16:37:10 +0100

> I'll have to think about it.

Could someone please fill me in on the most important details of ListTensor?
Looking at the sub tree I get a strong urge to just ignoring it, would that be safe?

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 17:51:14 +0100

> Looking at the sub tree I get a strong urge to just ignoring it, would that be safe?

I don't get what you're asking for here. Temporarily you can
probably ignore it, but in the end it should be supported.

Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 03 Mar 2009 18:29:44 +0100

> probably ignore it, but in the end it should be supported.

I had a second look at Indexed vs. ComponentTensor (and ListTensor) and I think
I managed to make some sense out of it. But why does ListTensor not have indices
like ComponentTensor?

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 18:42:04 +0100

> I managed to make some sense out of it. But why does ListTensor not have indices

Why should it have indices? It represents a tensor composed of an
explicit list of arbitrary subtensors with no connection whatsoever.
(If its subtensors are scalar expressions, think of it as ListVector,
which it was in the first version)

Example:
  w = as_vector((1.0, 2.0)) # -> ListTensor((FloatValue(1.0), FloatValue(2.0))
  fixed_convection = dot(w, grad(u))

Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 03 Mar 2009 18:50:42 +0100

Quoting Martin Sandve Alnæs <[email-masked]>:

> >> > Looking at the sub tree I get a strong urge to just ignoring it, would
> that
> >> be safe?
> >> >
> >> > Kristian
> >>

Maybe it's just because I don't see what ListTensor does which ComponentTensor
can't.

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 18:58:48 +0100

> Maybe it's just because I don't see what ListTensor does which ComponentTensor

For starters, ComponentTensor can't represent the constant vector
(1.0, 2.0) shown above.

Take a scalar expression Aij with A.free_indices() being
a superset of all indices in the MultiIndex ij, and let
  A = ComponentTensor(Aij, ij)
Here A represents the tensor-valued expression with components given by Aij.
The rank of A equals len(ij).

Then assume (a, b, c) three distinct unrelated scalar expressions, and let
  B = ListTensor(a, b, c)
Here B represents the vector with components a, b, and c.

Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 03 Mar 2009 19:28:25 +0100

Quoting Martin Sandve Alnæs <[email-masked]>:

> >> > I had a second look at Indexed vs. ComponentTensor (and ListTensor) and
> I
> >> think
> >> > I managed to make some sense out of it. But why does ListTensor not
> have
> >> indices
> >> > like ComponentTensor?
> >> >
> >> > Kristian
> >>

A_j = j + 1 ?

> Here B represents the vector with components a, b, and c.

I'll look at it some more, but I think I've figured it out.

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 19:52:14 +0100

>> For starters, ComponentTensor can't represent the constant vector

That's not a valid expression for two reasons.

The first is that you (currently) can't use the indices as values in
an expression.

The second is that summands must have the exact same sets of free indices,
otherwise we get inconsistencies (see the ROADMAP file).

But to give another concrete example, ComponentTensor can't
represent the vector (f, f**2) where f is a scalar Function.

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 Mar 2009 21:10:50 +0100

> 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

---

From: Anders Logg <[email-masked]>
Date: Tue, 3 Mar 2009 22:11:15 +0100

> vec and mat or something?

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.

-- 
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 04 Mar 2009 00:31:40 +0100

> general indices in a ListTensor.

If I understood it correctly, it should be
'general indices OF a ListTensor' ??

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 4 Mar 2009 08:15:53 +0100

> 'general indices OF a ListTensor' ??

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

Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 4 Mar 2009 08:45:12 +0100

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

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 4 Mar 2009 09:34:43 +0100

> 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

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 4 Mar 2009 13:25:36 +0100

> already being extracted as a simplification.

See the latest commit message.

I have to prioritize some other things before improving it further.

Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 4 Mar 2009 13:26:05 +0100

> I have to prioritize some other things before improving it further.

Thanks. I'll try it out.

-- 
Anders