[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
Paul Wilson
wilsonp at engr.wisc.edu
Wed Jul 16 09:16:44 CDT 2014
Patrick,
I think there is a global ID tag (or something similar) that should
probably NOT be overwritten. I am not sure of others...
Paul
On 07/16/2014 09:15 AM, Patrick Shriwise wrote:
> 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
--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
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/20140716/949c53a0/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/20140716/949c53a0/attachment-0001.bin>
More information about the cgma-dev
mailing list