itaps-parallel A question about iMeshP interface functions

[Mark Shephard]

In trying to follow these emails it looks like there is a lack of 
understanding of some of the issues and as is typical, it relates to 
the basic differences in approached taken in MOAB and FMDB. Unless those 
involved in the emails actually think they are converging, let me 
suggest that this issue needs to be addressed by some combination of 
conference call(s) and/or technical documents that actually describe 
what is there and how it works.

Mark

Jason Kraftcheck wrote:
> Onkar Sahni wrote:
>>> I had assumed that if one had a handle for an entity at all, that the
>>> local
>>> processor knew enough about that entity to answer such questions (e.g.
>>> that
>>> it is an interface or ghost entity.)  But I missed several discussions.
>>> Are
>>> we back to considering entity handles to be globally unique across all
>>> processors?
>>   If entity-handle is local (on local part/proc.) then one can ask such
>> questions (ghost entity etc.), but if entity is not local, i.e,
>> remote-handle or remote-copt then it is not valid to ask such questions.
>> How do we return reasonable error message/code in this case of
>> remote-handle. There are no globally unique entity handles.
>>
> 
> What is a "remote handle"?   And are you talking about entity handles or
> part handles?
> 
>>> It seems to me that the iMeshP_getEntOwnerPart and
>>> iMeshP_getEntOwnerPartArr
>>> are inherently expensive, and those are the only two for which I see a
>>> requirement to return an error if the passed entity is not contained in
>>> the
>>> partition.  I'm looking at the draft spec Karen sent on July 24th.  Is
>>> there
>>> a more recent one?
>>   I do not see why these will be expensive, at least they are not in FMDB
>> implementation.
>>
> 
> Presumably if you have some structure that allows for a fast search for the
> parts an entity is contained in, then that structure is fairly large, as it
> must contain values for every mesh entity.  It is either costly in terms of
> memory required or slow.  Either way, it is expensive.
> 
> How can the FMDB implementation efficiently search for the part an entity is
> contained in while not being able to efficiently determine if the entity is
> part of a given partition?  Is it the cost of determining which partition a
> part is in that FMDB cannot do efficiently?
> 
> - jason
>