itaps-parallel abstraction for 'neighbors of a part'

[Tim Tautges]

I'm ok with 1-3 below in principle, and with a bit less certainty I 
think I'm ok with the specific definition below.  The one concern I have 
is whether it's wise to have part neighbor status depend on what level 
of ghosting exists between parts/processors.  I'm not sure ghosting 
should affect part neighbor status.  That's the same issue as whether 
part neighbors and communication plans are different (I think they are 
different).

- tim

Onkar Sahni wrote:
> Carl, Mark M., Mark S. (RPI folks), Tim (also others if you are interested):
> 
> Tim, I just wanted to provide some ideas before tomorrow's ITAPS
> parallel-interface phone conf. such that we can discuss them at that time
> and hence, I am writing this email with some of my ideas and proposal.
> 
> There are two parts to this email: (a) points to consider in abstraction
> of definition for 'neighbors of a part' and (b) "an" abstraction for
> 'neighbors of a part'. Read below.
> 
> ------------------------------------------------------------
> Points to consider in definition for 'neighbors of a part':
> 
> 1) Provide abstraction in definition for 'neighbors of a part', which is
> based on underlying mesh being partitioned (and is not completely
> arbitrary), and that can fit applications need. Basically, abstract ways
> of describing 'neighbors of a part' that application can understand,
> request and use (at least as building blocks to possibly achieve their
> more complex needs).
> 
> 2) In this process, possibly proceed with most basic one (inclusive of
> common apps.) or may be two, or even handful, but allow for future
> possibilities of incorporating other reasonable ones. I do not think at
> this stage in ITAPS parallel-interface we want to get all possible
> abstractions.
> 
> 3) If we decide on more than one, then we can consider the possibility of
> providing functionality to dynamically switch between them (i.e., on the
> fly, at run-time).
> 
> (Non-manifold geometries can be of interest/importance and may have extra
> valid/reasonable requirements which will introduce complexities and should
> be considered).
> ------------------------------------------------------------
> 
> ------------------------------------------------------------
> Proposal for "a" most basic definition of 'neighbors of a part' (that will
> satisfy (building block) needs of common apps. (which I can think of)):
> 
> Provided entity-type(s), two parts are considered neighbors if each of
> them at least "possess" one (first-order) adjacent "contributor" to any
> entity of specified-type(s), where, "possess" implies internal and also
> owner (for example, non-ghost mesh regions in a part) and "contributor"
> are mesh entities that do not bound any higher-order entity (for example,
> in a case of cube with an extra hanging flap/face (like tin-sheet in a
> brick wall), the mesh faces on flap (tin-sheet) and mesh regions within
> cube (brick-wall) are contributor entities).
> 
> At this point, this may look crude and complex (also lousy) and using
> mathematical form may clear a lot things. In any case, to make this more
> abstract we can further decide what are parameters various applications
> want to have control over (like specific entity-type or entity-types,
> first-order or second-order adjacencies, "contributor" or
> "highest-dimension" or "specified-type" adjacencies etc.). Moreover,
> implementations can tell which abstractions they support and in each
> abstraction what are constraints over input parameters (some
> implementations may say they don't support non-manifold cases).
> ------------------------------------------------------------
> 
> Feel free to polish/improve on above points. Also please let me know your
> feedback.
> 
> Thanks,
> Onkar
> 
> 

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