Subject: [UFL-dev] [HG UFL] Initial attempt at implementing index renumbering. Needed to disable

From: [email-masked] (UFL)
Date: Sun, 22 Feb 2009 22:03:04 +0100 (CET)

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

changeset:   614:f611ca1ec5d993fd6a11161b43401159d7de7074
tag:         tip
user:        Anders Logg <[email-masked]>
date:        Sun Feb 22 22:02:58 2009 +0100
files:       ufl/algorithms/monomials.py ufl/algorithms/renumbering.py ufl/common.py ufl/indexing.py
description:
Initial attempt at implementing index renumbering. Needed to disable
optimization in Index class (caching of signature) since signature
(count) will change. Wasn't able to remove caching for __repr__

changeset:   613:d364f36297c30499ba0125b0f1f638f732945dd2
user:        Anders Logg <[email-masked]>
date:        Sat Feb 21 21:29:10 2009 +0100
files:       ufl/algorithms/ufl2latex.py
description:
Bug fix in ufl2latex

changeset:   612:8dece32161935470465c9e48ff2c47d07f0e5a56
user:        Anders Logg <[email-masked]>
date:        Sat Feb 21 21:25:58 2009 +0100
files:       ufl/algorithms/monomials.py
description:
Handle component indices in monomial transformation

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

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Sun, 22 Feb 2009 22:10:31 +0100

You should never ever modify UFL objects, always create new ones.
What you're doing here can mess up all other forms in the application.

Martin

On Sun, Feb 22, 2009 at 10:03 PM, UFL <[email-masked]> wrote:
> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev
>

---

From: Anders Logg <[email-masked]>
Date: Sun, 22 Feb 2009 22:12:23 +0100

ok, will fix.

-- 
Anders

---

From: Anders Logg <[email-masked]>
Date: Sun, 22 Feb 2009 22:56:31 +0100

> ok, will fix.

I made an attempt to fix this. See if it looks better. I've also
removed the set_count() function.

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 23 Feb 2009 11:51:42 +0100

Looks ok, but I simplified it further.

Note that we might need a more sofisticated renumbering
later, to discover that e.g. u[i]*v[i] and u[j]*v[j] are the
same expression, for fast optimization of quadrature code.

Also, I moved the argument renumbering to FormData,
take a look at it. I've removed the "classes" and
"*_renumbering" members of FormData. We should
go through the FormData structure soon to finalize
it as well as we can.

I've confusingly used the term "coefficient" in e.g.
FormData, I guess we should stick to "function" in UFL.
Agreed?

Also, we should always write "basis_function" instead of "basisfunction"?

Martin

On Sun, Feb 22, 2009 at 10:56 PM, Anders Logg <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmhyg8ACgkQTuwUCDsYZdF8lACgkWyjq3y+bHdfBGXJnHKztv2a
> ycUAnApKmw5493PWMwLm25ciP4GbBvoz
> =4AeI
> -----END PGP SIGNATURE-----
>

---

From: Anders Logg <[email-masked]>
Date: Mon, 23 Feb 2009 12:36:42 +0100

> Looks ok, but I simplified it further.

Looks nice and simple.

> same expression, for fast optimization of quadrature code.

ok

> go through the FormData structure soon to finalize

I wasn't aware that FormData already did some renumbering. What does
it renumber and how does it relate to renumber_indices?

> FormData, I guess we should stick to "function" in UFL.

Agree, but there will be a coefficient thing in the monomial
representation where functions are expanded to

  f = f_i v_i

> Also, we should always write "basis_function" instead of "basisfunction"?

ok

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 23 Feb 2009 14:05:00 +0100

> it renumber and how does it relate to renumber_indices?

It didn't renumber anything, what I removed was a numbering mapping,
mapping each function to its place in the form in [0,n).
But now it renumbers the form arguments (not the indices).
It has to apply expand_derivatives before this, since
this can result in changes in the argument list.
(I don't really like this, see the FIXME comment in formdata.py).
The current implementation of expand_derivatives calls expand_compounds.

If you make a formdata:

  fd = FormData(a)

You get e.g. a list of functions:

  fd.coefficients

which have counts in [0,n),
and can get the original argument (e.g. the PyDOLFIN Function)
from the dict original_arguments:

  for f in fd.coefficients:
      original_f = fd.original_arguments[f]

> representation where functions are expanded to

Do you need to represent this sum explicitly?
Some extension to UFL will be needed to do that.

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 23 Feb 2009 14:10:38 +0100

>       original_f = fd.original_arguments[f]

ok.

> Some extension to UFL will be needed to do that.

No, implicitly via indices.

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 23 Feb 2009 16:52:32 +0100

> No, implicitly via indices.

What do you mean? Using actual indices to represent this sounds like a
rather explicit representation :)

But I guess you're keeping your own data structure for this, so I
don't need to care?

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 23 Feb 2009 17:06:12 +0100

> rather explicit representation :)

Yes, it will be a very explicit sum of products of basis functions.

> But I guess you're keeping your own data structure for this, so I

Yes.

-- 
Anders