- changed component to multimesh
Function evaluation should not need knowledge of floating point arithmetic
Suppose we have the triangle with vertices (0.0, 0.0, 1.0), (1.0, 1.0, 1.0), (1.0, 0.0, 0.0). It's reasonable to assume that the user should be able to evaluation a function in the point (2./3, 1./3, 2./3) without getting an error, although this point is not exactly in the triangle due to floating point arithmetic.
Some background information: This issue was seen in the test test_manifold_dg0_functions
in the file fem/test_symbolic_geometry_assembly.py
. After updating the CollisionPredicates
to use adaptive arithmetic (this is to achieve geometric robustness), we got an error since the point is not inside the triangle.
I will investigate the use of a relaxed geometry predicate in this case.
Comments (5)
-
-
reporter I've changed
Function::eval(Array<double>& values, const Array<double>& x) const
to allow for evaluation of points within DOLFIN_EPS (according tomesh.bounding_box_tree()->compute_closest_entity(point)
. The unit tests pass and I think the solution solves this issue. -
Sounds like a hack.
-
reporter Yeah, it kind of is. One improvement can be to consider a more careful (relative) error tolerance.
-
- changed status to resolved
I think this resolves the issue. I see no other way than to use a loose tolerance.
- Log in to comment