itaps-parallel A question about iMeshP interface functions

[Onkar Sahni]

I agree and think that there are lots of details which other may or may
not like to go into.

So I would suggest that Ting and Janson can discuss details on FMDB if
they want to.

Rest can just think about the issue and discuss.

- Onkar

> 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
>>
>
>