itaps-parallel Questions about iMeshP

[Mark Beall]

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
>