itaps-parallel Questions about iMeshP
Tim Tautges
tautges at mcs.anl.gov
Tue Dec 22 14:07:09 CST 2009
Whatever. Can you point me to the specific email (date & time, I think I have them still in the trash) where it is
(concisely) described what can't be done with the current interface?
- tim
Mark Shephard wrote:
> 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
>>>>>
>>>>
>>>
>>
>
>
--
================================================================
"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
More information about the itaps-parallel
mailing list