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

[Onkar Sahni]

Lori,

I have tried to answer some of your specific queries, see below.

I am still trying to work on my overall comments and concerns (which too
will now have many overlapping inputs).

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

  I think a comment will be useful to clarify (as Karen, Carl... agree)
that part IDs are mainly needed to refer to remote parts like if we want
to migrate entities from a part to another part then another part is
described in terms of 'part ID' (i.e., destination_part_id). We need
part-handles, that can be pointers and are local to a process, at least
in serial iMesh functions (in place of entity-set-handle); and also for
other things.

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

  Ones with rank can provide info. for any rank (off-process) and
moreover, prefix_getParts provide local on-process part-handles (that
can be further used in serial iMesh functions). I do not remember why we
need getNumPartIds and getnumPartIdsArr. If possible we should avoid
them.

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

  Yes, infact we do not require part handle(s) (Vitus too proposed these
syntax corrections). And in receive I think 'target' should refer as
'source'.

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

  Remote copy information is very critical in all of RPI's applications.
These functionalities provide link for shared entities. getCopyEntOnPart
is same as getCopiesEnt but only for a specific part. If names are
confusing then I think some re-naming might be required like changing
getCopyEntOnPart to getEntCopyOnAPart. I think providing appropriate
documentation and code-examples may avoid difficulties in thinking about
them.

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

  No this is not the case. I want to also clarify that addCopyEnt can be
called many times for a particular entity on a specific part (in case
where we want to add multiple remote copies for a particular entity on a
specific part, we may also want to provide add/rmvCopies).

Please let me know if something is not clear.

- Onkar

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