itaps-parallel Questions about iMeshP

[Mark Beall]

For our implementation we will be able to tell whether it's an entity  
set handle or a part handle and act appropriately (I can come up with  
implementations that couldn't, but they could always use the same  
approach that we will - the cost is a few if-statements or a virtual  
function call).

My main issue is just making sure that we understand what functions we  
have to support (and that it's clear to users what they should expect  
to work across all implementations).

On my proposal I'll just say a few things:
- I think the idea of a "read only" entity set could be useful since  
it gives a standard way to document this kind of situation (and a  
useful error to throw if someone tries to modify one)
- Having separate function to add/remove from parts gives a useful  
place to document things related to that action that wouldn't really  
fit well in the entity set functions
- There is no functional difference between this and the current  
implementation, it's mainly a question of style.

mark

On Dec 18, 2009, at 3:35 PM, Devine, Karen D wrote:

>
> Mark B.:  You are correct that the documentation is confusing.  Our  
> hope was
> that an implementation could differentiate between an entity set  
> handle and
> a part handle, and react differently based on the handle type.  Thus,
> overloading some entity set functions to work on parts with part  
> handles
> would allow the iMeshP interface to be smaller.  Do you think this  
> approach
> is infeasible for at least some of the functions?  You are probably  
> correct
> that not all entity set functions make as much sense in the part  
> context; we
> can correct the documentation for those.
>
> All:  What do you think of Mark B's proposal that parts be "read-only"
> entity sets and have part-specific add/remove functions?  Also, we  
> should go
> through the iMesh interface carefully and determine for which  
> functions the
> overloading is appropriate and for which functions it is not.  If we  
> now
> agree that the entire approach is infeasible, we should define the  
> part
> functions needed to complete iMeshP.
>
> Karen
>
>
> On 12/16/09 9:30 AM, "Mark Beall" <mbeall at simmetrix.com> wrote:
>
>> In reading things again, there is this bullet above the one I quoted:
>>
>> - Many iMesh functions that accept an iBase_EntitySetHandle are also
>> useful in the context of a iMeshP_PartHandle. These functions are
>> reinterpreted so that they can accept either an iBase_EntitySetHandle
>> or an iMeshP_PartHandle.
>> What, exactly, does this imply? My concern is that it means that a
>> part has to behave as an entity set for a call like iMesh_addEntSet
>> (which adds an entity set to an existing set). The semantics of an
>> entity set say that, if I make this call, the entity set that I added
>> would have to be returned if I subsequently called iMesh_getEntSets  
>> on
>> that part.
>> I don't really see how an implementation that doesn't represent parts
>> as entity sets could reasonably be expected to do this.
>> If the intention isn't to require the above to work that way, it  
>> would
>> seem that it would be better to say that a part is a "read-only"
>> entity set and that there be part-specific functions to add/remove
>> entities to/from a part. It seems to me that this would allow
>> efficient implementations whether or not they are done using entity
>> sets.
>> mark
>> On Dec 15, 2009, at 4:06 PM, Mark Beall wrote:
>>
>>>
>>> On Dec 15, 2009, at 2:14 PM, Tim Tautges wrote:
>>>
>>>>>>
>>>>>> 4. It is mentioned that a part can act as an entityset. Since
>>>>>> entitysets
>>>>>> can have parent-child and containment relationships with other
>>>>>> entitysets, does this mean that parts need to have them too? If
>>>>>> so, it
>>>>>> is undefined what this means with respect to the partitioning. If
>>>>>> not,
>>>>>> what is the expected course of action when a part is used in an
>>>>>> iMesh
>>>>>> entityset function call which would result in a hierarchical
>>>>>> relationship?
>>>>>>
>>>>> The only API requirement is that the functions for querying the
>>>>> contents of
>>>>> sets also work for parts.  Whether or not those functions that
>>>>> *modify* sets
>>>>> (either contents or parent/child links) can be called on a part is
>>>>> implementation-dependent.
>>>>
>>>> Actually, the v0.8 iMeshP.h states that *all* functions in the
>>>> serial interface taking sets should also work for parts.  So, I
>>>> think that includes things like parent/child relations.  Same goes
>>>> for contains relations. I think that does imply the need for a
>>>> recursive getEntities function (which I have in a set of extensions
>>>> to iMesh, BTW).
>>>
>>> One thing it does say is the following:
>>>
>>> - In particular, entities are added to and removed from local parts
>>> via the same functions that are used to manipulate entity sets. That
>>> is, given a mesh instance, an entity handle, and a part handle, the
>>> entity is added to or removed from the part via calls to the
>>> following functions with the part handle passed as the entity set
>>> handle:
>>> - Add entity to part --> iMesh_addEntToSet
>>> - Remove entity from part --> iMesh_rmvEntFromSet
>>> - Add array of entities to part --> iMesh_addEntArrToSet
>>> - Remove array of entities from part --> iMesh_rmvEntArrFromSet
>>>
>>> I didn't re-read the entire thing again to see if it says that all
>>> other functions taking sets should also work for parts. However, if
>>> that is the case, it would seem that that requires an implementation
>>> that actually represents parts as entity lists.
>>>
>>> mark
>>>
>>
>>
>>
>
>