itaps-parallel removal of

[Onkar Sahni]

>> This is bad for a parallel mesh decomposer, for example, which
>>
>> needs to be able to 'assign' entities to 'any' parts. It will need to
>>
>> be able to identify parts to 'send' entities to that are neither local
>>
>> nor neighbors of the 'initial' decomposition. I suppose one could
>>
>> argue that it could achieve this by sending entities on a 'journey'
>>
>> through all the part neighbors between the originating and destination
>>
>> parts. But, that wouldn't be too efficient.
>
> By "parallel mesh decomposer" I assume you do -not- mean a full-up
> partitioner (which will have a list of part handles that come with the
> entities to be partitioned).  Instead, you're presumably talking about a
> scenario qualitatively similar to having a single process read a
> parallel mesh and dice it -before- the partitioner gets involved.

  I think it means calling a service like Zoltan for partitioning, which
will be called collectively with mostly local information on each
process (like local entities forming objects/graph nodes and local
part-handle of each local object, may involve neighboring part-handles
for graph-edges crossing inter-part/process bdry.).

>
> Or I could argue (and this is the alternative I prefer) that it's
> possible to have part handles that:
>
> a) are globally unique;
> b) allow identification of what process they live on;
> c) can be computed knowing only process rank and local part number; and
> d) still be be universally distinguished from pointers.

  If we consider part-handles then it could be pointers, I find it
confusing to call it an handle and then say by the way it is an int or
uses some specific number of bits (although implementation if free to do
so and mostly we will do the same in FMDB). May be we should call it
partIdType or partHandleType, OR may be we should just provide
appropriate functions to satisfy items a-d above in terms of
part-handles, like (a)-comparison operator on part-handles, (b)-process
rank info. which we already have, (c)-we have tried to avoid use of
local part number and (d)-not necessary

- Onkar