ffc team mailing list archive

[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.

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

Attachment: signature.asc
Description: Digital signature