itaps-parallel definition for 'neighbors of a part'

Devine, Karen D kddevin at sandia.gov
Thu Feb 14 14:14:30 CST 2008


For these definitions, do we really need the distinction of "objects in the
partition"?    The phrase "objects in the partition" has a number of
problems.  First, what is an "object"?  Second, how is "adjacent entity"
defined for an "object"?  Third, does an implementation have to track the
"objects" used to compute the partition in order to compute neighboring
parts?  (I think the "objects" should be tracked by the partitioning
service, not the implementation.)  Fourth, what happens if a partition is
read from, say, parallel nemesis files and the application has no idea what
"objects" were used to generate the partition?

Do the following definitions work just as well?

Two (or more) parts are neighbors with respect to entity type A, if at least
one entity in each of the parts has a common lower- or higher-dimensional
adjacent entity of specified entity type A.

Or

Two (or more) parts are neighbors if any entity of specified entity type A
has at least one adjacent higher- or lower-dimensional entity in each of the
parts.

Karen


On 2/12/08 3:02 PM, "Onkar Sahni" <osahni at scorec.rpi.edu> wrote:

>
>
> Tim and I have come with two definitions for 'neighbors of a part' (the
> definitions imply same thing but wordings in each are different). Please
> provide us your feedback and we can choose one (or keep both).
>
> Two (or more) parts are neighbors, if at least one object in each of the
> parts (i.e., the objects in the partition owned by each part) have a
> common lower- or higher-dimensional adjacent entity of specified type(s).
> (Common higher-dimensional adjacent entity of type REGION will satisfy
> need for vertex-based partition, where mesh vertices are
> partition-objects, used in mesh smoothing).
>
> OR
>
> Two (or more)  parts are neighbors, if any entity of specified type(s) at
> least have one adjacent object in each of the parts (i.e., the objects in
> the partition owned by each part). (Again, for a vertex-based partition,
> specified type can be REGION and objects are vertices, so regions that
> have objects (i.e., vertices) on two parts make the parts neighbor to each
> other).
>
> Thanks,
> Onkar
>
>>
>> Attached is a revised version of DraftInterface.h, along with the CVS
> diff
>> from the previous version you saw.
>>
>> In going through everyone's reviews, I saw that confusion remains regarding
>> copies and their management.  In this week's phone conf, we'll discuss
> the
>> communication functions (sendEntArrToPartsPar/recvEntArrFromPartsPar) as
> well as any function with Copy/Copies and Owned in its name.
>>
>> There are many other parts of the interface marked "TODO".  Let's
> discuss
>> them over email to reach consensus on as many as possible before using
> phone
>> time for them.
>>
>> I have not received the new part-neighbor definition yet, so the old one is
>> still in the document.
>>
>> Finally, I tried to address all comments in the reviews, but if there is
> a
>> point that I missed or didn't address to your satisfaction, please let
> me
>> know.
>>
>> Thanks for your contributions!
>> Karen
>>
>>
>
>
>
>
>
>






More information about the itaps-parallel mailing list