ufl team mailing list archive

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

Quoting 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 totally agree.
 
> 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.

This looks like a very good solution, any form compiler just needs to get the
relevant options dictionary and disregard all others.
The options supported in these dictionaries should then be described in the
relevant compiler manual. Using this approach UFL doesn't have to know anything
about compiler options, apart from which compilers define these options?
 
> > 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?

Agree.

Kristian
 
> Martin
>