itaps-parallel Phone meetings past and future

[Devine, Karen D]

Below are notes from the last phone meeting and action items for this week's
meeting.  There are one or two TODOs for everyone, and specific items for
Tim, Lori and me.

-  Functions iMeshP_getNumPartsOnRank and iMeshP_getPartsOnRank were voted
out.
   TODO:  Karen will remove them from the draft specification.

-  Tim's function to establish ghost cells iMeshP_Exchange_Ghost_Cells was
discussed and accepted.  The following conventions were agreed upon:
   +  The triplet describing a ghosting "rule" (ghost dim, bridge dim, #
layers) will be stored in the implementation and re-established by the end
of iMeshP_syncPartitionAll and iMeshP_syncMeshAll.  Implementations can
choose to keep ghosting consistent throughout mesh modification, but ghosts
are not required to be consistent until the end of these two functions.
   +  The number of layers specified is with respect to the global mesh;
that is, ghosting may extend beyond a single neighboring processor if the
number of layers is high.
   +  iMeshP_Exchange_Ghost_Cells is a preprocessing function.  It is
cumulative; that is, multiple calls will add more ghosts, not eliminate
previous ghosts.
   TODO:  Karen will add iMeshP_Exchange_Ghost_Cells to the draft (with
syntax/naming consistent with the rest of the interface).
   TODO:  Tim will propose syntax for deleting lists of ghosts and deleting
all ghosts and ghosting rules.

-  Nathan Fabien asked about the established orderings that exist in ITAPS.
It was agreed that ITAPS has an established ordering of downward
adjacencies, but not upward adjacencies.
   TODO:  Does someone have a link to the document describing the adjacency
conventions?

-  Part Handles:  At the next meeting, I'd like to resolve outstanding
issues with part handles.  In particular, are the following requirements
necessary and sufficient for part handles?  That is, can implementations
satisfy these requirements and, if they do, will services and users be
satisfied?
   +  Part handles are globally unique (so that remote part handles make
sense and Zoltan doesn't go insane);
   +  Part handles allow identification (without communication or O(#parts)
storage) of what process the part lives on;
   +  Part handles can be created and returned by iMeshP_createPart without
communication;
   +  Part handles can be distinguished from entity set handles so that our
overloading of many iMesh functions works.
   TODO:  Everyone should think about these requirements from the
implementation and user perspective.
   TODO:  Lori:  Martin raised concerns about part handles at the ITAPS
bootcamp, saying he'd prefer consecutive, integer part identifiers in the
range 0 to (number of parts - 1).  Your vote will decide whether Martin has
to live with these requirements, so it would be good if you understand his
concerns.

If we can resolve the part handles and ghost issues, we'll be in pretty good
shape for the tutorial in July.  The biggest outstanding issue then will be
parallel file I/O; I'm willing to tackle that for July as well, but it might
be more realistic to target the SC08 tutorial instead.

Karen