Honored selectees:

As promised, here are the assignments for draft zero 
of the parallel interface.

Our task due by November 16 is to build the interface 
for Sections 3.2 (Basic Parallelism) and 3.3 (Partitions) 
of the requirements document. There are four categories 
of interface needed.

  -  Global queries (including MPI Communicators)
  -  Global IDs
  -  Partition Model
  -  Partitioned Mesh

Here's the plan:
Step 0:  draft what functions are needed in each
         category; due Oct 15.
Step 1:  agree on what functions are needed in each 
         category; due Oct. 18.
Step 2:  formalize the syntax for those functions; 
         due Oct 25.
Step 3:  review and revise output from Steps 1 and 2, 
         and write first draft; due Nov. 16.

Below is an outline of what should be included in each 
category.  The requirement numbers are those used in 
CVS Version 1.14 of the requirements document, 
distributed October 2.

Global Queries:

-  Req-5: MPI Communicators
   We did not agree at the bootcamp whether MPI 
   communicators should be set once or passed to each 
   function.  It seems natural that an MPI communicator 
   be associated with a mesh; that is, a mesh would know 
   which processors contained any part of the mesh.  
   Different communicators could be passed to services 
   like load balancing, but in general, a query like 
   "give me the global number of element in this mesh" would 
   use the mesh's communicator.  So should we have one
   function that associates a communicator with a mesh?  
   Or should both a communicator and a mesh be associated 
   with a partition?  Or are there cases where separate 
   communicators would be needed for each function?  Or...?

   Also here, we should probably decide what a root set
   really is in parallel.  Should there be one root set
   per processor, with functions invoked on the root set
   returning only info on the processor?  If so, should 
   there be an additional layer above the root set
   representing the global mesh?

   Just for my understanding, is a root set equivalent to
   a mesh instance?  If, say, a multiphysics application 
   has two meshes, does it have two root sets?

-  Req-6:  Global queries
   Which queries should we support?  Should they all be 
   associated with a mesh?  

-  This category also enforces requirements 
   Req-2, Req-3, and Req-4.

Global IDs:

-  Req-7:  Global IDs
   We agreed at bootcamp that global IDs would be 
   represented as an array of integers.  We need to 
   define the data types and functions on global IDs,
   as well as their immutability.

Partition Model

-  We decided to have a separate iPart handle that 
   would be passed to ITAPS functions.  We'll also 
   need some functions that return information about 
   a partition.  These functions are required by 
   Req-10 to Req-13.

Partitioned Mesh

-  We decided that iPart handles could be passed to 
   many ITAPS functions in place of Entity handles.  
   We need to now examine whether that decision was 
   correct.  So for this section, we need to discuss 
   how easy substitution of iPart handles will be and 
   what additional capability will be needed.  This 
   section deals with Req-14 to Req-18.

OK, now the exciting part -- the part you've all been 
waiting for -- your assignments!  We'll divide and 
conquer, having each group take care of one category 
as follows.  

Global Queries:    Argonne (Tim)
Global IDs:        Sandia  (Vitus, Karen)
Partition Model:   RPI     (Mark, Ken, Onkar)
Partitioned Mesh:  UBC     (Carl)

By Oct 15, please complete Step 0 and send the output 
to this distribution list for review and discussion.
Thanks.

Karen