itaps-parallel Part handles
Vitus Leung
vjleung at sandia.gov
Tue Jun 24 09:41:56 CDT 2008
In the draft interface, there are functions that take part handles that
may be local or remote (without rank) and functions that return remote
part handles (again without rank). It seems to me that these would
require globally unique part handles. Also, there is an open item on
iMeshP_syncPartitionAll computing a mapping from part handles to
integers 0,...,k-1. If that is done, Zoltan could make use of that
information. Zoltan takes as input the existing partition. After
Zoltan computes new assignments, iMeshP_exchEntArrToPartsAll will
migrate the entities to their assigned parts. I believe the parts have
to already exist since part handles are used for the migration.
Vitus
> + Part handles are globally unique (so that remote part handles make
> sense and Zoltan doesn't go insane);
> - remote part handles won't exist on a processor unless they were
> communicated there somehow; in that case the implementation will be able
> to store the proc # with (not in) the handle if it so chooses
> - didn't I hear you say, Karen, that Zoltan computes its own 0..n-1
> numbering of parts anyway? Or, will you eliminate that if we have
> unique part handles?
> - are we assuming an application will allocate all the part handles
> before calling Zoltan for the partitioning case? Does it actually have
> to migrate entities to the processor owning a part in order to assign
> those entities to that part? Or, can a given processor only assign
> local entities to local parts? That seems like a pretty severe
> limitation (and would only allow you to partition for increasing #'s of
> processors besides)
More information about the itaps-parallel
mailing list