[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
Paul Wilson
wilsonp at engr.wisc.edu
Wed Jul 16 00:09:53 CDT 2014
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>
> *To:* Paul Wilson <wilsonp at engr.wisc.edu>; "Jain, Rajeev"
> <jain at mcs.anl.gov>; CGMA Development <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
Faculty Director, Advanced Computing Infrastructure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140716/c07dfc5e/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/c07dfc5e/attachment-0001.bin>
More information about the cgma-dev
mailing list