ufl team mailing list archive

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

On Mon, Feb 16, 2009 at 11:09 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> Kristian Oelgaard wrote:
>> Quoting "Garth N. Wells" <gnw20@xxxxxxxxx>:
>>
>>>
>>> Anders Logg wrote:
>>>> On Mon, Feb 16, 2009 at 09:57:26AM +0100, Martin Sandve Alnæs wrote:
>>>>> 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.
>>>> Hints for the degree of the quadrature is also form compiler
>>>> specific. There may be other ways to evaluate the integral than
>>>> quadrature, for example by random sampling, symbolic integration (like
>>>> in SyFi) or using a tensor representation (FFC).
>>>>
>>> Tensor representation still uses quadrature, it's just that it's
>>> performed a priori rather than at runtime.
>>
>> I guess the degree is just the highest polynomial order that the user wishes
>> integrated exactly.
>> If it is possible for the form compiler to comply with this wish it may do so,
>> if not it will ignore the instruction.
>> On second thought, I think we do need 'quadrature', 'tensor' to be allowed in
>> the metadata, otherwise the user can't specify different representations on
>> different subdomains.

That's why I used the term "integration order" and not "quadrature order".
Basically, by this the user will ask the form compiler to use an integration
method that guarantees a certain order.

I'm fine with lumping this in with other metadata, but I think at least how to
specify the integration order should be standardized. I don't know how many
other options we can standardize, but we can define a format for it:

metadata = {
    # ... The meaning of some parameters is defined by UFL:
    "integration_order": None,
    # ... Other packages use their name to wrap specific options:
    "ffc": ffc_options,
    "sfc": sfc_options,
}

So you can do e.g.
    ffc_options = dict(representation="quadrature")
    sfc_options = dict(integration_method="quadrature")
    metadata = dict(integration_order=3, ffc=ffc_options, sfc=sfc_options)
    a = v*u*dx(0, metadata) + f*v*dx(0)

At any point we can add new standardized options.
I don't see any value in letting representation/integration_method
be a standard parameter, since the values it can take
will be different for each compiler anyway.

> Perhaps this information should belong to the form rather than the integral?
>
>     a_tensor = . . .
>     a_quad   = . . .
>     a = a_tensor + a_quad
>
> Garth

As Kristian said, sometimes different integrals or integral terms has
different optimal compiler options, so attaching options to integrals
is a good feature to have.

Form-global compiler options doesn't have to be attached to UFL objects,
isn't it better to pass them to the form compiler jit function directly?

Martin