itaps-parallel To-do list for next phone conference

[Tim Tautges]

For functions requiring globally unique part identifiers, why not use a 
part id, and distinguish that from part handle?  I know this was part of 
RPI's proposal way back when, but I think here we can be more specific 
about when it's created/used/needed.  That is, it's used analogously to 
a global id for mesh entities, e.g. when partitioning them.

- tim

Onkar Sahni wrote:
> Karen,
> 
> See my comments on part-handles below (inline with your points):
> 
>> Part handles ...
>> a) are globally unique (so that remote part handles make sense and Zoltan
>> doesn't go insane);
> 
>   On any process, only local part-handles and neighboring (remote-)
> part-handles are accessible through iMeshP interface. And it seems
> reasonable that any iMeshP implementation will provide unique handles
> for local and neighboring parts on any single process.
> 
>> b) allow identification (without communication or O(#parts) storage) of
>> what
>> process the part lives on [note:  communication is allowed in
>> iMeshP_syncPartitionAll to updated info about parts that could be used
>> here];
> 
>   I would say allow identification, comparison etc., whatever is needed by
> applications (like mesh-modification or flow-solver) and services (like
> Zoltan). I do not know what is the set of necessary operators required
> in this category and this has been my concern, especially for services
> like Zoltan (as they might need more than local and neighboring
> part-handles).
> 
>> c) can be computed knowing only process rank and local part number (that
>> is,
>> iMeshP_createPart can return a part handle without communication);
> 
>   I am not sure about part-handle being computed knowing only process rank
> and local part number. I agree iMeshP_createPart must return a part
> handle without communication but it doesn't need to know process rank
> and local part number as input of partition_handle will provide this
> information. In other words we do not have iMeshP_computePartHandle(int
> rank, int localID, iMeshP_PartHandle *part_handle) and I think it is
> difficult to support this unless we work with iMeshP_PartID (not
> handle).
> 
>> d) can be distinguished from pointers and entity set handles (so that our
>> overloading works).
> 
>   I agree part-handle should be overloaded in necessary iMesh functions
> (as I understand all handles are typedefed to void* so I do not know
> what it means by can be distinguished from pointers).
> 
> - Onkar
> 
> 
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706