itaps-parallel Issues with prefix_sendEntArrToPartsPar and prefix_recvEntArrToPartsPar
Tim Tautges
tautges at mcs.anl.gov
Wed Feb 27 10:34:06 CST 2008
Ok, that's what I thought. However, isn't that sort of information
already available from other calls? If so, then couldn't the
implementation figure out what it needed to inside the send/recv calls,
so there wouldn't need to be additional functions?
- tim
Onkar Sahni wrote:
> Part of the reason is the need for an entity to know handle/pointers of
> its image on other parts (this involves entities which are non-objects and
> have images on multiple parts like mesh faces on inter-part boundaries,
> and also mesh edges and vertices, for a 3D case with mesh regions as
> objects).
>
> Other reason one can think of (for communications) is to determine
> residence parts for non-object entities (after migration), i.e., on which
> parts any non-object would exist, assuming destination part for each
> object is provided.
>
> - Onkar
>
>> Why is a single pair not sufficient? Does it have to do with needing to
>> know the handle on the destination proc?
>>
>> - tim
>>
>> Onkar Sahni wrote:
>>> The document Ting sent few days ago provides details of mesh migration
>>> code, specifically how it is done in FMDB. With this document I would
>>> like
>>> to mention one important point.
>>>
>>> It is critical to realize that one set/pair of send and recv. is not
>>> sufficient to keep mesh-database up to date as mesh migration is done
>>> (whether for partitioning and/or for local mesh modifications).
>>> Basically
>>> to keep track of remote copies (independent of issue whether owner knows
>>> all remote-copies or all remote-copies know all other remote-copies),
>>> one
>>> set/pair of send and recv. is not sufficient. Hence,
>>> prefix_sendEntArrToPartsPar and prefix_recvEntArrToPartsPar will not be
>>> sufficient.
>>>
>>> So we will have to re-visit these functions (as I remember the
>>> impression
>>> was that these would be enough for mesh migration for mesh-partitioning
>>> and NOT mesh-modifications, where Carl and I are trying to resolve
>>> issues
>>> with the latter (mesh-modification) one).
>>>
>>> Please let me know if you have questions.
>>>
>>> - Onkar
>>>
>>>
>>>> Dear All,
>>>>
>>>> The attached is the pseudo code of current FMDB migration algorithm and
>>>> some simple explanations. Please let me know if you have any problems.
>>>> Thanks.
>>>>
>>>> Regards,
>>>>
>>>> Ting
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> ================================================================
>> "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
>>
>>
>
>
>
--
================================================================
"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
More information about the itaps-parallel
mailing list