itaps-parallel iMeshP_syncPartitionAll, iMeshP_getNumGlobalParts, and communication

[Jason Kraftcheck]

Devine, Karen D wrote:
> My understanding of how one uses partition handles with iMeshP_load is as
> follows:
> 
> User creates a mesh instance.
> User creates a partition handle, associating a communicator with it.
> User calls iMeshP_load with the mesh instance and partition handle.  In
> addition to doing everything that iMesh_load did to fill the mesh instance,
> iMeshP_load constructs parts (either by reading part assignment from files
> or calling Zoltan), adds the parts to the partition, adds entities to the
> parts, etc., and calls iMeshP_syncPartitionAll.  Thus, iMeshP_load returns a
> useable mesh instance and partition handle to the application.  After that,
> calls to iMeshP_getNumParts do not invoke communication, as the number of
> parts is pre-computed in iMeshP_syncPartitionAll.
> 
> Are you saying you would like iMeshP_load to accept and return multiple
> partition handles?  I don't mind making that change, but we haven't yet
> worked out the details of having multiple partitions of a mesh (e.g., how to
> specify which partition is the "active" partition).
> 

No.  I don't think it should need to return multiple partitions.  The
iMeshP_getNumPartitions and iMeshP_getPartitions should be sufficient for
that.  I'm more concerned with how to implement iMeshP_getNumGlobalParts if
there are more partitions than the "active" one.  I had already assumed
there'd be multiple partitions as iMeshP_get(Num)Partitions is in the API.


> Sorry; I admit I do not understand your use case of doing partitioning in
> parallel.  Whether we do partitioning serially or in parallel, we create
> generally create one partition with many parts.  Please explain your use
> case more.  Thanks!
> 

You know more about such things than I.  I had assumed that the resulting
partitioning need not be related to the partition used to distribute the
mesh for the parallel partitioner.

- jason