A cell owning a tree is a very strange concept. What about introducing a point cloud over a mesh with an optional reusable tree:
mesh = ... tree = BBTree(mesh) pc = PointCloud(mesh, tree) # tree is optional, can be created internally ids = [pc.add(x) for x in pointlist] values = f.eval(pc) Users can deal with manual creation of the tree to speed up cases with multiple point clouds or just use a single point cloud which handles creation of a non-shared tree internally. The problem with mutable MeshGeometry is not solved by moving the tree outside of Mesh though. Introducing versioning to Mesh (just an int incremented on changes) could allow automatic rebuilding of the tree on demand. The PointCloud class can be introduced to ufl as well for use in point integrals: L = f*dP(domain=pc) Martin 23. jun. 2015 10.43 skrev "Anders Logg" <[email protected]>: > How about something like this: > > 1. Require additional Cell& cell argument to Function::eval > > 2. Add new class AutoCell handling this for users who don't want to > explicitly work with a BoundingBoxTree > > class AutoCell : public Cell > { > public: > AutoCell(Mesh &mesh); > BoundingBoxTree tree; > } > > AutoCell cell(mesh); > function.eval(values, x, cell); > > 3. If the mesh moves, a user can do something like: > > cell.invalidate() > > -- > Anders > > > > tis 23 juni 2015 kl 10:30 skrev Garth N. Wells <[email protected]>: > >> 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 >> > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
