itaps-parallel Re: Assignments for parallel interface

[Devine, Karen D]

Hi, Carl.  Thanks for your comments.  Please see my follow-ups below.  If I
don't provide a follow-up, I either don't know the best answer or I
generally agree and will update the document appropriately.  (You'll have to
guess which case is true.  :)

Karen


On 2/4/08 12:42 PM, "Carl Ollivier-Gooch" <cfog at mech.ubc.ca> wrote:

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

I think part IDs should always travel with partition handles, since part IDs
often refer to off-process parts.  So they have to be unique only with
respect to a partition.  Then your scheme would allow a billion part IDs per
partition.  Very cool!!!  I hadn't thought about how to assign the part IDs,
though; I like to push everything into the implementation.  :)

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

Throughout the interface, I assumed part handles were valid only locally.
I'll make that clearer in the comments.

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

My comments for getNumPartNbors/getPartNbors failed to mention that entity
type is an input.  From our phone conversations, we decided Part A
"neighbors" Part B if A and B share entities of a given dimension; functions
computing part neighbors will accept an entity type (possibly
iBase_ALL_TYPES).  I'll update the comments.

I don't know the answer on the communicating vs. pre-computed question.
Whatever we decide, we'll have to document it.  This question seems related
to getting adjacency info at part boundaries.

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

You are correct that every entity needs an "owner" with right-to-modify.  We
had said that part assignments computed with respect to a set of entities
would induce part assignments to lower-dimensional entities in an
implementation-dependent fashion.  That is, if a partition is computed with
respect to regions, queries about ownership of faces and vertices are valid.
Is it more correct to say that a partition should be able to induce part
assignments on all entities adjacent (in any manner) to entities involved in
computing the partition?  I'm OK with that, but we should state it clearly.

An error would be returned, then, only if an entity that isn't adjacent to
any of the partitioned entities is requested.  For example, say entity set A
contains a mesh and entity set B contains another mesh completed separate
from set A.  If we partition set A, and then call getEntityOwner with
partition A and an entity in set B, getEntityOwner returns an error.  Does
that seem correct?

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

Yes, I go both ways on this issue.  It is more object-oriented and
extensible to use the tuples.  But it's just so darned convenient to allow
the part handles to be interchangeable with set handles.

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