itaps-parallel Part handle decision

[Mark Shephard]

This sounds about right.

Carl Ollivier-Gooch wrote:
> Tim Tautges wrote:
>>
>>
>> Devine, Karen D wrote:
>>> All:
>>>
>>> Some questions arose about whether we had reached a consensus on how to
>>> access part info.  I believe we did reach a consensus, but I have not 
>>> yet
>>> updated the interface document.  Please forgive me for the delay; this
>>> summer has been just crazy!  I'll make the update a priority for our 
>>> phone
>>> conf.
>>>
>>> Summarizing the consensus:  Part handles exist to identify on-processor
>>> parts; these part handles can be passed in place of entity sets to 
>>> many of
>>> the iMesh functions.  Global identification of parts is accomplished 
>>> through
>>> part IDs that are globally unique.  Functions that convert between 
>>> part IDs
>>> and part handles will return valid values for on-processor parts; for
>>> off-processor parts, they will return errors.
>>
>> Dare we say on-processor OR neighbor parts?
> 
> I don't see why we would want to.
> 
> Part handles are going to be used exclusively for local, on-process 
> queries about parts, and global part ID's for stuff involving 
> communication.  It doesn't make sense to have a part handle on another 
> process --- you can't do anything with it but send it back to its owner, 
> using some call that requires a global part ID.
> 
> If an implementation wants to deal with things differently than that 
> below the interface level, that's fine, but at the interface level, my 
> understanding was that we had agreed to effectively divide interface 
> functions that refer to parts into those that are strictly local (which 
> will take a part handle) and those that require communication (which 
> will take a global part ID).  Yes, implementations will have to convert 
> these things under the hood, but IMO that's a way better alternative 
> than having two versions of all the communication functions (one taking 
> a global ID, the other a process rank/part handle pair).
> 
> Carl
>