[cgma-dev] Continuing discussion of iGeom handling of RefVolume vs Body
Patrick Shriwise
shriwise at wisc.edu
Mon Feb 9 07:59:13 CST 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20150209/e469f2bf/attachment.html>
More information about the cgma-dev
mailing list