-  "Local" operations are operations performed with respect to a part.
TJT: not quite, local are first local to an instance/processor, then
in very specific cases local to a part.

   Partition instances know which mesh instance's entities they partition. 
TJT: don't think so, analogous to an entity set not knowing which
instance it's in

   Mesh instances know which partitions they are in.
TJT: other way around, mesh instances know which partitions they
contain

   These functions will be reinterpreted so that they can accept either a 
   mesh instance and EntitySet handle, or a partition handle and a 
   part handle.  See Carl's Oct 15 email for more detail.
TJT: nope, mesh instance is always required; entity set handle can be
   either that or a part handle

void prefix_createPartitionMPI: 
. does this function (and destroy) imply communication if called in parallel?
. shouldn't the communicator be optional, to allow creating partitions
in serial?

//  Given a partition handle, return the mesh instance that is
//  included in the partition.  
//  KDD:  DO WE NEED THIS CAPABILITY?  IT IS HARD TO SPECIFY
//  KDD:  IF iMesh_Instance MUST ALWAYS BE FIRST ARG OF iMesh FUNCTIONS.  :)
TJT: agreed, we don't need it, analogous to sets

getRank, getRankArr: might these imply communication?

getNumOfTypePar, getNumOfTopoPar: does it make sense to have an entity
set handle parameter for this function?  What does that mean in
parallel?  Do entity sets given on each processor have to be ones
shared in parallel?

prefix_getNumEntSetsPar: we don't add entity sets to partitions, so
how can we get them for a partition?  Is this function really for
getting the entity sets over all procs?  Need to distinguish partition
from mesh across all processes in the communicator

Global IDs: I agree it should be a service.

Parts/part ids: why have functions which take/return parts as handles
and ids both?  Why not just deal with handles, and provide ids as
separate functionality?

getNumOfType/Topo, getEntSets: shouldn't this functionality be
available from EntSet functions, like add/rmv to/from part?

getAllVtxCoords, getVtxCoordIndex, getEntities, getAdjEntities, others:
similar comment as for getNumEntSetsPar above

getEntityOwner, others: would suggest using getEntityPart, etc., since
Owner is ambiguous

isEntOwner, isEntParStatus: isEntOwner should tell strictly whether
entity is in specified part (also, why have this be separate function
from getEntityOwner?); isEntParStatus tells whether entity is a
copy/ghost and other info

getNumCopiesEnt: num copies on processes or parts?

addCopyEnt, removeCopyEnt: do these functions communicate?

- For functions that replace a set handle with a part handle, return
  all appropriate entities in a part, whether they are owned or are 
  copies.  The application can test for ownership if needed.
TJT: is a copied entity put in a part?  I don't think it should be...


Need some functionality which exchanges tag data for entities on
interface and ghost entities (e.g. parallel smoothing application)