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:48 AM, Kristian Oelgaard
> <k.b.oelgaard@xxxxxxxxxx> wrote:
> > 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?
> 
> UFL doesn't need to know anything about compiler options,
> not even which compilers exist.

True, I misread the
'dict(integration_order=3, ffc=ffc_options, sfc=sfc_options)'
as a call with named arguments.

Kristian

> Form compilers should just do this for a given integral:
> 
> m = integral.metadata()
> 
> # Get UFL-defined options
> integration_order = m.get("integration_order")
> ...
> 
> # Get my own options
> ffc_options = m.get("ffc", {})
> 
> Or iterate over what's given:
> 
> for k,v in m:
>     if k == "ffc": ...
>     elif k == "integration_order": ...
>     else: warning("Unrecognized option %s" % k)
> 
> 
> Martin
> 
> 
> >> > 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
> >>
> >
> >
> >
>