Hi Chris, In Firedrake we solve this problem by imposing an additional constraint on numbering of entities (and DoFs) such that ghost entitites (which we call halo entities) are numbered after the owned ones. This imposes a slightly suboptimal traversal order, since you are constraining RCM or SFC or whatever order you were using, but it means you can traverse owned cells and/or halo cells as contiguous blocks. (In fact we do a more complex version of this where we distinguish between owned cells which can't see the boundary and owned cells which can, but the principle is the same).
Cheers, David On 15 May 2014 14:26, Chris Richardson <[email protected]> wrote: > > Dear all, > > I am trying to integrate some changes for "ghost mesh" creation into > dolfin. > This involves adding some extra cells to the local mesh on each process, > which overlap with neighbouring processes. > > That much is fine, but in order not to break user code, I was thinking > that > the MeshEntityIterator should not by default iterate over these "ghost > cells" or their any of their associated facets, edges and vertices, > unless they are shared with other "real" cells. > > However, skipping over them without reducing memory or CPU efficiency > could be tricky. Does anyone have any ideas? Or should it just be left > up to users to sort out (i.e. just provide a way of flagging up if you > are on a ghost cell). > > Chris > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > -- Dr David Ham Departments of Mathematics and Computing Imperial College London http://www.imperial.ac.uk/people/david.ham
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
