itaps-parallel To-do list for next phone conference

[Devine, Karen D]

The next phone conference is June 5 at 1pm PDT.

Before the next phone conference:

-  Vote:  Do you need the functions iMeshP_getNumPartsOnRank and
iMeshP_getPartsOnRank, which return the number and part handles,
respectively, of parts on a given rank?
   "Yes" vote means you need those functions.
   "No" vote means it is OK to replace these functions with functions that
are restricted only to the current process; e.g., iMeshP_getNumPartsOnMyRank
and iMeshP_getPartsOnMyRank.  (We can modify the names, of course; these are
yucky but they communicate the idea.)

-  Think about part handle requirements.  It would be nice to keep part
handles as is, since we overloaded some functions to take part handles in
place of set handles.  But we also don't want to have to store O(#parts) or
O(#processes) data to answer queries about part handles.  We decided to
define the required capabilities of part handles.  Here's a start adapted
from Carl's email.  Please comment on whether this list is (1) complete and
(2) feasible.  Onkar, you have thought a lot about this, so please
contribute your concerns.

Part handles ...
a) are globally unique (so that remote part handles make sense and Zoltan
doesn't go insane);
b) allow identification (without communication or O(#parts) storage) of what
process the part lives on [note:  communication is allowed in
iMeshP_syncPartitionAll to updated info about parts that could be used
here];
c) can be computed knowing only process rank and local part number (that is,
iMeshP_createPart can return a part handle without communication);
d) can be distinguished from pointers and entity set handles (so that our
overloading works).

-  Review and comment on the ghosting specification that Tim sends this
week.

Thanks for a good call today.
Karen