- removed milestone
Expression is evaluated at interior points even if it occurs as boundary integral only
An expression which is part of a boundary integral in a form gets unnecessarily evaluated at interior mesh points when assembling. This is problematic as the Expression may be very expensive to evaluate or may not be even defined at these points.
Also note that the form must contain at least one volume part for this problem to occur.
Following code demonstrates the problem:
from dolfin import *
mesh = UnitIntervalMesh(10)
V = FunctionSpace(mesh, "CG", 1)
class ExpensiveExpression(Expression):
def eval(self, value, x):
print "Evaluating an expensive expression at x = %f." % x
value[0] = 1
f0 = ExpensiveExpression()
f = interpolate(Constant(1), V)
dx = dx(domain=mesh)
ds = ds(domain=mesh)
form = f * dx + f0 * ds
assemble(form)
Comments (10)
-
-
The 'fix' for this is a long-planned feature of defining function spaces on subdomains, including on subdomains of different topological dimension.
An
Expression
that is only defined on boundary would fix the reported issue. -
This has also been reported and commented on at http://fenicsproject.org/qa/1033/dirichletbc-expressions-evaluated-away-from-the-boundary.
-
reporter Thanks Garth.
Nico, I think this here is a different issue: Your linked question reports that the application of a
DirichletBC
evaluates anExpression
at dofs on or adjacent to the boundary. However, here theExpression
occurs in a boundary integral of a variational form and is evaluated at all interior nodes. -
The reason for this is that all coefficients of a form are treated equally. So for each integral all coefficients are restricted to the integration cell even if they are not present in the integral. For this to be fixed we need to store coefficients per integral and generate code accordingly.
-
Issue
#360was marked as a duplicate of this issue. -
- changed milestone to 1.7
-
- edited description
(updated code to work with fenics dev)
-
- removed milestone
Removing milestone: 1.7 (automated comment)
-
Issue
#867was marked as a duplicate of this issue. - Log in to comment