Make quadrature scheme and degree a native property of Measure and Integral

[Martin Sandve Alnæs]

M = f*dx(degree=5, scheme="default")

instead of

M = f*dx(metadata={"quadrature_degree": 3, "quadrature_scheme": "default"})

Apart from the obvious usability side of this feature, it will allow a refactoring of code in the form class, form preprocessing and ffc intermediate representations that sorts and groups integrals back and forth in various representations that are at times hard to follow, into one representation that suits all purposes I can see at least.

[Martin Sandve Alnæs]

Maybe we can agree on some named automatic degree choices as well.

"spaces" - get by adding test/trial spaces for bilinear form; 2*test space for linear form (for consistency with bilinear form)

"exact" - exact integration for polynomial expressions (no pointwise expressions allowed); fail if exact is not possible to determine

"moderate" - exact if possible; create a moderate degree estimate otherwise

"high" - exact if possible; create a very high degree estimate otherwise

"auto" - default; like "spaces" for non-functionals; something else for functionals (e.g. "moderate")

I don't like "low" because it would have to be higher than "spaces" to make any sense, or maybe it makes sense for functionals.

[Jan Blechta]

and what about "low" - very low degree estimate which is employed today?

[Martin Sandve Alnæs]

What's employed today is not a "very low degree estimate", for complicated equations we quickly get ridiculously high degrees. I guess you're talking about the automatic degree choice for Expression, however that is a distinct operation from the estimation of the integration degree, and we want to remove automatic degree choice for Expression.

[Prof Garth Wells]

For the auto degree, I like 'spaces' and 'exact' (need to think of a better name for the former). I'm not keen on the others. To smooth a transition, we could add something that replicates what we do at the moment, and deprecate it immediately.

[Martin Sandve Alnæs]

Fine by me, force the user to be aware of how accurate the functionals are integrated with f*dx(degree=3).

We could have:

"spaces", "exact", "auto"="spaces"|"exact"

"legacy" - as close as possible to what we do today.

Initial default: "legacy" - with deprecation warning (triggers for all forms).

Next version default: the new "auto". Keep "legacy" as an option to allow replication of previous results.

Some future version: Remove "legacy".

[Kristian Ølgaard]

@martinal, just to be clear. When you say 'remove automatic degree choice for Expression', do you mean for the pointwise case, i.e., not if the user has supplied a finite element (that has a degree)?

[Martin Sandve Alnæs]

Kristian: yes, when the user supplies an element there is no automatic degree choice (because that element has a degree).

[Martin Sandve Alnæs]

Btw Kristian, you should change your bitbucket name like Garth has done to use - instead of ., because the @ name notation becomes just @ k...

[Kristian Ølgaard]

Done.

[Martin Sandve Alnæs]

What about "operator" instead of "spaces"?

a = f*u*v*dx(degree="operator")  #  use u.degree() + v.degree()
L = g*v*dx(degree="operator")  # use 2*v.degree(), assumed consistent with operator 'a'

[Martin Sandve Alnæs]

I've added 'degree' and 'rule' as arguments to dx() in ufl (in next), for now just inserting them into metadata["quadrature_degree"] and metadata["quadrature_rule"] which ffc sees as usual.

Feel free to start using this notation with explicit integer degrees: f*dx(degree=3).

Later we can add the string options discussed above and see if we can make the actual degree used accessible to the user.