itaps-parallel abstraction for 'neighbors of a part'

[Onkar Sahni]

Tim,

Could you please send the updated version of definition for 'neighbors of
a part'.

Thanks,
Onkar

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