July 2014 - cgma-dev - mailman3.cels.anl.gov

CGM-14.0 Release (SIGMA 1.0)
by Vijay S. Mahadevan 25 Jul '14

25 Jul '14

Dear CGM users, We are pleased to announce the release of CGM-14.0 which is now part of the Scalable Interfaces for Geometry and Mesh based Applications (SIGMA) tools. The tarball for the release is available for download from http://sigma.mcs.anl.gov/downloads. The release notes for all the packages as part of SIGMA are available at http://sigma.mcs.anl.gov/sigma/sigma-release-1-0. Please upgrade from 13.x and lower to the latest version in order for us to help you better use the tools. Some important updates for CGM include: # Fix stack smashing issues found on Intel builds while loading using function: iGeom_load_cub_geometry. # CMake-based builds are now supported. Note that CMake scripts do not yet support parallel/MPI builds # Improved Doxygen support; Documentation available at http://ftp.mcs.anl.gov/pub/fathom/cgm-docs/ # Several other miscellaneous bug fixes, enhancements throughout the library. More information at http://sigma.mcs.anl.gov/sigma/sigma-release-1-0. As always, send us an email at cgma-dev(a)mcs.anl.gov, if you have any questions on configuration/build/install procedures. Thank you, Vijay and SIGMA team

1 0

iGeom tag data on copied ent bug
by Patrick Shriwise 22 Jul '14

22 Jul '14

Hey all, While working on the updates to the iGeom interface I've come across a bug. When copying entities, tag data on the copy cannot be retrieved for some reason. I've added a simple test to testgeom.cc to show this. It is in my cgm fork under a branch named add_tests_iGeom (http://bitbucket.org/pshriwise/cgm/branch/add_tests_iGeom) This test fails in both ACIS and iGeom. Any thoughts on why this might be? Cheers, -- Patrick C. Shriwise Research Assistant University of Wisconsin - Madison Engineering Research Building - Rm. 428 1500 Engineering Drive Madison, WI 53706 (608) 446-8173

1 0

Re: [cgma-dev] Sigma website
by Rajeev Jain 18 Jul '14

18 Jul '14

Thanks for reporting this. I'll fix it. Rajeev ________________________________ From: Patrick Shriwise <shriwise(a)wisc.edu> To: "cgma-dev(a)mcs.anl.gov" <cgma-dev(a)mcs.anl.gov> Sent: Friday, July 18, 2014 8:49 AM Subject: [cgma-dev] Sigma website Hi all, I think the description of make_watertight is quite good. I don't have anything to add to it. I did notice on the EBMesh page I was seeing some strange text around hyperlinks that I don't think is expected. Thought I'd let you know. Looks something like this : Â MeshKitÂ Here's the page at which I was seeing it: http://sigma.mcs.anl.gov/?p=795 Cheers, -- Patrick C. Shriwise Research Assistant University of Wisconsin - Madison Engineering Research Building - Rm. 428 1500 Engineering Drive Madison, WI 53706 (608) 446-8173

1 0

Sigma website
by Patrick Shriwise 18 Jul '14

18 Jul '14

Hi all, I think the description of make_watertight is quite good. I don't have anything to add to it. I did notice on the EBMesh page I was seeing some strange text around hyperlinks that I don't think is expected. Thought I'd let you know. Looks something like this : ï¿½ MeshKit <http://sigma.mcs.anl.gov/?page_id=777>ï¿½ Here's the page at which I was seeing it: http://sigma.mcs.anl.gov/?p=795 Cheers, -- Patrick C. Shriwise Research Assistant University of Wisconsin - Madison Engineering Research Building - Rm. 428 1500 Engineering Drive Madison, WI 53706 (608) 446-8173

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Paul Wilson 16 Jul '14

16 Jul '14

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(a)engr.wisc.edu> >> *To:* "Jain, Rajeev" <jain(a)mcs.anl.gov>; shriwise >> <shriwise(a)wisc.edu>; CGMA Development <cgma-dev(a)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@a etc. >>> >>> Rajeev >>> >>> ------------------------------------------------------------------------ >>> *From:* shriwise <shriwise(a)wisc.edu> <mailto:[email protected]> >>> *To:* Paul Wilson <wilsonp(a)engr.wisc.edu> >>> <mailto:[email protected]>; "Jain, Rajeev" <jain(a)mcs.anl.gov> >>> <mailto:[email protected]>; CGMA Development <cgma-dev(a)mcs.anl.gov> >>> <mailto:[email protected]> >>> *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(a)gmail.com >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> See comments below... >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson >>>>>>> <wilsonp(a)engr.wisc.edu <mailto:[email protected]>> 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(a)gmail.com <mailto:[email protected]>> 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(a)wisc.edu <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Hi Jane, >>>>>>>> >>>>>>>> Will the ref_volumes() method return RefEntities? >>>>>>>> >>>>>>>> Patrick >>>>>>>> >>>>>>>> On Jun 15, 2014, at 3:56 PM, Jane Hu >>>>>>>> <janejhu(a)gmail.com <mailto:[email protected]>> >>>>>>>> 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(a)wisc.edu >>>>>>>>> <mailto:[email protected]>> 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

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Patrick Shriwise 16 Jul '14

16 Jul '14

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(a)engr.wisc.edu> > *To:* "Jain, Rajeev" <jain(a)mcs.anl.gov>; shriwise <shriwise(a)wisc.edu>; > CGMA Development <cgma-dev(a)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@a etc. >> >> Rajeev >> >> ------------------------------------------------------------------------ >> *From:* shriwise <shriwise(a)wisc.edu> <mailto:[email protected]> >> *To:* Paul Wilson <wilsonp(a)engr.wisc.edu> >> <mailto:[email protected]>; "Jain, Rajeev" <jain(a)mcs.anl.gov> >> <mailto:[email protected]>; CGMA Development <cgma-dev(a)mcs.anl.gov> >> <mailto:[email protected]> >> *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(a)gmail.com >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> See comments below... >>>>>> >>>>>> >>>>>> On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson >>>>>> <wilsonp(a)engr.wisc.edu <mailto:[email protected]>> 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(a)gmail.com <mailto:[email protected]>> 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(a)wisc.edu <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hi Jane, >>>>>>> >>>>>>> Will the ref_volumes() method return RefEntities? >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> On Jun 15, 2014, at 3:56 PM, Jane Hu >>>>>>> <janejhu(a)gmail.com <mailto:[email protected]>> >>>>>>> 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(a)wisc.edu >>>>>>>> <mailto:[email protected]>> 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

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Rajeev Jain 16 Jul '14

16 Jul '14

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(a)engr.wisc.edu> To: "Jain, Rajeev" <jain(a)mcs.anl.gov>; shriwise <shriwise(a)wisc.edu>; CGMA Development <cgma-dev(a)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@a etc. > > >Rajeev > > > >________________________________ > From: shriwise <shriwise(a)wisc.edu> >To: Paul Wilson <wilsonp(a)engr.wisc.edu>; "Jain, Rajeev" <jain(a)mcs.anl.gov>; CGMA Development <cgma-dev(a)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(a)gmail.com> wrote: >>>>> >>>>>See comments below... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson <wilsonp(a)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(a)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(a)wisc.edu> wrote: >>>>>>>>> >>>>>>>>>Hi Jane, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Will the ref_volumes() method return RefEntities? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Patrick >>>>>>>>>> >>>>>>>>>>On Jun 15, 2014, at 3:56 PM, Jane Hu <janejhu(a)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(a)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 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 > > -- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- 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

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Paul Wilson 16 Jul '14

16 Jul '14

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@a etc. > > Rajeev > > ------------------------------------------------------------------------ > *From:* shriwise <shriwise(a)wisc.edu> > *To:* Paul Wilson <wilsonp(a)engr.wisc.edu>; "Jain, Rajeev" > <jain(a)mcs.anl.gov>; CGMA Development <cgma-dev(a)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(a)gmail.com >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> See comments below... >>>>> >>>>> >>>>> On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson >>>>> <wilsonp(a)engr.wisc.edu <mailto:[email protected]>> 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(a)gmail.com <mailto:[email protected]>> 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(a)wisc.edu <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hi Jane, >>>>>> >>>>>> Will the ref_volumes() method return RefEntities? >>>>>> >>>>>> Patrick >>>>>> >>>>>> On Jun 15, 2014, at 3:56 PM, Jane Hu >>>>>> <janejhu(a)gmail.com <mailto:[email protected]>> 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(a)wisc.edu >>>>>>> <mailto:[email protected]>> 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

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Timothy Tautges 15 Jul '14

15 Jul '14

I think the name gets duplicated at the attribute level; it's only when the attribute gets interpreted and assigned in CGM that the suffix gets added. On Jul 15, 2014 8:26 PM, "Rajeev Jain" <jain(a)mcs.anl.gov> 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@a etc. > > Rajeev > > ------------------------------ > *From:* shriwise <shriwise(a)wisc.edu> > *To:* Paul Wilson <wilsonp(a)engr.wisc.edu>; "Jain, Rajeev" < > jain(a)mcs.anl.gov>; CGMA Development <cgma-dev(a)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(a)gmail.com> wrote: > > See comments below... > > > On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson <wilsonp(a)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(a)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(a)wisc.edu> > wrote: > > Hi Jane, > > Will the ref_volumes() method return RefEntities? > > Patrick > > On Jun 15, 2014, at 3:56 PM, Jane Hu <janejhu(a)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(a)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 > 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 > > > >

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Rajeev Jain 15 Jul '14

15 Jul '14

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@a etc. Rajeev ________________________________ From: shriwise <shriwise(a)wisc.edu> To: Paul Wilson <wilsonp(a)engr.wisc.edu>; "Jain, Rajeev" <jain(a)mcs.anl.gov>; CGMA Development <cgma-dev(a)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(a)gmail.com> wrote: >>>> >>>>See comments below... >>>>> >>>>> >>>>> >>>>> >>>>>On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson <wilsonp(a)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(a)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(a)wisc.edu> wrote: >>>>>>>> >>>>>>>>Hi Jane, >>>>>>>>> >>>>>>>>> >>>>>>>>>Will the ref_volumes() method return RefEntities? >>>>>>>>> >>>>>>>>>Patrick >>>>>>>>> >>>>>>>>>On Jun 15, 2014, at 3:56 PM, Jane Hu <janejhu(a)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(a)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 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

1 0