[cgma-dev] Continuing discussion of iGeom handling of RefVolume vs Body
shriwise
shriwise at wisc.edu
Mon Feb 23 11:12:59 CST 2015
Adding to this discussion, I spoke with Tim Tautges this morning and he
had a few thoughts to add.
He prefers the option in which an iGeomEntityHandle pointer and an
integer for the number of entities returned are used to indicate the
result of these boolean operations we have been discussing. His
reasoning is that in iGeom EntitySets were intended to indicate the
state of the geometry to the user rather than for use as a container of
objects. He also saw it working better with the current c implementation
on the backend of this interface.
Just wanted to throw that into the mix for future reference.
Cheers,
Patrick
On 02/09/2015 07:59 AM, Patrick Shriwise wrote:
> Hi all,
>
> Are there any other thoughts on this? Or ideas on the proper steps
> forward for the iGeom implementation in CGM?
>
> Cheers,
>
> Patrick
>
>
> On 02/02/2015 12:43 PM, Patrick Shriwise wrote:
>> Hi Evan,
>>
>> As to 2). I completely agree and I think if I'm reading it correctly
>> its aligning with the second of my two purposed solutions in the
>> prior email.
>>
>> 1) does seem to add a complication or two. I'm glad you brought it up!
>>
>> I don't know much about how these bodies fit into the hierarchy of
>> CGM, but naively it seems that if they are still treated as
>> RefVolumes then operations on these sheets could be handled as usual
>> in CGM behind the iGeom interface. For the user, it might be good to
>> add something in iGeom which will notify them that a sheet
>> body/volume has been returned if it is a possibility in the function
>> they have called. What it looks like to me from this code in Body.cpp
>>
>> CubitBoolean Body::is_sheet_body()
>> {
>> DLIList<RefVolume*> volumes;
>> ref_volumes(volumes);
>> while (volumes.size())
>> if (!volumes.pop()->is_sheet())
>> return CUBIT_FALSE;
>> return CUBIT_TRUE;
>> }
>>
>> is that sheet bodies are still in fact treated as RefVolumes. However
>> after looking at some of the OCC code, sheets in OCC come back as
>> OCCSurfaces. I'm assuming that these are then translated to
>> RefVolumes in the context of CGM, but I lack the expertise to know
>> exactly. Does anyone have an exact answer to this?
>>
>> If we can still treat RefVolumes which are sheets in the same way as
>> other RefVolumes then I think returning only RefVolumes is still a
>> valid option. If we find that this is not the case or that it will
>> obscure the interface by causing certain operations to be
>> compromised, then we might have an entirely different problem to deal
>> with.
>>
>> Cheers,
>>
>> Patrick
>>
>>
>>
>>
>>
>>
>>
>> On 01/30/2015 12:20 PM, Vander Zee, Evan B. wrote:
>>>
>>> There are two additional things that we might want to consider in
>>> this discussion.
>>>
>>> 1)When are bodies that CGM is passing through the iGeom interface
>>> allowed to be “sheet bodies?” In other words, when should we be
>>> able to pass what are essentially 2-dimensional entities through the
>>> iGeom interface?
>>>
>>> 2)The input path of iGeom is a consideration as well as the output
>>> side. We can assume, I think, that the only entity handles a user
>>> passes into methods through the iGeom interface are entity handles
>>> that have been accessed through the iGeom interface. If we want to
>>> allow operations that apply to multiple volumes, but we never pass
>>> back entity handles that refer to multiple-volume bodies, then we
>>> should make sure that the interface includes methods that support
>>> passing in a list of entities or an entity set. For example, the
>>> interface already supports subtract with entity set arguments as
>>> well as with entity handles.
>>>
>>> I think that with a little documentation, we could expect users to
>>> be responsible for cleaning up single-entity entity sets that are
>>> returned from operations that could in some cases return multiple
>>> volumes. However, making it easier to use and not expecting a lot
>>> of the user is often the better path.
>>>
>>> These are just a few comments from a guy who’s relatively new to
>>> CGM. Please continue the discussion with comments from more
>>> experienced developers.
>>>
>>> -Evan
>>>
>>> *From:*cgma-dev-bounces at mcs.anl.gov
>>> [mailto:cgma-dev-bounces at mcs.anl.gov] *On Behalf Of *shriwise
>>> *Sent:* Friday, January 30, 2015 9:15 AM
>>> *To:* Paul Wilson; CGMA Development
>>> *Subject:* Re: [cgma-dev] Continuing discussion of iGeom handling of
>>> RefVolume vs Body
>>>
>>>
>>>
>>> Hi all,
>>>
>>> From an iGeom perspective, I'm not sure that using bodies is a bad
>>> thing... The real issue to me is the mix currently being used. It
>>> has been shown to cause problems in iRel. In any case, I think that
>>> we should move entirely to one or the other.
>>>
>>> The real issue to me is that outside of the user's knowledge of the
>>> geometry, they can't be sure if the body they are getting from
>>> UniteEnts, IntersectEnts, etc. contains disjoint volumes or not.
>>>
>>> *_Using RefVolumes Exclusively_*
>>> As it currently stands in specification, in the iGeom interface
>>> there is no notion of a body or, perhaps more importantly, an Entity
>>> which /contains/ other entities. There are only Entities and
>>> EntitySets. The point being that returning a recast cgm Body as an
>>> Entity from iGeom simply shouldn't be allowed as it breaks
>>> established conventions of iGeom unless we do one of two things:
>>>
>>> 1) Only return bodies as EntitySets which contain the appropriate
>>> Entities (these relationships being set within the functions being
>>> called.)
>>> - This would require
>>>
>>> 2) Return arrays of Entities from functions when appropriate, along
>>> with an indicator of the array size.
>>>
>>> Either way, a proper iGeom implementation will require a bit of a
>>> deeper look at any function that currently returns a Body to
>>> determine the proper way to handle this. For example, the
>>> createSphere function should really return a single RefVolume as the
>>> body created from this process wouldn't be expected to have more
>>> than one volume. However, I think that other functions like
>>> uniteEnts and so on will require something like 1) or 2) above.
>>>
>>> *_Using Bodies Exclusively_*
>>> All this being said about RefVolumes, it would certainly be possible
>>> to always return Bodies from iGeom for dimension 3 entities, but as
>>> I mentioned above I think this should always be done using
>>> EntitySets. This implementation would be less clean as iGeom models
>>> would then perhaps contain many EntitySets most of which really only
>>> contain one entity. The user would then have to retrieve their
>>> created entities proper by querying the EntitySets. It adds an
>>> unnecessary level of abstraction and might cloud the user's idea of
>>> what EntitySets are intended for.
>>>
>>> One last thing I'll say in favor of using RefVolumes exclusively but
>>> returning lists is that it adds clarity to the interface. By having
>>> boolean functions like uniteEnts and others return lists or
>>> EntitySets, it will imply to the user that iGeom is capable of doing
>>> these operations in the case of disjointed volumes and that they may
>>> be getting multiple volume entities back from these functions. If we
>>> were to return bodies only, it then becomes ambiguous (and perhaps
>>> confusing to the user) as to whether or not any function called is
>>> returning one or more volumes.
>>>
>>> That's my take. Apologies for the lack of insight in the changes
>>> found in the current PR. The situation is not as simple as I'd
>>> initially thought.
>>>
>>> Cheers,
>>>
>>> Patrick
>>>
>>> On 01/29/2015 03:17 PM, Paul Wilson wrote:
>>>
>>> Hello,
>>>
>>> There has been some discussion in a pull request
>>> <https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates>
>>> that I thought would be better brought to the mailing list.
>>>
>>> This was initially motivated by the realization that iGeom was
>>> inconsistent in returning a RefVolume vs a Body in different
>>> calls. Thus, two entity handles that referred to the same
>>> volume in space would not be detected as the same volume.
>>>
>>> Faced with two choices - refer only to RefVolumes or refer only
>>> to Body's - we settled on referring only to refVolume's in the
>>> iGeom interface. However, this breaks the ability to refer to a
>>> Body such as my be returned by uniting two volumes that are
>>> disjoint - which is part of the interface.
>>>
>>> So.... perhaps we need to only deal with Body in the iGeom
>>> interface. Perhaps Patrick can offer some of the downsides to
>>> this approach?
>>>
>>> Paul
>>>
>>>
>>> --
>>>
>>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>>>
>>> Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal:http://bit.ly/pphw-cal
>>>
>>> Professor, Engineering Physics. ~http://cnerg.engr.wisc.edu
>>>
>>> Faculty Director, Advanced Computing Infrastructure ~http://aci.wisc.edu
>>>
>>>
>>>
>>> --
>>> Patrick C. Shriwise
>>> Research Assistant
>>> University of Wisconsin - Madison
>>> Engineering Research Building - Rm. 428
>>> 1500 Engineering Drive
>>> Madison, WI 53706
>>> (608) 446-8173
>>
>> --
>> Patrick C. Shriwise
>> Research Assistant
>> University of Wisconsin - Madison
>> Engineering Research Building - Rm. 428
>> 1500 Engineering Drive
>> Madison, WI 53706
>> (608) 446-8173
>
> --
> Patrick C. Shriwise
> Research Assistant
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706
> (608) 446-8173
--
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20150223/86ffe6ac/attachment.html>
More information about the cgma-dev
mailing list