On Thu, 25 Jun 2015 17:59:46 +0200 Marco Morandini <[email protected]> wrote:
> On 06/23/2015 04:31 PM, Martin Sandve Alnæs wrote: > > Both assemble and interpolate have loops over all cells in the mesh, > > so at least for single-mesh situations the cell will be known. > > > > Looking at this from another angle: > > what exactly is the problem with a Mesh owning its related BBTree? > > Is it only a matter of making updates safe or is there something > > else? If we get rid of unsafe ways to modify the Mesh (e.g. > > MeshGeometry::x()), and add safe ways to modify the Mesh that mark > > the BBTree as invalidated, does that make all issues go away? > > > > To better understand the issue I tried to write some code. > > 1) First option: invalidate Mesh:bonding_box_tree whenever the mesh > coordinates are accessed with a non-const method > > https://bitbucket.org/MarcoMorandini/morandini-dolfin/branch/morandini/invalidate-bbox > > I don't know if the implementation is correct (i.e. if I'm > invalidating it when and only when it is needed), but at first glance > seems a small change, it passes all the python unit tests, and it > appears to fix the testcase of > > https://bitbucket.org/fenics-project/dolfin/issue/89 > > modified to run on current master (attached). I think you're missing an invalidation for "MeshGeometry& Mesh::geometry()". Problem is that Python wrappers cannot distinguish between MeshGeometry& Mesh::geometry() const MeshGeometry& Mesh::geometry() Natural solution seems to be: 1. moving tree to MeshGeometry class 2. ignoring in SWIG everything which with const and non-const version 3. handling const-correctness by writing __set__ and __get__ methods properly Johan, any comment here? Jan > > > 2) Second option: actually remove Mesh:bonding_box_tree. > As pointed out by Logg, this is a more complex task: > > https://bitbucket.org/MarcoMorandini/morandini-dolfin/branch/morandini/remove-bbox > > The work in not finished, and right now it does not pass all the > python unit tests. > > Just like Garth, I would prefer the solution 2), but I'm starting > to change my mind. > > Anyway. > Feel free to comment and/or drop everything. > > Marco > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
