ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On Sun, Feb 15, 2009 at 10:10 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Fri, Feb 13, 2009 at 02:30:00PM +0100, Martin Sandve Alnæs wrote:
>> Attaching metadata to an integral is implemented, but we
>> haven't  decided what format the metadata should be in.
>
> I think there needs to be a convention as part of UFL for how to
> specify the integration rule. Otherwise different form compilers will
> invent different conventions and interpret the metadata differently.

Agree.

> Here's a suggestions:
>
>  metadata = ("quadrature", degree)
>  metadata = ("tensor", degree)

Here you're already into FFC territory...

Integration order is an important mathematical
property, the method for code generation is not.
"tensor" is in the latter category.

> Degree would be the degree of polynomials which will be integrated
> exactly by the quadrature rule. For tensor representation we use
> quadrature on the reference element so it makes sense there as well.
>
> It might even be useful to add a class IntegrationRule with "enums"
> for quadrature and tensor representation. Then an Integral would have
>
>  _integrand
>  _measure
>
> and Measure would have
>
>  _domain_type
>  _domain_id
>  _integration_rule
>
> and possibly metadata.

In the current implementation _integration_rule == _metadata, but it's
of course not a problem to replace that with two variables or rename it.

I think that probably any metadata other than integration order
will be form compiler specific. We can let Measure have

  _domain_type
  _domain_id
  _integration_order
  _metadata

and allow:

  dx(domain_id)
  dx(domain_id, integration_order)
  dx(domain_id, integration_order, metadata)

where metadata contains compiler hints like "tensor" and
can be form compiler specific.

Then the integration order can be interpreted correctly by
any form compiler, and metadata can be ignored.

Martin