Estimator of polynomial degree fails silently when visiting types it does not support
Compound UFL operators like div
, nabla_grad
, inner
and dot
are not handled correctly:
from dolfin import *
from ufl.algorithms import estimate_total_polynomial_degree as est
mesh = UnitSquareMesh(42, 42)
P2 = FunctionSpace(mesh, 'CG', 2)
V2 = VectorFunctionSpace(mesh, 'CG', 2)
u = Function(P2)
print est(grad(u)) # OK
print est(nabla_grad(u)), est(div(u)) # wrong - returns 2, 2
print est(dot(grad(u), grad(u))), est(inner(grad(u), grad(u))) # wrong - returns 1, 1
u = Function(V2)
print est(dot(u, u)), est(inner(u, u)) # wrong - returns 2, 2
print est(dot(grad(u), grad(u))), est(inner(grad(u), grad(u))) # wrong - returns 1, 1
Comments (15)
-
reporter -
reporter Also estimates for
div(u)
andnabla_grad(u)
seems to be incorrect also for ordinary, non-mixed functionu
. -
reporter Also estimation of
dot
andinner
seems to be wrong. -
I think there's a blueprint on component wise degree estimation on launchpad. Basically tensor values are treated as having the max degree of the components now, which causes the problem you see.
-
reporter OK but
div
,nabla_grad
,dot
andinner
are estimated incorrectly even for one-component function. Should I report it as a a separate issue? -
No need to do that, can you provide an example?
-
reporter - changed title to Estimator of polynomial degree has plenty of bugs
- edited description
Martin, I updated description of the issue with these examples.
-
Issue text from launchpad:
The degree estimation algorithm can be improved by looking at the degrees of components of functions instead of the max degrees.
See fixmes in and calls to degree() in estimate_degrees.py.
-
- marked as critical
-
-
assigned issue to
-
assigned issue to
-
Jan Blechta: What made you report the dot/inner/div behaviour as a bug? Now that I look at it more closely, the reason that several operators are not handled correctly is that they are simply assumed not to be present, because this algorithm should be used after form preprocessing. During this preprocessing, derivatives are computed and there are not nabla_grad, div, dot, inner objects left in the expression. If this algorithm is applied prior to preprocessing, that is the real bug. I'll add a comment and some assertions to "fix" this.
-
- changed status to resolved
Fix issue 4, estimating degrees better.
Note that, although we now handle a larger class of expressions, preprocessing must still be applied prior to calling the degree estimation algorithm for correct result in a generic case. Algorithm should now fail with a clear message if unsupported types are present in the expression.
Also removed the unused and somewhat strange estimate_max_polynomial_degree.
→ <<cset 4dfffce7b830>>
-
- changed title to Estimator of polynomial degree fails silently when visiting types it does not support
- marked as minor
- edited description
-
Fix issue 4, estimating degrees better.
Note that, although we now handle a larger class of expressions, preprocessing must still be applied prior to calling the degree estimation algorithm for correct result in a generic case. Algorithm should now fail with a clear message if unsupported types are present in the expression.
Also removed the unused and somewhat strange estimate_max_polynomial_degree.
→ <<cset a6c4be1107b4>>
-
reporter Nice!
- Log in to comment