itaps-parallel Two options from today's iMeshP phone conference

[Jason Kraftcheck]

Saurabh Tendulkar wrote:
> 
> 
> On 07/16/10 20:00, Carl Ollivier-Gooch wrote:
>> On 10-07-16 04:21 PM, Devine, Karen D wrote:
>>>
>>> A. Change the iMesh_createEnt function to include an entity set handle
>>> argument PH. For serial applications, PH would be the root set; that is,
>>> entities are added only to the root set. For parallel applications, PH
>>> would be a part handle; the created entity would be added to the part
>>> identified by the part handle. Since iMesh_createEnt is an iMesh
>>> function
>>> (not an iMeshP function), we would use entity set handle as the argument
>>> type, so that serial users would not have to include iMeshP.h nor
>>> link with
>>> iMeshP. This option was generally accepted by Carl, Simmetrix, Sandia
>>> and
>>> RPI. Tim is in favor of adding the argument, but does not like the
>>> restriction of the handle to be either the root set or a part handle. My
>>> fear in allowing arbitrary entity set handles to be used is as
>>> follows: if
>>> a service uses the entity set handle to, say, add entities to a boundary
>>> condition set, that service could not be used in parallel, as its
>>> iMesh_createEnt calls would not add the entities to a part.
>>>

[snip]

> 
> I think for A, we proposed that the argument be NULL in case of serial.
> If we want no restriction in iMesh, then maybe we can instead pass an
> array of entity sets to iMesh_createEnt, and then in iMeshP stipulate
> that one of them has to be a part.
> 

Logically null.  Not literally 'NULL' (a bit-wise zero value).  Not all
implementations use pointer-based handles, and therefore zero is not an
invalid handle value for all implementations.  The closest thing we have to
a logical null is the root set (as everything goes into the root set anyway.)

- jason