ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Apr 19, 2009 at 03:03:44PM +0200, Martin Sandve Alnæs wrote:
> On Sun, Apr 19, 2009 at 2:48 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Sun, Apr 19, 2009 at 02:02:57PM +0200, Martin Sandve Alnæs wrote:
> >> With some renaming, we now have:
> >>
> >> extract_max_quadrature_element_degree:
> >> Returns max degree of found quadrature elements, None with no
> >> quadrature elements
> >
> > Sounds good.
> >
> >> estimate_quadrature_degree:
> >> Uses the formula 2*v.element().degree() for linear forms,
> >> v.element().degree()+u.element().degree() for bilinear forms,
> >> don't know if we need this? Returns None for functionals now.
> >> The form compilers could have an option to use this variant.
> >
> > Is it to be used as a fallback if the others fail?
> 
> No, from what I understand this is the default in e.g. Diffpack,
> and may often be sufficient? I don't know the conditions for this.
> I was thinking that we can give the choice between the two
> approaches to the user through options to the form compilers.
> 
> Kent, what do you say?

ok. That may be useful to have.

We can decide later what to name that option.

> >> estimate_max_polynomial_degree:
> >> Estimates the highest polynomial degree of the expression.
> >> It is an estimate since not all operators are polynomials.
> >
> > Does it return something sensible even if the expression is not a
> > polynomial?
> 
> Yes, the default rule for unhandled types are to return the max
> degree of the operands, so the degree of exp(f**2) will be the
> same as the degree of f**2. We could define heuristic rules like
> degree(exp(f)) -> 2*degree(f), if that makes any sense.

ok.

> > If so, then estimate_quadrature_degree may not be needed.
> >
> > It would be enough for a form compiler to do this:
> >
> >  quadrature_degree = extract_max_quadrature_element_degree(integral)
> >  if quadrature_degree is None:
> >      quadrature_degree = estimate_max_polynomial_degree(integral)
> >
> > Perhaps this should be in UFL?
> 
> As I said above, I think this should be controllable by form compiler options,
> so in that case no. Also, Kristian wants splitting of expression terms
> by polynomial degree in the future, which will be yet another way to
> handle this.

ok.

-- 
Anders

Attachment: signature.asc
Description: Digital signature