itaps-parallel Notes and assignments

[Onkar Sahni]

Sorry for yet another message.

I want to be clear on a line from my previous message.

By "Objects exist only on one single part" I meant "A object exists on a
single part" (for example, during mesh-partitioning each object in the
mesh will be assigned to a single part).

- Onkar

> Karen,
>
> I would like to point out one premises for earlier definition of
> 'neighbors of a part', which included "objects" in its definition:
>
> --------------------------------------------
> Objects exist only on one single part (lets avoid any ghosting).
>
> Early definition X reads like does any object (on current part) have
> common adj. entity of type A with objects (on other parts) (for example,
> region1/object1 in part 1 and region2/object2 in part 2 have a common adj.
> face (type A=FACE)).
>
> Early definition Y reads like does any entity of type A have objects adj.
> to it that lie on separate parts (for example, face (type A=FACE) has adj.
> regions/objects in parts 1 and 2).
> --------------------------------------------
>
> If one does not consider "objects" and/or "rules" (basically fact that
> "objects" exist only on one single part) into these definitions and just
> considers arbitrary entity-types A and B then both definition can be one,
> see below.
>
> Definition X + Y: Two (or more) parts are neighbors, if any entity of type
> A has at least one adjacent entity of type B in each of the parts (type A
> and type B are inputs).
>
> For example,
> **1) type A = REGION, type B = FACE (does any region has an adj. face that
> exists on parts 1 and 2).
>
> **2) type A = FACE, type B = REGION (does any face has adj. regions in
> parts 1 and 2).
>
> As of now I think we need to put some restriction on one of entity-type
> and if one does that then again there are two ways to see 'neighbors of a
> part' (like def. X and def. Y).
>
> Please let me know if you have questions.
>
> - Onkar
>
>
>>
>> OK, we're in the home stretch in preparation for bootcamp.
>>
>> Our next phone conf is scheduled 2/28 at 1pm PST.  The biggest issues
>> still
>> in question are (1) copies and communication for them, (2) communication
>> of
>> tag info, and (3) what should be included in prefix_UpdatePartitionPar.
>>
>> We probably have only two phone confs left before bootcamp, so please
>> schedule 1.5 hours for the call on 2/28.  I'd like to make significant
>> progress on (1) and (2).
>>
>> Assignments:
>>
>> Carl & Onkar:  Revise the functions for copies and non-collective
>> communication.
>>
>> Tim:  Submit functions for exchanging tag data.
>>
>> All:
>> -  Send a list of data you'd like to have pre-computed in
>> prefix_UpdatePartitionPar (allowing other functions to work without
>> communication).
>>
>> -  Vote for your favorite definition of part neighbor (or submit your
>> objections to both along with a definition that you like better):
>>
>>    Definition X:  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.
>>
>>    Definition Y:  Two (or more) parts are neighbors with respect to
>> entity
>> type A if any entity of specified entity type A has at least one
>> adjacent
>> higher- or lower-dimensional entity in each of the parts.
>>
>> -  Read the attached updated DraftInterface.h, paying attention to items
>> marked TODO.
>>
>>
>
>
>