itaps-parallel Questions about iMeshP

Tue Dec 22 13:40:16 CST 2009

Tim,

It is not correct to state I agreed to iRel to meet the mesh-to-model 
relation need. I have since the first ITAPS meeting on Sept 11th (yes 
that Sept 11th) discussed the importance of effective mesh-to-model 
relationships and that they had to be a key part of what we did. Why do 
we bother with the abstraction of topology if we are not going to use 
it! As near as I and others can tell is it not part of the current iRel 
and until we have a solution to this issue that is actually useful there 
is not way that we can provide effective code.

I have heard no one other than you say that the current iRel can provide 
an effective solution. Until someone that does mesh modification on a 
regular basis, etc. indicates they agree and demonstrates exactly how to 
do that, it is very much an open issue and a style issue.

Mark

Tim Tautges wrote:
> 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
>>>>
>>>
>>
> 