itaps-parallel Questions about iMeshP

[Tim Tautges]

I don't have a problem making parts read-only, though I question then how one builds partitions.

In terms of duplicating functions in iMesh to specialize for Parts, if we do that, then I question why we even have an 
abstraction for sets, if we're not going to use it for something like this?

At minimum, before even considering adding something like that to the interface, I'd want to see somebody write up a 
paragraph contrasting Parts and entity sets and explaining why distinct things in the data model are used.  Not for 
justification to me, but for explanation to our users, who I'm certain will be asking that question.  If the choice is 
so clear, it should be easy to describe in a short amount of space.

I agree that we need more documentation all around (I've just sent out the one I wrote on iRel, to a smaller group, but 
if you're curious let me know and I'll send a copy).

- tim

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

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706