Subject: [UFL-dev] [HG UFL] Temporarily give up on implementation of is_multilinear (see comment

From: [email-masked] (UFL)
Date: Mon, 29 Sep 2008 21:56:39 +0200 (CEST)

One or more new changesets pushed to the primary ufl repository.
A short summary of the last three changesets is included below.

changeset:   286:1a8f946c08dbd537cdafd0ab33fe14a7c546f7eb
tag:         tip
user:        Anders Logg <[email-masked]>
date:        Mon Sep 29 21:56:47 2008 +0200
files:       sandbox/multilinear.py ufl/algorithms/predicates.py
description:
Temporarily give up on implementation of is_multilinear (see comment
in predicates.py). The extra stack argument that was added to the traversal
algorithms is not used, so it can be removed if we find out we don't need it.

changeset:   285:2347e1f6ce51e00492e6eed0e769d582bd37a2ca
parent:      284:c31a973fa84f0ed15e3a8c3761a608a2bdbc1b61
parent:      283:6fa9c6e9e2989fcb8d2242b15a1353fb8374cfa8
user:        Anders Logg <[email-masked]>
date:        Mon Sep 29 16:33:26 2008 +0200
files:       
description:
merge

changeset:   284:c31a973fa84f0ed15e3a8c3761a608a2bdbc1b61
parent:      282:eefbe0539581b033128e669ba1f87e3588388aa4
user:        Anders Logg <[email-masked]>
date:        Mon Sep 29 16:33:00 2008 +0200
files:       sandbox/multilinear.py ufl/algorithms/analysis.py ufl/algorithms/predicates.py ufl/algorithms/traversal.py
description:
Work on traversal algorithms:
- Keep track of operator stack when traversing expression tree:
- Add default iterator traversal() same as pre_traversal

Usage:

  for (o, stack) in traversal(expression):
      ...

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ufl

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 29 Sep 2008 23:03:14 +0200

I was wondering how you intended to use that :)
Lets discuss how to best do this soon, I can show you
how I've been thinking in the other algorithms as well.

-- 
Martin

2008/9/29 UFL <[email-masked]>:
> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev
>

---

From: Anders Logg <[email-masked]>
Date: Mon, 29 Sep 2008 23:14:06 +0200

> I was wondering how you intended to use that :)

I was planning to count the number of products each basis function
appeared in. That worked but then I realized that's not what we need.
We need to know how many of each basis function appears in a product.

> how I've been thinking in the other algorithms as well.

It can be easily implemented using the monomials() function I just
added. It returns a list of tuples, where each tuple is a product of
basis functions.

The final monomials() function will do some more, like propagating all
linear (differential) operators to the basis functions.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 29 Sep 2008 23:49:31 +0200

> We need to know how many of each basis function appears in a product.

And that no basis functions appear as arguments to nonlinear functions like exp.

You commented that is_multilinear is FFC-specific. But a valid form must
always be multilinear in the basis functions, but not in functions. Right?

> linear (differential) operators to the basis functions.

I was considering that propagation a part of the AD implementation.
If we write algorithms separately we'll probably duplicate several things
in different but non-orthogonal ways.

Is this monomials() approach to is_multilinear possible to generalize
to non-polynomial forms? Otherwise it's very FFC specific.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 30 Sep 2008 09:18:49 +0200

> And that no basis functions appear as arguments to nonlinear functions like exp.

Yes.

> always be multilinear in the basis functions, but not in functions. Right?

Yes.

> to non-polynomial forms? Otherwise it's very FFC specific.

Yes, maybe. Perhaps I should move that code to FFC?

I can try to implement is_multilinear (in the sense that all forms
must be multilinear, not just FFC forms) based on monomials(), remove
monomials(), and put an extended version of monomials() in FFC if it's
not something that is generally useful to have in UFL.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 30 Sep 2008 09:42:46 +0200

> Yes, maybe. Perhaps I should move that code to FFC?

It's difficult to know what we'll need both places. It's not a problem to have
algorithms in UFL that we don't use in both SFC and FFC though, as long
as the algorithms are general and don't have external dependencies.

> not something that is generally useful to have in UFL.

Add as much as you like to UFL, but please be careful about modifying
existing algorithms without asking me first, in case there's something
I'm using.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 30 Sep 2008 13:26:09 +0200

> as the algorithms are general and don't have external dependencies.

ok, I'll keep it in UFL until it becomes obvious it should be moved to
FFC. I don't plan to add any new dependencies, just one or two
functions that extract data from UFL expressions.

> existing algorithms without asking me first, in case there's something

I promise. ;-)

-- 
Anders