itaps-parallel abstraction for 'neighbors of a part'

[Onkar Sahni]

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