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