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 > 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
