January 2015 - cgma-dev - mailman3.cels.anl.gov

CGM v14.1 release now available as part of SIGMA v1.1.
by Vijay S. Mahadevan 31 Jan '15

31 Jan '15

Dear users, The consolidated release of SIGMA v1.1 is available now. Please refer to the following link to find all changes in the SIGMA components. http://press3.mcs.anl.gov/sigma/news/sigma-release-1-1/ Download: ftp://ftp.mcs.anl.gov/pub/fathom/cgm-14.1.tar.gz The notable changes in CGM are below: # CGM Version 14.1 (SIGMA v1.1) This version of CGM is compatible with Cubit v14.0 (https://cubit.sandia.gov/public/14.0/Cubit-14.0-announcement.html) only. The API updates for Cubit v14.1 will be available in the next minor release. ## A. BUG FIXES 1. Fix a lot of warnings (over 700) appearing on Linux and OSX due to uninitialized variables, remove unsed variables etc. for CGM-13.1 and CGM-14.0. 2. Trap unhandled exceptions more cleanly 3. Fixed failing test cases on newer version of OSX 4. Fixes for getting shared builds (Cubit/OCC) and make distcheck working cleanly in several configuration combinations ## B. NEW FEATURES + ENHANCEMENTS 1. Native support for building with both OpenCascade (OCC) and the community edition (OCE). Currently configured using --with-occ. 2. A patched OCE fork on Bitbucket is managed by SIGMA team and can be used as is: https://bitbucket.org/fathomteam/oce. Using the fork of https://github.com/tpaviot/oce will require patching separately in order to work semalessly with CGM. - Version info: a. OCC 6.7.1 <=> OCE 0.16 <=> Branch rajeeja/oce_0.16_occ_6.7.1 b. OCC 6.6.0 <=> OCE 0.13 <=> Branch sigma/oce_0.13_occ_6.6 c. OCC 6.5.3 <=> OCE 0.10 <=> Branch sigma/oce_0.10_occ_6.5.3 3. Support for CMake-based builds 4. Improved support for CGM build on Windows OS 5. Improvements to documentation and added new tests Please let us know if you have any questions or encounter any issues during upgrade. Best, The SIGMA team

1 0

Re: [cgma-dev] Continuing discussion of iGeom handling of RefVolume vs Body
by Vander Zee, Evan B. 30 Jan '15

30 Jan '15

There are two additional things that we might want to consider in this discussion. 1) When are bodies that CGM is passing through the iGeom interface allowed to be “sheet bodies?” In other words, when should we be able to pass what are essentially 2-dimensional entities through the iGeom interface? 2) The input path of iGeom is a consideration as well as the output side. We can assume, I think, that the only entity handles a user passes into methods through the iGeom interface are entity handles that have been accessed through the iGeom interface. If we want to allow operations that apply to multiple volumes, but we never pass back entity handles that refer to multiple-volume bodies, then we should make sure that the interface includes methods that support passing in a list of entities or an entity set. For example, the interface already supports subtract with entity set arguments as well as with entity handles. I think that with a little documentation, we could expect users to be responsible for cleaning up single-entity entity sets that are returned from operations that could in some cases return multiple volumes. However, making it easier to use and not expecting a lot of the user is often the better path. These are just a few comments from a guy who’s relatively new to CGM. Please continue the discussion with comments from more experienced developers. -Evan From: cgma-dev-bounces(a)mcs.anl.gov [mailto:[email protected]] On Behalf Of shriwise Sent: Friday, January 30, 2015 9:15 AM To: Paul Wilson; CGMA Development Subject: Re: [cgma-dev] Continuing discussion of iGeom handling of RefVolume vs Body Hi all, From an iGeom perspective, I'm not sure that using bodies is a bad thing... The real issue to me is the mix currently being used. It has been shown to cause problems in iRel. In any case, I think that we should move entirely to one or the other. The real issue to me is that outside of the user's knowledge of the geometry, they can't be sure if the body they are getting from UniteEnts, IntersectEnts, etc. contains disjoint volumes or not. Using RefVolumes Exclusively As it currently stands in specification, in the iGeom interface there is no notion of a body or, perhaps more importantly, an Entity which contains other entities. There are only Entities and EntitySets. The point being that returning a recast cgm Body as an Entity from iGeom simply shouldn't be allowed as it breaks established conventions of iGeom unless we do one of two things: 1) Only return bodies as EntitySets which contain the appropriate Entities (these relationships being set within the functions being called.) - This would require 2) Return arrays of Entities from functions when appropriate, along with an indicator of the array size. Either way, a proper iGeom implementation will require a bit of a deeper look at any function that currently returns a Body to determine the proper way to handle this. For example, the createSphere function should really return a single RefVolume as the body created from this process wouldn't be expected to have more than one volume. However, I think that other functions like uniteEnts and so on will require something like 1) or 2) above. Using Bodies Exclusively All this being said about RefVolumes, it would certainly be possible to always return Bodies from iGeom for dimension 3 entities, but as I mentioned above I think this should always be done using EntitySets. This implementation would be less clean as iGeom models would then perhaps contain many EntitySets most of which really only contain one entity. The user would then have to retrieve their created entities proper by querying the EntitySets. It adds an unnecessary level of abstraction and might cloud the user's idea of what EntitySets are intended for. One last thing I'll say in favor of using RefVolumes exclusively but returning lists is that it adds clarity to the interface. By having boolean functions like uniteEnts and others return lists or EntitySets, it will imply to the user that iGeom is capable of doing these operations in the case of disjointed volumes and that they may be getting multiple volume entities back from these functions. If we were to return bodies only, it then becomes ambiguous (and perhaps confusing to the user) as to whether or not any function called is returning one or more volumes. That's my take. Apologies for the lack of insight in the changes found in the current PR. The situation is not as simple as I'd initially thought. Cheers, Patrick On 01/29/2015 03:17 PM, Paul Wilson wrote: Hello, There has been some discussion in a pull request<https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates> that I thought would be better brought to the mailing list. This was initially motivated by the realization that iGeom was inconsistent in returning a RefVolume vs a Body in different calls. Thus, two entity handles that referred to the same volume in space would not be detected as the same volume. Faced with two choices - refer only to RefVolumes or refer only to Body's - we settled on referring only to refVolume's in the iGeom interface. However, this breaks the ability to refer to a Body such as my be returned by uniting two volumes that are disjoint - which is part of the interface. So.... perhaps we need to only deal with Body in the iGeom interface. Perhaps Patrick can offer some of the downsides to this approach? 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 ~ http://aci.wisc.edu -- 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] Continuing discussion of iGeom handling of RefVolume vs Body
by shriwise 30 Jan '15

30 Jan '15

Hi all, From an iGeom perspective, I'm not sure that using bodies is a bad thing... The real issue to me is the mix currently being used. It has been shown to cause problems in iRel. In any case, I think that we should move entirely to one or the other. The real issue to me is that outside of the user's knowledge of the geometry, they can't be sure if the body they are getting from UniteEnts, IntersectEnts, etc. contains disjoint volumes or not. _*Using RefVolumes Exclusively*_ As it currently stands in specification, in the iGeom interface there is no notion of a body or, perhaps more importantly, an Entity which /contains/ other entities. There are only Entities and EntitySets. The point being that returning a recast cgm Body as an Entity from iGeom simply shouldn't be allowed as it breaks established conventions of iGeom unless we do one of two things: 1) Only return bodies as EntitySets which contain the appropriate Entities (these relationships being set within the functions being called.) - This would require 2) Return arrays of Entities from functions when appropriate, along with an indicator of the array size. Either way, a proper iGeom implementation will require a bit of a deeper look at any function that currently returns a Body to determine the proper way to handle this. For example, the createSphere function should really return a single RefVolume as the body created from this process wouldn't be expected to have more than one volume. However, I think that other functions like uniteEnts and so on will require something like 1) or 2) above. _*Using Bodies Exclusively*_ All this being said about RefVolumes, it would certainly be possible to always return Bodies from iGeom for dimension 3 entities, but as I mentioned above I think this should always be done using EntitySets. This implementation would be less clean as iGeom models would then perhaps contain many EntitySets most of which really only contain one entity. The user would then have to retrieve their created entities proper by querying the EntitySets. It adds an unnecessary level of abstraction and might cloud the user's idea of what EntitySets are intended for. One last thing I'll say in favor of using RefVolumes exclusively but returning lists is that it adds clarity to the interface. By having boolean functions like uniteEnts and others return lists or EntitySets, it will imply to the user that iGeom is capable of doing these operations in the case of disjointed volumes and that they may be getting multiple volume entities back from these functions. If we were to return bodies only, it then becomes ambiguous (and perhaps confusing to the user) as to whether or not any function called is returning one or more volumes. That's my take. Apologies for the lack of insight in the changes found in the current PR. The situation is not as simple as I'd initially thought. Cheers, Patrick On 01/29/2015 03:17 PM, Paul Wilson wrote: > Hello, > > There has been some discussion in a pull request > <https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates> > that I thought would be better brought to the mailing list. > > This was initially motivated by the realization that iGeom was > inconsistent in returning a RefVolume vs a Body in different calls. > Thus, two entity handles that referred to the same volume in space > would not be detected as the same volume. > > Faced with two choices - refer only to RefVolumes or refer only to > Body's - we settled on referring only to refVolume's in the iGeom > interface. However, this breaks the ability to refer to a Body such > as my be returned by uniting two volumes that are disjoint - which is > part of the interface. > > So.... perhaps we need to only deal with Body in the iGeom interface. > Perhaps Patrick can offer some of the downsides to this approach? > > 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 ~http://aci.wisc.edu -- 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

Continuing discussion of iGeom handling of RefVolume vs Body
by Paul Wilson 29 Jan '15

29 Jan '15

Hello, There has been some discussion in a pull request <https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates> that I thought would be better brought to the mailing list. This was initially motivated by the realization that iGeom was inconsistent in returning a RefVolume vs a Body in different calls. Thus, two entity handles that referred to the same volume in space would not be detected as the same volume. Faced with two choices - refer only to RefVolumes or refer only to Body's - we settled on referring only to refVolume's in the iGeom interface. However, this breaks the ability to refer to a Body such as my be returned by uniting two volumes that are disjoint - which is part of the interface. So.... perhaps we need to only deal with Body in the iGeom interface. Perhaps Patrick can offer some of the downsides to this approach? 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 ~ http://aci.wisc.edu

1 0

Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.
by Grindeanu, Iulian R. 27 Jan '15

27 Jan '15

OK, I found this old email thread. Rajeev, we need to discuss what is expected with the attributes for rgg. copy_attrib was enabled only for occ builds. So I assume that rgg with cubit already did what you want; my understanding is that copy attrib exposed a problem when rgg was built with occ. after Jane fixed it, RGG worked fine with occ. So we need to understand what is expected, and what attributes/tags are needed. Attributes are treated differently for cubit and occ; Iulian ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Patrick Shriwise [shriwise(a)wisc.edu] Sent: Wednesday, July 16, 2014 9:15 AM To: Jain, Rajeev; Paul Wilson; CGMA Development Subject: Re: [cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel. 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><mailto:[email protected]> To: "Jain, Rajeev" <jain(a)mcs.anl.gov><mailto:[email protected]>; shriwise <shriwise(a)wisc.edu><mailto:[email protected]>; CGMA Development <cgma-dev(a)mcs.anl.gov><mailto:[email protected]> 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<UrlBlockedError.aspx> -- 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<UrlBlockedError.aspx> ~ 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] Pull request
by Rajeev Jain 12 Jan '15

12 Jan '15

We're not building with occ-6.8. Anyways I'm reviewing this with our current builds. If it works, I'll approve the PR. Thanks. Rajeev Jain 630-252-3176 / 630-252-5986 (fax) jain(a)mcs.anl.gov From: David Thompson <david.thompson(a)kitware.com> To: "cgma-dev(a)mcs.anl.gov" <cgma-dev(a)mcs.anl.gov> Sent: Monday, January 12, 2015 2:18 PM Subject: [cgma-dev] Pull request Hi all, Could someone with fathomteam commit authority please review/merge this pull request: https://bitbucket.org/fathomteam/cgm/pull-request/18/occ-68-changed-order-o… which fixes a compile error when building against the master branch of OCE (https://github.com/tpaviot/oce)? Thanks, David

1 0

Pull request
by David Thompson 12 Jan '15

12 Jan '15

Hi all, Could someone with fathomteam commit authority please review/merge this pull request: https://bitbucket.org/fathomteam/cgm/pull-request/18/occ-68-changed-order-o… which fixes a compile error when building against the master branch of OCE (https://github.com/tpaviot/oce)? Thanks, David

1 0