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