On Thu, 15 May, 2014 at 2:43 PM, David Ham <[email protected]>
wrote:
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.
Yes, this is the natural thing to do. DOLFIN already does this for dofs
(this will be more apparent in the upcoming switch to local dof
indexing).
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).
I wouldn't expect this sub-optimal ordering to have a noticeable impact
on performance.
Garth
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
