itaps-parallel Issues with prefix_sendEntArrToPartsPar and prefix_recvEntArrToPartsPar

[Onkar Sahni]

That sort of information is not available (where that sort of information
implies remote copies).

As mesh migration is done you create entities (and their handles) on other
parts, until you have created the entity you do not know their handles on
parts where it got migrated. Again this includes entities which are both
objects and non-objects.

- Onkar

> I agree with Tim.  This also relates to the bigger issue of being able
> to easily get entities shared with other parts.
>
> Vitus
>
> On Wed, 2008-02-27 at 09:34 -0700, Tim Tautges wrote:
>> 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
>>
>>
>
>
>