Subject: [Ffc] New handling of integrals

From: Anders Logg <[email-masked]>
Date: Sun, 24 Jan 2010 00:12:37 +0100

I have pushed a changeset that simplifies the handling of integrals of
different types and domains. This unfortunately breaks the quadrature
but the changes should lead to large simplifications. I hope you're up
for it Kristian...

For the tensor representation, I was able to remove large portions of
code for extracting integrals of various types (domain_type) and on
different sub domains (domain_id).

This now happens in UFL and form_data has a new member called
integral_data, that just lists all the data associated with different
(UFC) integrals:

  [(domain_type, domain_id, integrals, metadata),
   (domain_type, domain_id, integrals, metadata),
   ...]

We then iterate over all integral tuples in representation.py and call
the appropriate backend depending on metadata["representation"].

I have also updated analysis.py so that it makes sure metadata is
common for all UFL integrals that should go into the same UFC
integral.

Let me know if you have any questions on the new format.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Sun, 24 Jan 2010 14:02:32 +0100

> but the changes should lead to large simplifications. I hope you're up

Tensor is broken too. Try MixedPoisson.   

--
Marie

> ------------------------------------------------------------------------
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Anders Logg <[email-masked]>
Date: Sun, 24 Jan 2010 14:34:10 +0100

> Tensor is broken too. Try MixedPoisson.

Not unexpected. Will fix later.

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Sun, 24 Jan 2010 20:10:17 +0100 (CET)

> but the changes should lead to large simplifications. I hope you're up

Well it has not really been fully operational anyway so the damage is not that big.

> different sub domains (domain_id).

I had a quick look and I'm very impressed. 100 lines of code in tensorrepresentation!!

>   (domain_type, domain_id, integrals, metadata),

I only had a very quick look in the code in UFL, my only concern would be if UFL is becoming too FFC aware? From what I've seen though it still looks OK.

> the appropriate backend depending on metadata["representation"].

Why didn't we always do it this way, it's so simple.

Kristian

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktbgmUACgkQTuwUCDsYZdFRywCfaoa8x/uhT9u69CW8eEt7k6Z4
> 2rwAn12j6idxDqk84v2/huiXQEoa5OL6
> =QOII
> -----END PGP SIGNATURE-----
>

---

From: Anders Logg <[email-masked]>
Date: Sun, 24 Jan 2010 20:29:40 +0100

> Well it has not really been fully operational anyway so the damage is not that big.

Good!

> I had a quick look and I'm very impressed. 100 lines of code in tensorrepresentation!!

There's quite a bit of stuff still going on in other modules but the
reduction in code was big.

> I only had a very quick look in the code in UFL, my only concern
> would be if UFL is becoming too FFC aware? From what I've seen
> though it still looks OK.

I don't think that's the case. The new integral_data does the natural
thing which is to group integrals by their domain_type and domain_id
which is what needs to come out at the other end (UFC) so one could
say that it is UFC-specific.

The only FFC-specific thing could be that we allow metadata to be
added to each such group and we use that for representation but that
can be ignored by other compilers.

> Why didn't we always do it this way, it's so simple.

Agree, but it takes some time to figure out.

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Sun, 24 Jan 2010 20:58:10 +0100 (CET)

> say that it is UFC-specific.

Agree. One question here is how we can let the form:

a = inner(grad(v), grad(u))*dx + v*u*dx

be represented by two quadrature loops since there will only be one metadata for the sum and 'quadrature_degree' will be equal to that of the v*u*dx term, although the first term could use a lower order quadrature scheme. Do you group the integrals into a new integral (form) based on the metadata? Perhaps it will be enough to simply store the two integrals in a list.

Kristian

> iEYEARECAAYFAktcn6QACgkQTuwUCDsYZdH3iwCfZG3nstkpwXjsM2AW6xGXv/JK
> mK8An2IiNT/YQyB8DGJc2fc5yKvZjWPG
> =OM90

---

From: Anders Logg <[email-masked]>
Date: Sun, 24 Jan 2010 21:09:01 +0100

> be represented by two quadrature loops since there will only be one metadata for the sum and 'quadrature_degree' will be equal to that of the v*u*dx term, although the first term could use a lower…

The input you get to compute_integral_ir contains the variable named

  integrals

This is a list of all the integrals that should be summed inside the
UFC integral specified by (domain_type, domain_id).

The metadata variable you get contains the common metadata for all the
integrals, but each integral in that list should still have its own
individual metadata if you need it.

For the tensor representation, I just use the common quadrature
degree.

--
Anders