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

[Onkar Sahni]

I have attached part of my assignment which discusses communication
requirement of functions at high level.

Other part of assignment on entity functionality will follow (hopefully
before end of today).

I will also try to send general overall comments and concerns for ITAPS
parallel interface.

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

  As of now, we (RPI) are considering a parent/root/primary partition for
any single mesh-instance (i.e., parent-partition<->mesh-instance is
one-to-one), and hence, part IDs are unique in an mesh instance (and
parent-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.

  I think it sounds fine and we can support this.

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

  Not sure as of now.

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

   Sounds fine.

Thanks,
Onkar

> 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?
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CommInterface.h
Type: application/octet-stream
Size: 6415 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080204/2505776a/attachment.obj>