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

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

16 Jun '14

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). This is valid with the iGeom implementation, but there is no function in the iGeom interface that provides this access, right? Paul -- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- 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 Jane Hu 13 Jun '14

13 Jun '14

> > 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)

1 0

Re: [cgma-dev] [Meshkit-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Tim Tautges 13 Jun '14

13 Jun '14

ACIS Body, the gift that keeps on giving :). I think both MOAB and MeshKit should be modified to always do things (geom_topo sets, MeshKit ModelEnts, etc.) based on RefVolumes. And, take Body entities from CGM and automatically make them entity sets in MOAB, *containing* (not having as children) the volumes in them, and also mark them with the "Body" category tag. Then MK won't consider Body entities as ModelEnts, and iRel should work as before. IIRC, we went straight to volumes in MOAB's cgm reader. - tim On 06/13/2014 01:23 PM, Patrick Shriwise wrote: > > Hi all, > > After a lot of investigation, I've discovered an inconsistency in the iGeom function getEntities() (line 1149 > iGeom_CGMA.cc). This problem can actually be seen throughout the file iGeom_CGMA.cc file, but I'm using getEntities as > an example. > > When entities are loaded from a standard geom EntSet (or a group), CubitEntities are returned. > > However, when querying from the root_set, RefEntities are returned. > > In most cases this seems to be ok, except for the case of Volumes. When volumes are queried at the with the root_set as > the set_handle, the RefEntitiy for the body that contains that volume is returned. However, if a volume (not the body it > belongs to) is added to an EntSet or Group, the volume CubitEntity will be returned from iGeom's getEntities. > > This causes problems in iRel when trying to populate groups in other software (to be specific, Meshkit). When ModelEnts > are created upon loading a file they are created for the bodies, meaning that iRel associates a meshset with the bodies. > Then upon populating groups that contain volumes, iRel cannot find a relation between the geom Entity and the mesh > EntitySet for the volume. > > So..... I'm not really clear as to whether or not this is a problem with returning CubitEntities vs. RefEntities or if > its a more conceptual issue cause by the different EntityType definitions between CGM and iGeom, shown below. > > const char *iGeom_entity_type_names[] = {"vertex", "curve", "surface", "body"}; > const char *cgm_type_names[] = {"vertex", "curve", "surface", "volume", "body"}; > > What's the best way to remedy this? Is there a way to get volumes within bodies via iGeom? > > -- > Patrick C. Shriwise > Research Assistant > University of Wisconsin - Madison > Engineering Research Building - Rm. 428 > 1500 Engineering Drive > Madison, WI 53706 > (608) 446-8173 > > > > _______________________________________________ > Meshkit-dev mailing list > Meshkit-dev(a)mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/meshkit-dev > -- Timothy J. Tautges Manager, Directed Meshing, CD-adapco Phone: 608-354-1459 timothy.tautges(a)cd-adapco.com

1 0

Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Patrick Shriwise 13 Jun '14

13 Jun '14

Hi all, After a lot of investigation, I've discovered an inconsistency in the iGeom function getEntities() (line 1149 iGeom_CGMA.cc). This problem can actually be seen throughout the file iGeom_CGMA.cc file, but I'm using getEntities as an example. When entities are loaded from a standard geom EntSet (or a group), CubitEntities are returned. However, when querying from the root_set, RefEntities are returned. In most cases this seems to be ok, except for the case of Volumes. When volumes are queried at the with the root_set as the set_handle, the RefEntitiy for the body that contains that volume is returned. However, if a volume (not the body it belongs to) is added to an EntSet or Group, the volume CubitEntity will be returned from iGeom's getEntities. This causes problems in iRel when trying to populate groups in other software (to be specific, Meshkit). When ModelEnts are created upon loading a file they are created for the bodies, meaning that iRel associates a meshset with the bodies. Then upon populating groups that contain volumes, iRel cannot find a relation between the geom Entity and the mesh EntitySet for the volume. So..... I'm not really clear as to whether or not this is a problem with returning CubitEntities vs. RefEntities or if its a more conceptual issue cause by the different EntityType definitions between CGM and iGeom, shown below. const char *iGeom_entity_type_names[] = {"vertex", "curve", "surface", "body"}; const char *cgm_type_names[] = {"vertex", "curve", "surface", "volume", "body"}; What's the best way to remedy this? Is there a way to get volumes within bodies via iGeom? -- 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

commit/CGM: Jane Hu: In an effort to find the example for oce patches, found that the edges' order in the modify.cpp testcases changed, hence added a check to use the particular edge for testing sweep_translational. Passed modify test.
by Bitbucket 13 Jun '14

13 Jun '14

1 new commit in CGM: https://bitbucket.org/fathomteam/cgm/commits/20be5ee0426b/ Changeset: 20be5ee0426b Branch: cgm13.1 User: Jane Hu Date: 2014-06-13 19:44:12 Summary: In an effort to find the example for oce patches, found that the edges' order in the modify.cpp testcases changed, hence added a check to use the particular edge for testing sweep_translational. Passed modify test. Affected #: 1 file Repository URL: https://bitbucket.org/fathomteam/cgm/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email.

1 0

Re: [cgma-dev] What versions of OCE is CGM 13.1 compatible with?
by Vijay S. Mahadevan 11 Jun '14

11 Jun '14

Hi Jane, were you able to resolve the errors that Geoff was seeing here with the copy_attrib test ? Can you verify if the tests run fine under the same configuration so that we can close the issue. Vijay On Sat, May 24, 2014 at 6:56 PM, Geoff Oxberry <goxberry(a)gmail.com> wrote: > Jane, > > The patches applied successfully. OCE 0.15 and CGM 13.1 built successfully, > but CGM fails tests in "make check". Here's a gist of the configure log and > test logs: https://gist.github.com/goxberry/152faed6fb782781ee4a > > The test that fails seems to be "copy_attrib". > > Geoff > > On Thu, May 22, 2014 at 10:23 AM, Jane Hu <janejhu(a)gmail.com> wrote: >> >> Hi, Geoff >> >> I attached the three patch files here, can you try to see if they work >> well on 0.15 oce? >> >> Jane >> >> >> On Thu, May 22, 2014 at 12:56 AM, Geoff Oxberry <goxberry(a)gmail.com> >> wrote: >>> >>> Apologies for not sending the previous reply to the CGMA-dev list. >>> >>> The patch under cgm/geom/OCC/occ_patches_6.6.0 failed to apply to source >>> files in OCE 0.15. A log can be found at >>> https://gist.github.com/goxberry/c31139a3c5c49adb1cad; the Homebrew formula >>> I am writing for OCE can be found at >>> https://github.com/goxberry/homebrew-itaps/blob/oce-0.15/oce.rb. >>> >>> A similar formula is under way for CGM. >>> >>> Cheers, >>> >>> Geoff >>> >>> >>> On Wed, May 21, 2014 at 7:57 AM, Rajeev Jain <jain(a)mcs.anl.gov> wrote: >>>> >>>> Yes. 0.15 works. >>>> >>>> Rajeev >>>> >>>> ________________________________ >>>> From: Jane Hu <janejhu(a)gmail.com> >>>> To: Geoff Oxberry <goxberry(a)gmail.com> >>>> Cc: Vijay M <vijay.m(a)gmail.com>; "Jain, Rajeev" <jain(a)mcs.anl.gov> >>>> Sent: Wednesday, May 21, 2014 9:48 AM >>>> Subject: Re: [cgma-dev] What versions of OCE is CGM 13.1 compatible >>>> with? >>>> >>>> Geoff, >>>> >>>> I don't have a Mac machine, and wouldn't tell if it works on 0.15, did >>>> you try it yet? >>>> >>>> The patches has been requested to opencascase.org 's develop's forum for >>>> quite long time, but didn't get in as we are not their customer. They >>>> haven't been submitted to upstream yet for OCE. We have to test them on >>>> linux for OCE before submit. But I know some of the testcases will fail on >>>> linux w/o the patches. >>>> >>>> Best, >>>> >>>> Jane >>>> >>>> >>>> >>>> >>>> On Wed, May 21, 2014 at 1:06 AM, Geoff Oxberry <goxberry(a)gmail.com> >>>> wrote: >>>> >>>> Jane, >>>> >>>> I take it by 0.16-dev, you mean the master branch of >>>> https://github.com/tpaviot/oce? Will it build with version 0.15? >>>> >>>> I did not apply the patches. I will do that to test the build, but it >>>> will mean that I cannot include the build recipe in >>>> https://github.com/Homebrew/homebrew-science, so CGM will not be in a >>>> mainstream package manager for OS X. I'll have to set up a separate repo >>>> called a "tap", and fork other build recipes in the process (at least MOAB, >>>> gmsh). >>>> >>>> Have these OCC/OCE patches been submitted upstream? If not, is there any >>>> plan to? Merging them upstream would make it easier to get build recipes for >>>> CGM, Lasso, and MeshKit into homebrew/science. It would also avoid a lot of >>>> unnecessary duplication and spread the maintenance burden for packaging over >>>> more people. (homebrew/science has 239 contributors; I am just one person.) >>>> >>>> Thanks, >>>> >>>> Geoff >>>> >>>> >>>> >>>> On Tue, May 20, 2014 at 7:59 AM, Jane Hu <janejhu(a)gmail.com> wrote: >>>> >>>> Hi, Geoff >>>> >>>> The OCE mentioned in Mac OSX build was from >>>> https://github.com/tpaviot/oce, looks like 0.16-dev version. >>>> >>>> Did you apply the patches under cgm/geom/OCC/occ_patches_6.6.0 for the >>>> build? What are the failed tests? We are working on Linux, so may not be >>>> able to fix for all of the failed tests, but want to get to know which ones >>>> are failing on Mac. Thanks. >>>> >>>> Jane >>>> >>>> >>>> On Tue, May 20, 2014 at 1:32 AM, Geoff Oxberry <goxberry(a)gmail.com> >>>> wrote: >>>> >>>> Dear CGM devs, >>>> >>>> I am attempting to write a build recipe for CGM for the OS X package >>>> manager Homebrew. So far, I've managed to build CGM with OCE, as recommended >>>> by the Trac wiki, although "make check" fails. Before I delve too far into >>>> the weeds by attaching build logs and error messages, what version of OCE >>>> should I be building with? >>>> >>>> Cheers, >>>> >>>> Geoff >>>> >>>> -- >>>> Geoffrey Oxberry, Ph.D., E.I.T. >>>> goxberry(a)gmail.com >>>> >>>> >>>> >>>> >>>> -- >>>> 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) >>>> >>>> >>>> >>>> >>>> -- >>>> Geoffrey Oxberry, Ph.D., E.I.T. >>>> goxberry(a)gmail.com >>>> >>>> >>>> >>>> >>>> -- >>>> 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) >>>> >>>> >>> >>> >>> >>> -- >>> Geoffrey Oxberry, Ph.D., E.I.T. >>> goxberry(a)gmail.com >> >> >> >> >> -- >> 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) > > > > > -- > Geoffrey Oxberry, Ph.D., E.I.T. > goxberry(a)gmail.com

1 0