itaps-parallel Questions about iMeshP

[Devine, Karen D]

Mark B:

Thank you for taking the time to organize the entity set functions with
respect to their usefulness with parts.  I should have done such an exercise
when we designed iMeshP.

For your implementation, starting with just the four functions that "make
sense" is reasonable.  Our group should discuss whether these are, indeed,
the only functions that make sense and if so, whether have part-specific
functions for these four would make the interface more user-friendly.

Using your email as a starting point, I'll put together a proposal and call
the appropriate phone conference in January for an interface revision
meeting.  Would you be interested in attending that phone conference?

Karen


On 12/21/09 6:25 PM, "Mark Beall" <mbeall at simmetrix.com> 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
>> 
> 
> 
>