itaps-parallel Phone meetings past and future

[Tim Tautges]

Devine, Karen D wrote:
> 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

In particular, stored on the partition.

> 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.

*may* add more ghosts, depending on existing ghost entities and new 
ghost data.

>    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.
> 

See following message.

> -  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);

We need to go back to having a global part id, which is distinct from 
the part handle.  The handle should really be implementation-dependent.

>    +  Part handles allow identification (without communication or O(#parts)
> storage) of what process the part lives on;

Only if a part is already "known" on another processor; under what 
conditions does this happen?

>    +  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.

This is the implementation's responsibility.

>    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
> 
> 
> 

- tim

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706