On 23/06/2015 09:30, Garth N. Wells wrote:
On 22 June 2015 at 18:00, Anders Logg <[email protected]> wrote:
The challenge in moving the bounding box tree outside of the mesh is
that it
has always been part of the mesh (it replaced an earlier data
structure that
was there) so a user expects to be able to do
v = Function(V)
print v(x)
This is fine for Expressions, but for a Function I don't think it's
bad for the interface to make obvious to the user that they are
performing a potentially expensive operation. If the user was required
to pass the cell, all would be fine. It would also fix the issues with
Function evaluations in parallel.
without needing to instantiate some cryptic BoundingBoxTree data
structure.
Furthermore, a user expects that on subsequent calls v(x) is fast
since the
tree has already been built.
I don't see a way around automatic handling of building the search
tree. Are
there some clever suggestions?
We have a fundamental problem/flaw that MeshGeometery is mutable and a
Mesh owns a bounding box object. One of the two needs to give.
Garth
I would vote for removing direct access to MeshGeometry data, and only
allowing
it to be moved by a method, e.g. MeshGeometry::update(std::size_t i,
Point p);
Chris
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
