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

[Onkar Sahni]

> Carl wrote:
>
>
> 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 agree that we need to reserve constant part IDs on each process/rank
('m' bits). I think we may also want to allow for more than 31 bits for
part IDs and thus, use iPartID_type (typedef to appropriate type like
32-bit-int and it may be decided by application during compile time). In
the same context, we may want to revisit routines like
prefix_getNumPartIds. Do we really need them for each rank?

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

  I think part-handles are always local on-process ones.

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

  I think the reason to support this is to have this pre-commuted. These
are maintained and updated during mesh migration and parallel
sub-division (send/recieveEntArr and add/rmvCopy).

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

  I thought this is for any arbitrary entity. Actually I may have added to
confusion by referring 'entity functionality' as 'functionality for
inter-part boundary entities' but I agree that it allows for
non-inter-part boundary entities too like prefix_getEntityParStatus for
internal mesh faces or regions.

- Onkar