[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
Patrick Shriwise
shriwise at wisc.edu
Wed Jul 16 09:15:12 CDT 2014
Are there any default tags that are automatically generated upon
creating a new entity in cgm? If so, should those be overwritten by the
tags from the original entity we are copying?
Patrick
On 07/16/2014 02:35 AM, Rajeev Jain wrote:
> I think all of the tags should get copied, but there might be use
> cases (in-future, I can't think of a case now) where making things
> more general and allowing a user option for selective or complete
> copying of tags might prove useful.
>
> Rajeev
>
> ------------------------------------------------------------------------
> *From:* Paul Wilson <wilsonp at engr.wisc.edu>
> *To:* "Jain, Rajeev" <jain at mcs.anl.gov>; shriwise <shriwise at wisc.edu>;
> CGMA Development <cgma-dev at mcs.anl.gov>
> *Sent:* Wednesday, July 16, 2014 12:09 AM
> *Subject:* Re: [cgma-dev] Inconsistency in getEntities for iGeom
> interface. Causes problems in iRel.
>
> Hi Rajeev,
>
> Thanks for the response. I guess it's still not clear what the
> expected behavior should be when copying an entity in iGeom. Should
> it copy some/none/all of the tags to the new entity? Is there a
> standard for what gets copied?
>
> Paul
>
>
>
> On 07/15/2014 08:26 PM, Rajeev Jain wrote:
>> Sorry, I missed this email.
>> Yes, you are right. It is for OCC based meshing. The test names
>> volumes/surfs etc and then tries to retrieve them.
>> You can ignore the test case as we started working on developing
>> other missing pieces for OCC geometry based meshing in MeshKit. When
>> entities are copied the names can be copied with some an additional
>> letter word under some convention.
>> Ex. CUBIT uses vol 1 named as mysteel when copied the new vol 2 is
>> called mysteel at a etc.
>>
>> Rajeev
>>
>> ------------------------------------------------------------------------
>> *From:* shriwise <shriwise at wisc.edu> <mailto:shriwise at wisc.edu>
>> *To:* Paul Wilson <wilsonp at engr.wisc.edu>
>> <mailto:wilsonp at engr.wisc.edu>; "Jain, Rajeev" <jain at mcs.anl.gov>
>> <mailto:jain at mcs.anl.gov>; CGMA Development <cgma-dev at mcs.anl.gov>
>> <mailto:cgma-dev at mcs.anl.gov>
>> *Sent:* Tuesday, July 15, 2014 10:29 AM
>> *Subject:* Re: [cgma-dev] Inconsistency in getEntities for iGeom
>> interface. Causes problems in iRel.
>>
>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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 ~ cal:http://bit.ly/pphw-cal
>>>>>> Professor, Engineering Physics. ~http://cnerg.engr.wisc.edu <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 <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 <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 <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/20140716/dbd5ad74/attachment-0001.html>
More information about the cgma-dev
mailing list