Subject: [UFL-dev] [HG UFL] Improvements to form2ufl script

From: [email-masked] (UFL)
Date: Sun, 15 Mar 2009 19:56:16 +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:   739:ace55a2c179c2335fccb620f1c4db1bc5a0f3153
tag:         tip
user:        Anders Logg <[email-masked]>
date:        Sun Mar 15 19:56:10 2009 +0100
files:       scripts/form2ufl
description:
Improvements to form2ufl script

changeset:   738:1724515cccffa1d6e03b0e25d8ccd35b42258f58
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Sat Mar 14 17:16:30 2009 +0100
files:       sandbox/pylintlog/cleanlogs.py
description:
missing file

changeset:   737:9582176cf2552468f06a8e337a5d677ee7cab559
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Sat Mar 14 17:16:14 2009 +0100
files:       ROADMAP sandbox/pylintlog/runpylint.sh sandbox/scripts/summarizetodos.py ufl/__init__.py ufl/algorithms/formfiles.py ufl/elements.py ufl/finiteelement.py
description:
Improvement to pylint tools.

Partially implemented ElementUnion class.

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

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 17 Mar 2009 10:39:10 +0100

> Improvements to form2ufl script

There's a bug when translating PoissonDG.form, look at the last *ds term.

Kristian

> user:        "Martin Sandve AlnÃ¦s <[email-masked]>"
> user:        "Martin Sandve AlnÃ¦s <[email-masked]>"
> files:       ROADMAP sandbox/pylintlog/runpylint.sh
> sandbox/scripts/summarizetodos.py ufl/__init__.py ufl/algorithms/formfiles.py
> ufl/elements.py ufl/finiteelement.py
> description:

---

From: Anders Logg <[email-masked]>
Date: Tue, 17 Mar 2009 21:01:42 +0100

> There's a bug when translating PoissonDG.form, look at the last *ds term.

Fixed. I've regenerated all .ufl files now except for TensorWeightedPoisson
which can't be handled by the script.

It would be good if we could keep the .ufl files untouched from now on
until at least the next release (so they are as close as possible to
the old .form files and generated using form2ufl). If you want, you
can add some more examples that set options like "quadrature_order".

-- 
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 17 Mar 2009 21:05:22 +0100

> which can't be handled by the script.

OK.

> can add some more examples that set options like "quadrature_order".

The reason that I've changed the *.ufl forms (added the quadrature_order) is
that otherwise the results does not agree, which I think is just as important
if you talk about a foo.form and foo.ufl form being equal.

Kristian

---

From: Anders Logg <[email-masked]>
Date: Tue, 17 Mar 2009 21:09:40 +0100

> if you talk about a foo.form and foo.ufl form being equal.

But isn't that a good thing? It indicates that we have not yet figured
out the correct quadrature order to use automatically.

-- 
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 17 Mar 2009 21:14:07 +0100

> out the correct quadrature order to use automatically.

That is one way of looking at it, but it makes it difficult to see if the rest
of the generated code is correct. It's no big deal though, I just add the order
for the forms that I test without checking the changes in.

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 17 Mar 2009 21:29:06 +0100

> for the forms that I test without checking the changes in.

To really solve this issue, I need to understand what sufficient
quadrature order _is_.

1) Can the discrete operator assembled from a bilinear form be
approximated using quadrature order v.degree() + u.degree()?
This seems to be common, but I don't understand why it is ok.

2) Obviously, using v.degree() is not sufficient for linear forms,
it even fails for f*v*dx. So using v.degree() + f.degree() in this
case seems like the only right thing to do. This can be generalized
to sum the degrees of form arguments in each product.

3) But for forms like "exp(f**2)*v*dx", there's no way we can
decide a sufficient quadrature order, so what do we fall
back to? Should the rhs use the same order as the lhs?
Or will simply 2*v.degree() be fine? The user should probably
be careful in a case like this anyway.

Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 17 Mar 2009 22:47:43 +0100

> be careful in a case like this anyway.

I think the form compilers should try to integrate the given forms
exactly and otherwise default to some sensible value.

So I'd suggest

  v.degree() + f.degree() - {num derivatives on v and f}

For cases like exp(f**2)*v*dx, I think it's reasonable to default to
2*v.degree().

We could also have an option for using quadrature order v.degree()
which I think should retain the correct order of convergence in most
cases, but that is more of a form compiler option than a language
option.

-- 
Anders