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) 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? Handling this for PointSource and MultiMesh is unproblematic. (But for MultiMesh, I would rather want to move it myself.) -- Anders mån 22 juni 2015 kl 17:54 skrev Marco Morandini <[email protected]>: > >>> Besides, the mesh bounding_box_tree used to find the colliding mesh > >>> entity is cached. I fear this could be a source of "strange" > >>> results, because its use is here completely transparent to the > >>> user, who may be unaware of the need to update it. > >>> > >> > >> I really don't like magical caching. How about having > >> > >> PointSource::apply(GenericVector& b, Cell& c, double magnitude); > >> > >> The user is responsible for finding the cell, and thereby also > >> responsible for handling meshes that move, etc. > >> > >> PointSource::apply(...) presently uses Mesh::bounding_box_tree(), > >> which I would like to get rid of from Mesh since mesh geometry is > >> mutable. If the search tools are not cached, the user takes > >> responsibility for managing the bounding boxes. > > > > For the record, this issue is filed as > > https://bitbucket.org/fenics-project/dolfin/issue/89 > > > > Right now Mesh::bounding_box_tree() is used by > > void PointSource::apply(GenericVector& b) > void Function::eval(Array<double>& values, const Array<double>& x) const > > and > > MultiMesh ( + MultiMeshDirichletBC ) > > It would be pretty easy to change PointSource and Function. > But I think that, for MultiMesh, I should move the bboxes there, and > leave MultiMesh::build() unchanged. > > I can go this route if there is consensus. > > Marco > > > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
