itaps-parallel Questions about iMeshP

[Tim Tautges]

First: it's very true that we agreed to that for iMeshP, and thanks for the reminder.  I think we should clarify the 
documentation on exactly what iMesh functions should function when passed a Part handle (which was also part of that 
agreement).

Second: whether or not the current iRel spec can support Mark B's model-mesh needs is not open.  The question is one of 
style.  Also, the current iRel spec was also agreed to, at least by Mark S; that includes the pending change eliminating 
"association" in favor of "relation".

- tim

Mark Shephard wrote:
> As a quick reminder. We had an entire boot-camp on iMeshP and it was 
> clearly decided that iMeshP was to be defined such that is was 
> independent of mesh sets and that implementations could decide if they 
> wanted to use mesh sets as the core of their implementation or not.
> 
> It is for the same reasons that that having simple and direct 
> mesh-to-model and model-to-mesh functions is of importance. This has 
> also been discussed for a long time (way back in TSTt) with an 
> indication it would be addressed. It is still open.
> 
> The current discussion continues to expand, which is useful for gaining 
> a better understanding of how ITAPS mesh sets work and how one can use 
> them for various things. However, one way or the other the issue of 
> defining the needed mesh-to-model and model-to-mesh functions is not 
> being addresses. Mark Beall has provided a specific recommendation for 
> such functions. If we want to progress on understanding how to get ITAPS 
> implementation of iMesh and iGeom working with each other, we need to 
> get back to this issue and get it resolved.
> 
> Mark
> 
> Mark Beall wrote:
>> I can give our perspective on an answer to that question. We have a 
>> partitioned mesh implementation that is not implemented using entity 
>> sets. Thus, the question is which entity set functions would we 
>> support in this case. I've broken up the entity set functions below 
>> into various groups as described below. The short summary is that our 
>> implementation will only support the four functions listed in the 
>> initial set. That may, or may not, be considered a woefully 
>> incompletely implementation of iMeshP.
>>
>> Entity set functions that make sense (meaning that I need to have this 
>> functionality for a part) for an implementation that does not 
>> implement parts as entity sets:
>> iMesh_addEntToSet
>> iMesh_rmvEntFromSet
>> iMesh_addEntArrToSet
>> iMesh_rmvEntArrFromSet
>>
>> Entity set functions that I'm not actually sure make sense as 
>> fundamental operations on entity sets. Is there any way to implement 
>> these that isn't just as efficient as they could be written through an 
>> iterator? If not, then it seems they would be better implemented once 
>> as a service that builds on the interface (and then could be used with 
>> anything that provides an iterator, not just sets).
>> iMesh_subtract
>> iMesh_intersect
>> iMesh_unite
>>
>> Entity set functions have equivalent functionality in iMeshP:
>> iMesh_createEntSet
>> iMesh_destroyEntSet
>> - these sets are not something that the user can create and destroy 
>> this way, you create and destroy parts
>>
>> iMesh_isEntContained
>> iMesh_isEntArrContained
>>
>> iMesh_initEntArrIter
>>
>> iMesh_isList
>> - parts are unordered
>>
>> Entity set functions that fundamentally don't make sense for an 
>> implementation that doesn't implement parts as entity sets. As I 
>> stated in a previous email, it doesn't make sense to enforce the 
>> semantics of set containing sets for an implementation that doesn't 
>> implement things that way.
>> iMesh_getNumEntSets
>> iMesh_getEntSets
>> iMesh_addEntSet
>> iMesh_rmvEntSet
>> iMesh_isEntSetContained
>>
>> Entity set functions that provide other functionality that I'm unsure 
>> of the value with parts. We wouldn't implement these until there was a 
>> clear demonstration of value that couldn't be obtained otherwise.
>> iMesh_addPrntChld
>> iMesh_rmvPrntChld
>> iMesh_isChildOf
>> iMesh_getNumChld
>> iMesh_getNumPrnt
>> iMesh_getChldn
>> iMesh_getPrnts
>>
>> iMesh_setEntSetData
>> iMesh_setEntSetIntData
>> iMesh_setEntSetDblData
>> iMesh_setEntSetENData
>> iMesh_getEntSetData
>> iMesh_getEntSetIntData
>> iMesh_getEntSetDblData
>> iMesh_getEntSetEH_data
>> iMesh_getAllEntSetTags
>> iMesh_rmvEntSetTag
>>
>>
>> On Dec 21, 2009, at 2:31 PM, Tim Tautges wrote:
>>
>>> 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
>>>
>>
> 

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