[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
Paul Wilson
wilsonp at engr.wisc.edu
Fri Jul 11 20:15:38 CDT 2014
Rajeev,
You are mentioned in the git logs as the inspiration for the copy_attrib
test that Patrick mentioned. (a few years ago)
I wonder if you have any thoughts on what the purpose and/or
requirements are for this capability? You probably needed it for RGG
based on OCC?
Paul
On 07/11/2014 07:21 PM, Patrick Shriwise wrote:
> Hi all,
>
> I'm currently working on the changes to iGeom that Paul previously
> proposed. I've hit one test when built with OCC (copy_attrib) that
> suggests that tags are expected to be copied along with an entity when
> using iGeom functions like copyEnt or subtractEnt. Is this the case?
> Are these specifc tags that are supposed to be copied if they exist on
> the original entity?
>
> Also to be clear this has become an issue because for volume entities
> we now use the RefVolume to get the volume Body and make a copy of
> that body using the GeometryModifyTool. The Body we make a copy of
> does not have the tags associated with the RefVolume. As a result the
> new Body and the corresponding RefVolumethat we return from the
> function does not have the original tags.
>
> These tags can be transferred to the new entity before leaving the
> function of course, but we're looking for the proper way to handle
> this situation. Mainly it would be good to know if there is a
> particular tag or tags that should be copied over to new entity upon
> it's creation.
>
> Cheers,
>
> Patrick
>
>
> On 06/23/2014 03:06 PM, Paul Wilson wrote:
>> Hi everyone,
>>
>> Patrick and I have discussed this and have come up with the following
>> proposal for a revision of how iGeom_CGMA handles RefVolumes and Body's.
>>
>> 1. All references to iBase_REGION will refer only to entities of
>> type RefVolume in CGM.
>> 2. All entities that are returned by iGeom will be RefEntities and
>> not CubitEntities
>> 3. At the time of loading file, based on an option based to
>> iGeom_load(), all entities of type Body in CGM that contain more
>> than a single volume, will be converted to RefGroup's and tagged
>> to distinguish them from the original RefGroup's
>>
>> The last of these may be subject to the most conversation, but it
>> seemed like a useful approach to use because it:
>>
>> * had little to no effect on the API of iGeom
>> * preserves access to CGM/ACIS bodies
>> * is the least intrusive in the implementation of iGeom_CGMA
>>
>> If a user does NOT pass in the option (e.g. "CONVERT_BODY_TO_GROUP"),
>> then no bodies will be accessible through iGeom. If a user does pass
>> in this option, any call to iGeom_getEntSets will return both the
>> original RefGroups and the additional RefGroups that were generated
>> automatically from Bodies. It will be up to the user to filter
>> between them using the available tag.
>>
>> Finally, since every RefVolume in ACIS always has a Body in which it
>> is a member, it seems best to only convert Bodies that contain >1
>> RefVolume to avoid creating far more RefGroups than necessary.
>>
>> We'd like to embark on these changes soon, but welcome any comments
>> or feedback. I'm sure we've missed something!
>>
>> Paul
>>
>>
>> On 06/17/2014 09:00 AM, Jane Hu wrote:
>>> So, I will add RefVolume to the return list
>>> of iGeom_get_adjacent_entities() as the result of the discussion.
>>>
>>> CubitEntity only has derived classes of RefEntity
>>> and CubitCoordinateSystem, iGeom_CGMA.cc only uses RefEntity as
>>> instance of the object.
>>>
>>> Jane
>>>
>>>
>>> On Mon, Jun 16, 2014 at 11:35 AM, Jane Hu <janejhu at gmail.com
>>> <mailto:janejhu at gmail.com>> wrote:
>>>
>>> See comments below...
>>>
>>>
>>> On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson
>>> <wilsonp at engr.wisc.edu <mailto:wilsonp at engr.wisc.edu>> wrote:
>>>
>>> Hi Jane,
>>>
>>> I think this needs a thorough review! Patrick and I hunted
>>> through iGeom_CGMA and found some inconsistencies in a few
>>> places.
>>>
>>> First, there is an inconsistency between returning pointers
>>> to RefEntity and pointers to CubitEntity. This is probably
>>> less important, but should probably be resolved in any change.
>>>
>>> I see RefEntity is inherited from CubitEntity, and CubitEntity
>>> is a pure virtual class. So even you got pointers to
>>> CubitEntity, you have to instantiate it to RefEntity objects.
>>>
>>>
>>> Second, there are places where the geometry is queried for
>>> entities of dimension=3 (returning RefVolumes) and places
>>> where the geometry is queried for entities of
>>> type=iGeom_REGION (== Body).
>>>
>>>
>>> In this case, I can return both bodies and refvolumes, so after
>>> user gets the refentity list back, he can cast to see if they
>>> are bodies or refvolumes, and choose to keep what ever he needs.
>>>
>>>
>>> This means that 2 calls into the interface that should
>>> resolve to the same entity may not do so for both reasons.
>>>
>>> All of this is related to the fundamental difference between
>>> the iGeom types (equivalent to vertex, edge, face, volume)
>>> and the CGM/ACIS types (equiavlent to vertex, edge, face,
>>> volume, body). I think Tim's suggestion is the best, but
>>> will require some substantial effort.
>>>
>>> Paul
>>>
>>>
>>> On 06/16/2014 10:14 AM, Jane Hu wrote:
>>>> I see in iGeom_CGMA.cc file,
>>>> function iGeom_get_adjacent_entities, if asks for 3-D
>>>> refentities, it returns body list. In CGM, bodies are not
>>>> necessary to be 3-D entities, it may contain single surface
>>>> or shell. Should we change the return to be only refvolumes
>>>> which are 3-D entities (I prefer this, makes more sense)?
>>>> Or I can return both bodies and refvolumes in the returned
>>>> refentity list. Depending on your user case, I can return
>>>> one of the two choices.
>>>>
>>>> Jane
>>>>
>>>>
>>>> On Mon, Jun 16, 2014 at 9:32 AM, Jane Hu <janejhu at gmail.com
>>>> <mailto:janejhu at gmail.com>> wrote:
>>>>
>>>> Yes, it returns a list of refVolume's which are
>>>> RefEntities.
>>>>
>>>> Jane
>>>>
>>>>
>>>> On Sun, Jun 15, 2014 at 11:55 PM, Patrick Shriwise
>>>> <shriwise at wisc.edu <mailto:shriwise at wisc.edu>> wrote:
>>>>
>>>> Hi Jane,
>>>>
>>>> Will the ref_volumes() method return RefEntities?
>>>>
>>>> Patrick
>>>>
>>>> On Jun 15, 2014, at 3:56 PM, Jane Hu
>>>> <janejhu at gmail.com <mailto:janejhu at gmail.com>> wrote:
>>>>
>>>>> Look at line 6454, if you have body's pointer,
>>>>> directly call ref_volumes() will work. It's not an
>>>>> iGeom interface function, but you can access it in
>>>>> iGeom.
>>>>>
>>>>> Good luck!
>>>>>
>>>>> Jane
>>>>>
>>>>>
>>>>> On Sat, Jun 14, 2014 at 8:55 AM, Patrick Shriwise
>>>>> <shriwise at wisc.edu <mailto:shriwise at wisc.edu>> wrote:
>>>>>
>>>>> Hi Jane,
>>>>>
>>>>> I looked around for this but didn't see it, is
>>>>> there a specific line/function you were
>>>>> thinking of? Good to know the ref_volume
>>>>> information is so easy to get to, but it
>>>>> doesn't seem that its part of the iGeom
>>>>> interface. The issue being that there's no way
>>>>> to access a body's volumes via iGeom.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Patrick
>>>>> On 06/13/2014 11:26 PM, Jane Hu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is there a way to get volumes within
>>>>>> bodies via iGeom?
>>>>>>
>>>>>>
>>>>>> See example in iGeom_CGMA.cc,
>>>>>> body->ref_volumes(volumes).
>>>>>>
>>>>>> Jane
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Patrick C. Shriwise
>>>>>> Research Assistant
>>>>>> University of Wisconsin - Madison
>>>>>> Engineering Research Building - Rm. 428
>>>>>> 1500 Engineering Drive
>>>>>> Madison, WI 53706
>>>>>> (608) 446-8173 <tel:%28608%29%20446-8173>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jane Hu
>>>>>>
>>>>>> Asst. Researcher
>>>>>> Dept. of Engineering Physics
>>>>>> UW @ Madison
>>>>>>
>>>>>> "And we know that for those who love God,
>>>>>> that is, for those who are called according
>>>>>> to his purpose, all things are working
>>>>>> together for good." (Romans 8:28)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jane Hu
>>>>>
>>>>> Asst. Researcher
>>>>> Dept. of Engineering Physics
>>>>> UW @ Madison
>>>>>
>>>>> "And we know that for those who love God, that is,
>>>>> for those who are called according to his purpose,
>>>>> all things are working together for good." (Romans
>>>>> 8:28)
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jane Hu
>>>>
>>>> Asst. Researcher
>>>> Dept. of Engineering Physics
>>>> UW @ Madison
>>>>
>>>> "And we know that for those who love God, that is, for
>>>> those who are called according to his purpose, all
>>>> things are working together for good." (Romans 8:28)
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jane Hu
>>>>
>>>> Asst. Researcher
>>>> Dept. of Engineering Physics
>>>> UW @ Madison
>>>>
>>>> "And we know that for those who love God, that is, for
>>>> those who are called according to his purpose, all things
>>>> are working together for good." (Romans 8:28)
>>>
>>> --
>>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>>> Paul Wilson ~ UW-Madison ~608-263-0807 <tel:608-263-0807> ~ cal:http://bit.ly/pphw-cal
>>> Professor, Engineering Physics. ~http://cnerg.engr.wisc.edu
>>> Faculty Director, Advanced Computing Infrastructure
>>>
>>>
>>>
>>>
>>> --
>>> Jane Hu
>>>
>>> Asst. Researcher
>>> Dept. of Engineering Physics
>>> UW @ Madison
>>>
>>> "And we know that for those who love God, that is, for those who
>>> are called according to his purpose, all things are working
>>> together for good." (Romans 8:28)
>>>
>>>
>>>
>>>
>>> --
>>> Jane Hu
>>>
>>> Asst. Researcher
>>> Dept. of Engineering Physics
>>> UW @ Madison
>>>
>>> "And we know that for those who love God, that is, for those who are
>>> called according to his purpose, all things are working together for
>>> good." (Romans 8:28)
>>
>> --
>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>> 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
>
> --
> Patrick C. Shriwise
> Research Assistant
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706
> (608) 446-8173
--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140711/4a1cfb26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140711/4a1cfb26/attachment-0001.bin>
More information about the cgma-dev
mailing list