itaps-parallel iMeshP_syncPartitionAll, iMeshP_getNumGlobalParts, and communication

[Devine, Karen D]

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

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!

Karen


On 10/15/08 8:29 AM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:

> Onkar Sahni wrote:
>> See my comments below:
>>
>>> 1) Do global communication for all partitions during file load to cache
>>>     global number of parts for each partition read from file.
>>>
>>
>>    iMesh_load allows only one partition (i.e., iMeshP_PartitionHandle) as
>> an input. So I do not know what load of 'all partitions' means... (may
>> be I am missing something). And as per my understanding either
>> iMesh_load is collective or is followed by call to
>> iMeshP_syncPartitionAll
>>
>
> iMesh_load allows one partition to use to distribute the mesh amongst
> processors (one active partition).  That does not mean that there cannot be
> others (e.g. doing partitioning in parallel).
>
>
>>> 2) Require application to associate an an MPI_Comm with any partition (we
>>>     don't have an API for this) and call iMeshP_syncPartitionAll on it
>>>     before expecting to be able to get any global data.
>>>
>>
>>   iMeshP_createPartitionAll takes MPI_Comm as an input and as per my
>> understanding thats how application will associate an MPI_Comm with any
>> partition.
>>
>
> But that only works if the application creates the partition.
>
> - jason
>
>
>