itaps-parallel deletion of ghost entities

Jason Kraftcheck kraftche at cae.wisc.edu
Tue Nov 4 12:42:37 CST 2008


Devine, Karen D wrote:

> You're right; the documentation isn't quite clear.  iMeshP_createGhostEnts
> should create ghosts right away -- it should do the communication when it is
> called.  But it also has to store the ghosting rules so that, if
> repartitioning or mesh modification of an existing mesh with ghosting
> occurs, the ghosts can be re-established after the repartitioning or mesh
> modification.  Re-establishing the ghosts in this second case is done by the
> end of iMeshP_syncMeshAll or iMeshP_syncPartitionAll; it can be done
> incrementally as, say, the mesh modification is done, but we guarantee only
> that ghosting is re-established by the end of the sync functions.

It isn't just that the documentation is unclear.  I think the API would be
better (simpler, easier to understand and use, etc.) if
iMeshP_createGhostEnts (and similarly iMeshP_deleteGhostEnts) only did one
of these two operations: either a) add a rule *or* b) communicate ghost
entities.

For a)
 o remove the implicit calls to iMeshP_syncMeshAll that every implementation
   will need to have at the end of iMeshP_createGhostEnts and
   iMeshP_deleteGhostEnts.
 o iMeshP_createGhostEnts and iMeshP_deleteGhostEnts do no communiction
 o Application must call iMeshP_syncMeshAll to communicate ghost entites.

For b)
 o remove iMeshP_syncMeshAll and iMeshP_ghostEntInfo and the concept of
   "ghosting rules".
 o iMeshP_createGhostEnts, iMeshP_deleteGhostEnts, etc. handle all
   communication.
 o after modifying mesh, application just calls iMeshP_createGhostEnts again
   to ghost any new entities, clean up remote references to deleted
   entities, etc.






More information about the itaps-parallel mailing list