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

Onkar Sahni osahni at scorec.rpi.edu
Mon Feb 4 18:15:13 CST 2008 

>
> Onkar:
>
> One question from our EntityLevelComments.txt:
>
>>  1) prefix_addCopyEnt will require remote_entity_handle along with
>>  remote_part_id (entity_handle is local on-process handle).
>>  prefix_removeCopyEnt may have either remote_part_id
>>  or remote_entity_handle (or both).
>
> How would a processor provide a remote entity handle for an entity it is
> copying into a remote part?  Say entity handles are addresses.  Then
> before
> the copy is added, how can a processor know its remote address?

  I don't know what you mean by "copying into a remote part". Let me
clarify in general, prefix_addCopyEnt is on-process call, where
entity_handle is on-process handle and entity exists on more than one
part. See Fig. 2 under Example 2 in attached examples document (same as
what I sent before), M^1_0 and M^1_1 are edges on P0 and P1,
respectively (where M^i_j follows latex syntax and denotes mesh entity
with dimension i (<=3) and local-on-part-entity-index j) and goes under
parallel split/subdivision. After split, M^1_3 and M^1_4 are created on
P0 and M^1_5 and M^1_6 are created on P1. M^1_3 is image of M^1_5 on P0
and vice-versa (and same for M^1_4 and M^1_6), so to link this
information in terms of remote copies we need prefix_addCopyEnt(). For
example, for prefix_addCopyEnt on P0, entity_handle=M^1_3 and
remote_entity_handle=M^1_5 and remote_part_id=P1 (of course M^1_5 and P1
are communicated to P0 before prefix_addCopyEnt). The arrows in Fig. 2
denotes messages. How does one know M^1_3 and M^1_5 needs to be linked
is through remote copy information for M^1_0 and M^1_1, parent edges (so
M^1_0 on P0 knows M^1_1, P1 as remote copy information and M^1_1 on P1
knows M^1_0, P0 as remote copy information). I hope I do not have typos.
Note that remote copy information is always maintained as migration
and/or parallel subdivision takes place (starting with serial mesh, on
one part, remote copy information evolves as mesh is
migrated/partitioned and while starting with parallel mesh it is
generated in loading of mesh).

Let me know if this is not clear.

- Onkar

>
> Karen
>
>
> On 2/4/08 1:58 PM, "Onkar Sahni" <osahni at scorec.rpi.edu> wrote:
>
>>
>>
>> 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 --------------
A non-text attachment was scrubbed...
Name: itaps_examples_rpi.1.0.pdf
Type: application/x-download
Size: 32146 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080204/75b7f996/attachment.bin>

More information about the itaps-parallel mailing list