itaps-parallel Assignments for parallel interface, due before 2/5 phone conf

[Lori A. Diachin]

Hi Karen and all,

I reviewed the document and have the following additional big picture 
questions for everyone (I agree we need to discuss the 4 at the bottom 
of this email as they occurred to me too when reading through the spec). 
I have a number of smaller issues as well, but will focus only on the 
larger items here. I apologize if this duplicates other folks' input - I 
haven't had time to review all the email sent out today.

- Our notion of partition neighbors appears to be defined by 'sharing' 
entities and I'm wondering about the case in which all entities are 
uniquely owned by a partition so nothing is 'shared'. This is how I 
think about partitions, and I think about partition neighbors as being 
defined by adjacency information in the mesh.

- I found the difference between partition handles and partition IDs, 
and when you would use which one, to be very confusing and non 
intuitive. Do we really truly need both, or can we just go with part IDs?

- the prefix_getNumParts and prefix_getParts seems to duplicate the 
functionality just above it in the file if you just add a myrank, so I 
suggest eliminating these two functions. Speaking of the functions just 
above (getNumPartIds and getNumPartIdsArr) - not really sure why you 
bring "Ids" into the function name other than to avoid conflict with the 
function below which I suggest eliminating)

- Global IDs. I'm fine with having this be a service on top of the 
interface, but we need the functionality in Mesquite, so I would propose 
it be separate from the load balancing service.

- In many instances there's a "getNumX" and a "getX" - I think we should 
look at whether or not we always need both functions or if we can just 
use getX, which returns the num as a byproduct. I realize there are many 
cases where you do need to separate the calls, but perhaps not all.

- prefix_sendEntArrToParts and the corresponding receive function both 
appear to take an entityset handle - I would have expected they take an 
entityhandle... is this a typo, or am I missing something?

- I like the idea of getting rid of the extra iterator functions (other 
than the init function) if we can

- isEntOwner appears to return "boundary", I think we should limit it to 
"owner" or "copy" --- "boundary" fits more naturally with, and is 
already included in, the next function isEntParStatus (which should 
probably be 'getEntParStatus')

- I struggle with the copyEntOnPart functions... I don't fully 
understand what this adds to the interface and I think it could lead to 
headaches when thinking about consistency of information across processors.

- Seems as though the addCopyEnt and removeCopyEnt could be combined 
with the other add functions (that are like entityset functions) with an 
appropriate enumerator (e.g. OWNED, COPY, etc)..

Lori

Devine, Karen D wrote:
> In the last phone conf, someone suggested that we put together a draft of
> the syntax for the capabilities on which we agreed.  So I added syntax from
> Carl's, Onkar's and Tim's past emails to our Combined document.  For
> readability, I turned the file into a C header file; the discussions from
> the Combined document are now comments in the C file.  The file is attached.
>
> For now, I'd rather not discuss:
> -  values of "prefix_".
> -  my use of "//" for comments being non-standard for some C compilers.
> -  my inconsistent use of "const" (unless I used it for a return argument --
> oops!)
> -  whether or not this file would actually compile.
>
> Here are your assignments:
>
> ALL:  Please give your opinions of the questions below. Some are simple
> questions resulting from the fact that I'm not used to ITAPS code
> conventions.
>
> Mark M. and Lori:
> -  Review all functions at a high level to identify gaps and duplications in
> capability.  Suggest functions that should be added or removed.
> -  Review all functions at a high level to determine whether our syntax is
> generally consistent with ITAPS' conventions and generally consistent within
> the document.  You shouldn't catch every detail; just let us know whether
> someone who is comfortable with other ITAPS interfaces would find this
> interface comfortable as well.
>
> Mark M and Onkar:
> -  Review all functions at a high level and indicate whether their use of
> communication will be definite, likely, or nonexistent.  If they incur
> communication, will the communication be global (e.g., MPI_Allreduce) or
> point-to-point (e.g., MPI_Send/MPI_Recv)?  We'll eventually modify the
> function names to indicate whether or not they incur communication.
>
> Onkar:
> -  Review in detail the Entity Functionality section.  This section has the
> entity copying capability, including the add/remove copies that you
> discussed in the last phone conf.
>
> Vitus:
> -  Propose the communication functions needed to support
> prefix_sendEntArrToParts and prefix_receiveEntArrToParts.
>
> Carl:
> -  Should functions prefix_getEntSets and prefix_getNumEntSets be added to
> Carl's sixteen functions?  They appear to be analogous to
> prefix_getEntities and prefix_getNumOfType.
> -  Review in detail the Part Functionality section.
>
> Tim:
> -  Review in detail the Partition Functionality section.
>
> ------------------------
> Questions for everyone:
>
> -  When we specify a part handle, must we always also specify a partition
> handle?  That is, should a part be uniquely identified by the pair
> (partition_handle, part_handle), just as entities are uniquely identified by
> (mesh_instance, entity_handle)?   "No" is the most convenient answer to this
> question; if parts are uniquely identified by only the part handle, we can
> do the entity-set argument overloading that we discussed at bootcamp.  We
> can also remove the partition_handle argument from many of the functions.  I
> had previously argued for use of the tuple, but many things would be easier
> if we didn't need it.  Can all the implementations generate part handles
> that are unique within an iMesh_Instance, rather than within a partition?
>
> -  With iterators over parts or part boundaries, is it necessary to have
> separate interface functions for getNext, reset, and end, or will the
> standard iMesh functions for getNext, reset, and end suffice?  That is, once
> an iterator is initiated, do we need to continue passing the part handle
> and, perhaps, neighbor-part id, to the iterator, or can the iterator
> "remember" these just as it remembers entity type and topology?  If we can
> re-use the iMesh getNext, reset and end, we can remove six functions from
> Carl's sixteen functions, bringing the count back to his original estimate
> of ten.
>
> -  Which functions should operate on single parts and/or entities, and which
> should have array versions (function_name and function_nameArr)?  I included
> both wherever we had a comment "Need single-part and array-part versions" in
> the combined document, but I won't be offended if we remove some of the
> functions.
>
> -  Since global IDs for entities are not used anywhere in the interface, I
> propose their generation and use should be a service on top of the interface
> rather than part of the interface.  What say you?
>
>
>
>