On Fri, Jan 22, 2010 at 09:35:23AM +0100, Kristian Oelgaard wrote:
2010/1/22 Anders Logg <logg@xxxxxxxxx>:
>On Thu, Jan 21, 2010 at 11:26:47PM +0100, Anders Logg wrote:
>>The MetaData.ufl example is failing in the quadrature representation.
>>
>>Kristian, could you have a look and see what goes wrong. Then I can
>>continue to make the incremental/combined integral stuff work.
>
>On second thought, maybe we should skip the whole thing with having
>different representations inside the same tabulate_tensor function
>for the following reasons:
>
>1. It leads to complications in the code generation.
Very true.
>2. It probably doesn't make much difference since if quadrature is
>required for one part of an integral, then it is likely the cost is
>low for including the other terms inside the existing quadrature loop.
True.
>3. The situation will not arise often since UFL will anyway group
>terms with the same dx inside the same integral and then all will have
>the same representation.
I'm not sure this is correct, if the metadata is different the integrals will not be grouped.
That's correct. So it has an effect when someone explicitly wants to
treat a term with a specific representation, but not when FFC tries to
auto-select the representation for each term since then all the terms
will have metadata "auto" and be grouped together.
I still think we have a strong case for a simplification. Agree?
>So the cases where this is useful are rare (because of the UFL
>grouping), it won't give any speedup and it's complicated to
>implement...
>
>We will still have the possibility of different representations for
>integrals on different subdomains and for cell, interior and exterior
>facet integrals.
Yes, and this is probably the case where one will use it the most anyway.
>If this sounds ok, I can add some checks in analysis.py that force all
>UFL integrals that will be grouped as part of the same UFC integral to
>use the same representation.
Yes, such that if any quadrature is present they will all be quadrature.
>Btw, does quadrature handle different quadrature degree for different
>integrals that become part of the same tabulate_tensor? If not, we can
>force metadata to be the same for all integrals that belong together.
I don't know how the meta data is set up now, but it used to be able to do:
a = v*u*dx + inner(grad(v), grad(u))*dx -->
loop ip range(4):
....
loop ip range(9):
....
Inside one tabulate_tensor() funtion.
ok, if there are no objections, I can have a go at adding some checks
for having the same metadata in all terms UFL integrals that
correspond to the same UFC integral (same domain type and domain number).
