ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Feb 13, 2009 at 02:30:00PM +0100, Martin Sandve Alnæs wrote:
> On Fri, Feb 13, 2009 at 2:03 PM, Kristian Oelgaard
> <k.b.oelgaard@xxxxxxxxxx> wrote:
> > Quoting "Garth N. Wells" <gnw20@xxxxxxxxx>:
> >
> >>
> >>
> >> Kent Andre wrote:
> >> > On fr., 2009-02-13 at 13:32 +0100, Martin Sandve Alnæs wrote:
> >> >> On Fri, Feb 13, 2009 at 1:20 PM, Kristian Oelgaard
> >> >> <k.b.oelgaard@xxxxxxxxxx> wrote:
> >> >>> Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
> >> >>>
> >> >>>> On Fri, Feb 13, 2009 at 11:53 AM, Kristian Oelgaard
> >> >>>> <k.b.oelgaard@xxxxxxxxxx> wrote:
> >> >>>>>
> >> >>>>> Hello,
> >> >>>>>
> >> >>>>> Any thoughts on how to implement a better rule for determining the
> >> >>>> polynomial
> >> >>>>> order of a form?
> >> >>>>>
> >> >>>>> as it is now the forms:
> >> >>>>>
> >> >>>>> a = v*u*dx
> >> >>>>> a = f*v*u*dx
> >> >>>>> a = f*f*f*.....*v*u*dx
> >> >>>>> a = inner(grad(v), grad(u))*dx
> >> >>>>>
> >> >>>>> all result in the same order (2 for linear basis functions)
> >> >>>> What do we want? Add the degrees of all functions and basis functions
> >> >>>> that are multiplied? Should be possible to do.
> >> >
> >> > In general I don't think this is what you 'want' to do.
> >> > It is common to use the same quadrature rules for
> >> > a = inner(grad(v), grad(u))*dx
> >> > and
> >> > a = f*inner(grad(v), grad(u))*dx
> >> >
> >> > even though f is a function.
> >
> > Sure, but I do believe the default should be correct integration.
> > If it is possible to have different orders it might have an impact on the
> > performance of the code which will allow the default for the compilers to be
> > 'correct AND fast' code.
> > Through the meta data the user is given the opportunity of changing the rules,
> > typically decreasing the order to gain speed by sacrificing accuracy.
> >
> >> > It would however be nice to choose quadrature rule by setting some kind
> >> > of meta data.
> >> >
> >>
> >> We discussed attaching this data to the integration operators a while
> >> ago and there was general agreement.
> >
> > Yes, and it would not be a problem to override the default values if any
> > instructions are set.
> >
> > Kristian
> 
> Attaching metadata to an integral is implemented, but we
> haven't  decided what format the metadata should be in.
> 
> This currently works:
> 
> metadata = "arbitrary data"
> metadata2 = "other arbitrary data"
> 
> a = f*dx(0, metadata) + g*dx(0, metadata2) + g*dx(0, metadata)
> 
> which will result in a Form with two Integrals with integrands
> (f+g) and (g) since the first and last term has the same domain and data.

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.

Here's a suggestions:

  metadata = ("quadrature", degree)
  metadata = ("tensor", degree)

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.

-- 
Anders

Attachment: signature.asc
Description: Digital signature