Subject: [FFC-dev] form integration

From: Kristian Oelgaard <[email-masked]>
Date: Fri, 05 Dec 2008 17:39:23 +0100

Hi,

I stumbled over the following which seems peculiar to me:

P2 = VectorElement("Lagrange", "triangle", 2)

DG = FiniteElement("Discontinuous Lagrange", "triangle", 0)

ME = MixedElement([P2, DG])

(v, q) = TestFunctions(ME)

(u, p) = TrialFunctions(ME)

a = q*p*dx

Now, FFC insists that the degree of the above form is 4 and it will therefore
use 3x3 integration points. For tensor representation this will lead to an
increase in FFC compile time, for quadrature an increase in runtime.

Is this a bug? Or something that happens for a good reason and which is hard to
do anything about? What will UFL do?

Kristian

---

From: Anders Logg <[email-masked]>
Date: Fri, 12 Dec 2008 11:41:40 +0100

I guess it's the following code in monomialtabulation.py that causes
this:

def __compute_degree(basisfunctions):
    "Compute total degree for given monomial term."
    q = 0
    for v in basisfunctions:
        q += v.element.degree()
        for d in v.derivatives:
            q -= 1
    return q

It just looks at v.element.degree() which for a mixed element returns

def degree(self):
    "Return degree of polynomial basis"
    return max([element.degree() for element in self.__elements])

So it's a feature/bug. We would need to modify _compute_degree so that
it calls a new function v.degree() which would look at the element for
that specific component.

-- 
Anders

On Fri, Dec 05, 2008 at 05:39:23PM +0100, Kristian Oelgaard wrote:
> _______________________________________________
> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 12 Dec 2008 11:47:20 +0100

In principle UFL isn't concerned with integration method,
since this is the main difference between the form compilers.
But we need this functionality in both form compilers,
so it should be implemented properly in ufl.algorithms
at some point.

Martin

On Fri, Dec 12, 2008 at 11:41 AM, Anders Logg <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAklCP+QACgkQTuwUCDsYZdH60wCfam6M9xqYqMJygqmQ/HKHVXfw
> OQwAn2uInqEQz7Qt3/Qkk1qYc8LSPO92
> =V/Dr
> -----END PGP SIGNATURE-----
>

---

From: Kristian Oelgaard <[email-masked]>
Date: Fri, 12 Dec 2008 11:59:35 +0100

> since this is the main difference between the form compilers.

I think it would make sense if UFL would compute the degree of a monomial, and
attach it as a member. Then the compilers could just ask for this info and
generate the proper integration rule (potentially user specified)

> > it calls a new function v.degree() which would look at the element for

OK, we'll need to fix this in both monomialtabulation.py and monomialintegration.py.

Kristian

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 12 Dec 2008 12:32:05 +0100

> generate the proper integration rule (potentially user specified)

We can implement a utility function to compute it and apply it when
constructing FormData. I'll add it to the ROADMAP.

Martin

---

From: Anders Logg <[email-masked]>
Date: Fri, 12 Dec 2008 12:32:11 +0100

> generate the proper integration rule (potentially user specified)

UFL uses a different representation. I will implement an algorithm for
extracting the monomial representation (like we have now in FFC) from
the UFL representation (which is an AST - Abstract Syntax Tree with
either an operator or a terminal symbol at each node) which will be
useful to compute the tensor representation.

The quadrature code generation should work on the AST instead of the
monomial representation and I imagine it will need to first extract
all terms and then find the degree for each term. I suspect Martin
already has some nice utilities for this.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 12 Dec 2008 12:40:22 +0100

> already has some nice utilities for this.

I imagine that we can share quite a lot of code for the quadrature
code generators.
But I don't have any code for the degree computation yet.

The current status is this:
I'm currently working on getting the general compiler framework up to date,
the whole chain ufl -> sfc -> ufc -> dolfin (C++). This will hopefully work
at the end of today.

Then I'll be implementing one demo at a time, beginning with projection
and poisson, and handle remaining bugs and issues as I hit them.
When some basic forms are working, the AD stuff needs work.

Martin

---

From: Anders Logg <[email-masked]>
Date: Fri, 12 Dec 2008 13:04:31 +0100

> the whole chain ufl -> sfc -> ufc -> dolfin (C++). This will hopefully work

Very nice.

We have some catching up to do for FFC. Hopefully we'll find some time
for this once the new DOLFIN release is ready.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 12 Dec 2008 13:28:02 +0100

> for this once the new DOLFIN release is ready.

That's ok. There are some central issues I/we need to work out,
that may still lead to redesign of some parts, so it's a good thing
we don't have too much code depending on ufl yet.

Martin