itaps-parallel Neighbor definition

[Mark Miller]

Hi Onkar,

I see your point. I am considering my response. Stay tuned...

Mark


Onkar Sahni wrote:

> Mark,
>
> There is one thing Lori specially mentioned in terms of an application,
> that the (lower-order) entities at inter-part boundaries exist only on one
> part ("uniquely owned") and so higher-order mesh entities on all but one
> will not be closed (so a mesh face on inter-part boundary bounding two
> mesh regions on two different parts will exist on one part).
>
> In this way I think there might be a more conceptual way to describe part
> neighbors then by specially using term "sharing of entities". And as we
> discussed it cannot be any arbitrary description but has to be related to
> underlying mesh being partitioned.
>
> Please let me know your comments.
>
> Thanks,
> Onkar
>
> > Hi Tim,
> >
> > This is very clear to me and I agree with it. But, since some of the
> > discussion after Lori left the conversation is missing, I'd like to take
> > a stab at adding that here simply in order to take a snapshot of the
> > history of this discussion...
> >
> > We basically went full circle in our discussion. The conversation
> > started with the notion that part neighbors are based upon the sharing
> > of mesh entities. An objection was raised because we can
> > often think of circumstances in which two parts need to exchange
> > data across the 'boundary' between them even when they DO NOT
> > necessarily share mesh entities. Rercusive Coordinate Bisection and
> > Finite Volume computations were raised as two examples. In the
> > former, RCB, I believe we also made arguments that there does in
> > fact exist a 'shared mesh entity' analog in that there are mesh edges
> > that are 'cut' by the RCB algorithm and it is those edges that wind
> > up being 'shared' between parts [I did not consider this yesterday
> > but what if such edges are never actually instantiated in iMesh?
> > Would this make the argument theoretically correct but practically
> > speaking not implementable?]
> >
> > We observed that there are likely to be many situations in which
> > processors (or the parts they own) need to communicate that have
> > nothing to do with underlying mesh topology. So the question arose,
> > do we expect our Part/Partition model and implementation to support
> > a more general notion of 'neighbor' or one that is specific to
> > mesh topology. Ultimately, we argeed on the latter.
> >
> > We also argued that a notion of neighbor based solely on mesh
> > topology is a 'sufficient bootstrap' to enable applications requiring a
> > more general notion of 'neighbor' to affect their communication
> > patterns. [As an aside, I don't think we considered this argument
> > in great detail and I wonder if it is in fact true in all cases that
> > more general notions of neighbor can always be derived from the
> > topologically specific one being proposed here. I'm inclined NOT to
> > believe that. At the same time, I think it is also arguable that such
> > situations are too 'application specific' to be worried about
> > explicitly supporting in the Part/Parition model we are developing.]
> >
> > We also agreed that our intention in developing the Part/Partition
> > model on top of iMesh is to support the topologically common
> > operations most applications will need and not necessarily ALL
> > possible communication patterns applications might use.
> >
> >  One question we need to re-visit is what are the implications
> > (storage and/or performance), if neighbor relationships other than
> > those determined by topology, are not supported?
> >
> > Mark
> >
> > Tim Tautges wrote:
> >
> >> A question arose in yesterday's telecon on what constitutes a part
> >> neighbor.  After some discussion, we came up with the following
> >> definition and rationale.
> >>
> >> Def: for a given part, a part neighbor of dimension d is any other part
> >> which shares mesh entities of dimension d with that part (i.e. the
> >> entity is represented on both parts).
> >>
> >> Rationale:
> >> - it is desirable to tie the definition of a part neighbor with
> >> information intrinsic to the mesh, i.e. one could derive information
> >> about part neighbors using only information about the mesh entities and
> >> the partition of entities over processors
> >>
> >> - in general, applications will have other criteria determining which
> >> other processors a given processor communicates with; that information
> >> can be stored in iMesh using sets and tags already, and applications
> >> will presumably be able to pass those things to communication functions
> >> in the itaps parallel interface (thus driving the application-specific
> >> communication patterns)
> >>
> >> Question: are ghosted/copied entities between parts considered shared?
> >> I would assert that ghosting/copying should be between processors, not
> >> parts, so this question is not relevant with respect to part neighbors.
> >>
> >> - tim
> >>
> >> --
> >> ================================================================
> >> "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
> >
> > --
> > Mark C. Miller, Lawrence Livermore National Laboratory
> > email: mailto:miller86 at llnl.gov
> > (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> > (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
> >
> >
> >

--
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)