ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxx>]

2010/1/24 Anders Logg <logg@xxxxxxxxx>:
> On Sun, Jan 24, 2010 at 08:10:17PM +0100, Kristian Oelgaard wrote:
> > 2010/1/24 Anders Logg <logg@xxxxxxxxx>:
> > >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...
> >
> > Well it has not really been fully operational anyway so the damage is not that big.
>
> Good!
>
> > >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).
> >
> > 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.
>
> > >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),
> > >  ...]
> >
> > 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.

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

> 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.
>
> > >We then iterate over all integral tuples in representation.py and call
> > >the appropriate backend depending on metadata["representation"].
> >
> > Why didn't we always do it this way, it's so simple.
>
> Agree, but it takes some time to figure out.
>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktcn6QACgkQTuwUCDsYZdH3iwCfZG3nstkpwXjsM2AW6xGXv/JK
> mK8An2IiNT/YQyB8DGJc2fc5yKvZjWPG
> =OM90
> -----END PGP SIGNATURE-----

Attachment: signature.asc
Description: OpenPGP digital signature