itaps-parallel Questions about iMeshP

[Mark Shephard]

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