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

Mon Feb 4 14:58:57 CST 2008

I have attached other part of assignment on entity functionality.

As I mentioned earlier, a function to get residence parts of an entity on
inter-part boundary will be helpful. See example in the end of attachment.

Thanks,
Onkar

>
> 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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: EntityLevelComments.txt
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080204/8a1c2c54/attachment.txt>