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

[Carl Ollivier-Gooch]

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.

I actually got this nearly done a week ago, but didn't get it sent until 
now...

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

This is probably a good idea, for those who both (a) choose to program 
on a part-by-part basis rather than process-by-process and (b) choose to 
use sets for various things.  I've got no objection.

> -  Review in detail the Part Functionality section.

createPart:  How do we envision the adjudication of global part ID's?
Does part creation imply a request to some oracle for a part ID?  Does
each process have its own unique space for part ID's?  Using n bits for
process rank, m bits for local ID would create part ID's that were easy
to create and interpret...  with cleverness, we could work things so
that n+m <= 31 (a billion part ID's...) so that this all looks like an 
int, and we don't have to mess with the sign bit.

destroyPart: Setting handles to NULL on destruction assumes implicitly
that no implementation will ever use 0 as a valid part handle.  While it
might be a good idea to invalidate the handle, the invalid value may
have to be implementation dependent.

getPartIdsFromPartHandle: The part handle presumably must be local here;
this should be added to the comment.

getNumPartNbors/getPartNbors: communicating or pre-computed?  If the
latter, how/when are these updated?  And again, how are we defining
which parts are neighbors?

Part and part bdry iterators:  I don't have (at least at this point) a
firm opinion about whether we should have separate functions to
increment, reset, and destroy these iterators.  It's pretty easy to
argue that, semantically, the iterator should know how to do those
things for itself, and that it isn't too hard for an implementation to
handle that internal state.

--------------------------

One entity-related comment:

getEntityOwner:  I disagree with Karen.  I think it -does- make sense to
be able to determine the owner of an arbitrary entity.  We have agreed
that exactly one part will have ownership of an entity in the
right-to-modify sense, and IMO this is what this call should return.  We
may also need functionality to identify the entities that were used in
-determining- the partition, but I see that as a different issue.

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

My concern here is that this is a potentially difficult constraint for 
implementations that want to use integer part handles.  Somehow, they 
have to coordinate all partitions active in an instance to produce 
unique integer ID's.  Also, part handles will have to be unique from set 
handles as well.  (Again, not a problem with pointers, but potentially a 
problem for integer handles.)  I'm not saying that I expect to implement 
handles as ints, but it's not an unreasonable choice, and we want to be 
careful not to exclude it without good reason.

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

See above.

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

No objection.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------