Estimator of polynomial degree fails silently when visiting types it does not support

Issue #4 resolved
Jan Blechta created an issue

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)

  1. Jan Blechta reporter

    Also estimates for div(u) and nabla_grad(u) seems to be incorrect also for ordinary, non-mixed function u.

  2. Martin Sandve Alnæs

    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.

  3. Jan Blechta reporter

    OK but div, nabla_grad, dot and inner are estimated incorrectly even for one-component function. Should I report it as a a separate issue?

  4. Martin Sandve Alnæs

    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.

  5. Martin Sandve Alnæs

    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.

  6. Martin Sandve Alnæs

    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>>

  7. Martin Sandve Alnæs

    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>>

  8. Log in to comment