ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 16, 2009 at 11:48:02AM +0100, Kristian Oelgaard 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.

I also think this looks good.

-- 
Anders



> 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
> > 
> 
> 
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev

Attachment: signature.asc
Description: Digital signature