[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
shriwise
shriwise at wisc.edu
Tue Jul 15 10:29:56 CDT 2014
Bump.
On 07/11/2014 08:15 PM, Paul Wilson wrote:
> 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
--
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/20140715/4b94fce0/attachment-0001.html>
More information about the cgma-dev
mailing list