itaps-parallel Issues with prefix_sendEntArrToPartsPar and prefix_recvEntArrToPartsPar

[Vitus Leung]

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