Function evaluation should not need knowledge of floating point arithmetic

[August Johansson]

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.

[August Johansson]

I've changed Function::eval(Array<double>& values, const Array<double>& x) const to allow for evaluation of points within DOLFIN_EPS (according to mesh.bounding_box_tree()->compute_closest_entity(point). The unit tests pass and I think the solution solves this issue.

[Jan Blechta]

Sounds like a hack.

[August Johansson]

Yeah, it kind of is. One improvement can be to consider a more careful (relative) error tolerance.

[Anders Logg (Chalmers)]

I think this resolves the issue. I see no other way than to use a loose tolerance.