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

[Mark Beall]

On Jul 19, 2010, at 12:21 PM, Jason Kraftcheck wrote:

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

I don't really like the array idea, since I think that obscures the  
intent here. If there is a single argument that must be a part, then  
it is very simple to explain why its there and when and when not to  
pass something.

> 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

Would it make sense for an implementation to define a value that means  
NULL (for here and other places that it could be of use)? Passing the  
root set here could be confusing ("ah I see, everything is always  
added to the root set since I always have to pass it here. Oh wait,  
sometimes I don't have to pass it here, does that mean that this  
entity won't be added to the root set?")

mark