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

commit/CGM: 5 new changesets
by Bitbucket 13 Feb '14

13 Feb '14

5 new commits in CGM: https://bitbucket.org/fathomteam/cgm/commits/57f3882e9887/ Changeset: 57f3882e9887 Branch: None User: tautges Date: 2007-06-05 00:14:00 Summary: Moving stuff down to trunk. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1046 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 903 files https://bitbucket.org/fathomteam/cgm/commits/fadd327d0f14/ Changeset: fadd327d0f14 Branch: None User: tautges Date: 2007-06-05 00:22:53 Summary: Changes from 10.2 to version sent by Kevin Pendley to Tim Tautges approximately 12/15/2006. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1047 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 67 files https://bitbucket.org/fathomteam/cgm/commits/79f8844159ce/ Changeset: 79f8844159ce Branch: None User: tautges Date: 2007-06-05 00:34:56 Summary: Adding the Face-based ray-fire written after latest CGM sent to Tim. Adding a few files which were added to CGM between 10.2 and the copy sent by Kevin Pendley to Tim Tautges approximately 12/15/2006. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1048 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 11 files https://bitbucket.org/fathomteam/cgm/commits/2f9441b455a3/ Changeset: 2f9441b455a3 Branch: None User: Jason Kraftcheck Date: 2007-06-05 17:41:32 Summary: Allow configure with pre-build CUBIT library git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1049 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 16 files https://bitbucket.org/fathomteam/cgm/commits/95c3b20423d4/ Changeset: 95c3b20423d4 Branch: None User: Jason Kraftcheck Date: 2007-06-05 17:41:39 Summary: Allow configure with pre-build CUBIT library git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1050 6162379e-bd28-0410-9a7d-b7f4dcfcad3c 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] Migrating repo to git
by Anthony Scopatz 12 Feb '14

12 Feb '14

Hello All, Great to see this happening! Be Well Anthony On Wed, Feb 12, 2014 at 9:14 PM, Jane Hu <janejhu(a)gmail.com> wrote: > Hi Tim, > > Just uploaded the cgm codes from svn to fathomteam/CGM in git which > includes 9 branches and 5 tags. Please let me know if you have problems > with the codes from there. > > Jane > > > On Thu, Jan 23, 2014 at 5:17 PM, Tim Tautges (ANL) <tautges(a)mcs.anl.gov>wrote: > >> Hi Jane /all, >> Jane, could you look at http://git-scm.com/book/en/ >> Git-and-Other-Systems-Migrating-to-Git for migrating an svn repo to git, >> and make sure you understand it all? And, compile a list of all users on >> the svn side that we know about, and see if you can find bitbucket users >> for the ones we work with? >> >> Others: we'll be moving the cgm code repo to bitbucket.com shortly. If >> you'd like to continue looking over the code or using it, don't worry, >> you'll be able to do that anonymously just like you currently can with the >> svn repo. If you'd like to be involved in CGM development or propose code >> changes, I'd encourage you to get a (free) bitbucket account and interact >> with us there. Bitbucket provides a nice web front-end to a git >> repository; you can interact with git just like you would if it were hosted >> on your own system, but also, the web interface allows you to do things >> like submit tickets and pull requests (code changes you'd like to send back >> to us) and a way to track those things. If you're familiar with github, >> it's a lot like that. >> >> Thanks. Once the move is done we'll email this list again, as well as >> turn off writing to the old repo. Eventually we'll take that old repo >> offline, but not for a little while after the switchover. >> >> - tim >> >> -- >> ================================================================ >> "You will keep in perfect peace him whose mind is >> steadfast, because he trusts in you." Isaiah 26:3 >> >> Tim Tautges Argonne National Laboratory >> (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) >> phone (gvoice): (608) 354-1459 1500 Engineering Dr. >> fax: (608) 263-4499 Madison, WI 53706 >> >> > > > -- > 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] Migrating repo to git
by Jane Hu 12 Feb '14

12 Feb '14

Hi Tim, Just uploaded the cgm codes from svn to fathomteam/CGM in git which includes 9 branches and 5 tags. Please let me know if you have problems with the codes from there. Jane On Thu, Jan 23, 2014 at 5:17 PM, Tim Tautges (ANL) <tautges(a)mcs.anl.gov>wrote: > Hi Jane /all, > Jane, could you look at http://git-scm.com/book/en/ > Git-and-Other-Systems-Migrating-to-Git for migrating an svn repo to git, > and make sure you understand it all? And, compile a list of all users on > the svn side that we know about, and see if you can find bitbucket users > for the ones we work with? > > Others: we'll be moving the cgm code repo to bitbucket.com shortly. If > you'd like to continue looking over the code or using it, don't worry, > you'll be able to do that anonymously just like you currently can with the > svn repo. If you'd like to be involved in CGM development or propose code > changes, I'd encourage you to get a (free) bitbucket account and interact > with us there. Bitbucket provides a nice web front-end to a git > repository; you can interact with git just like you would if it were hosted > on your own system, but also, the web interface allows you to do things > like submit tickets and pull requests (code changes you'd like to send back > to us) and a way to track those things. If you're familiar with github, > it's a lot like that. > > Thanks. Once the move is done we'll email this list again, as well as > turn off writing to the old repo. Eventually we'll take that old repo > offline, but not for a little while after the switchover. > > - tim > > -- > ================================================================ > "You will keep in perfect peace him whose mind is > steadfast, because he trusts in you." Isaiah 26:3 > > Tim Tautges Argonne National Laboratory > (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) > phone (gvoice): (608) 354-1459 1500 Engineering Dr. > fax: (608) 263-4499 Madison, WI 53706 > > -- 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

commit/CGM: 10 new changesets
by Bitbucket 12 Feb '14

12 Feb '14

10 new commits in CGM: https://bitbucket.org/fathomteam/cgm/commits/111c4b7cc34b/ Changeset: 111c4b7cc34b Branch: None User: Hong-Jun Kim Date: 2011-09-13 23:06:05 Summary: o The most recent revision against Cubit 10.2 git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/cubit10.2@5158 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/f2e021ee39a6/ Changeset: f2e021ee39a6 Branch: None User: janehu Date: 2011-09-14 17:02:31 Summary: Added two brep files that are needed for modify test, fixed make check failure. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/cubit10.2@5159 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 2 files https://bitbucket.org/fathomteam/cgm/commits/070e58d5c844/ Changeset: 070e58d5c844 Branch: None User: janehu Date: 2011-09-14 17:28:40 Summary: Check in the addition for Makefile.am for the two brep files for packaging. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/cubit10.2@5160 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 1 file https://bitbucket.org/fathomteam/cgm/commits/a0e71c17ae1d/ Changeset: a0e71c17ae1d Branch: None User: James Porter Date: 2012-03-23 06:41:57 Summary: Add tag for CGM version 12.2.0 git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/12.2.0@5439 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/6701fb4c3c62/ Changeset: 6701fb4c3c62 Branch: None User: janehu Date: 2013-09-12 16:49:11 Summary: Tagging the 13.1 release for cgm. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.0@6069 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/910faebc65ed/ Changeset: 910faebc65ed Branch: None User: janehu Date: 2013-11-04 19:51:56 Summary: Do not show this directory to users without ACIS licenses. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/12.2.0@6088 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/bda61a9d4bfb/ Changeset: bda61a9d4bfb Branch: None User: janehu Date: 2013-11-04 19:54:08 Summary: Do not show this directory to users without ACIS licenses. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.0@6090 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/a456a6cb90f6/ Changeset: a456a6cb90f6 Branch: None User: janehu Date: 2013-11-04 19:55:38 Summary: Do not show this directory to users without ACIS licenses. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/cubit10.2@6091 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/a10fe3f3f38c/ Changeset: a10fe3f3f38c Branch: None User: janehu Date: 2013-11-22 18:01:57 Summary: Added documentary for reflect and scale functions. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.0@6099 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 1 file https://bitbucket.org/fathomteam/cgm/commits/8dfec5503651/ Changeset: 8dfec5503651 Branch: None User: janehu Date: 2013-11-22 20:46:32 Summary: Moved cgm version to a separate header file. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.0@6103 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 4 files 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

commit/CGM: 3 new changesets
by Bitbucket 12 Feb '14

12 Feb '14

3 new commits in CGM: https://bitbucket.org/fathomteam/cgm/commits/2c70d117ae88/ Changeset: 2c70d117ae88 Branch: None User: tautges Date: 2007-06-04 21:47:45 Summary: Version 10.2 of cgm. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm@1040 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 904 files https://bitbucket.org/fathomteam/cgm/commits/916a1c71273c/ Changeset: 916a1c71273c Branch: None User: tautges Date: 2007-06-05 00:11:09 Summary: Creating a trunk, duh. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm@1045 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files https://bitbucket.org/fathomteam/cgm/commits/f44dd726a9f2/ Changeset: f44dd726a9f2 Branch: None User: tautges Date: 2007-06-05 00:11:09 Summary: Creating a trunk, duh. git-svn-id: https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk@1045 6162379e-bd28-0410-9a7d-b7f4dcfcad3c Affected #: 0 files 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] RefGroup question
by David Thompson 07 Feb '14

07 Feb '14

Hi Jane, Sorry for the slow reply. Thanks for finding the problem! I was unaware of the difference between auto_flag(CUBIT_TRUE); and set_all_auto_read_flags(true); set_all_auto_write_flags(true); set_all_auto_actuate_flags(true); Once the repository is migrated to bitbucket, I'll submit a pull request with some more documentation. Thanks again, David On Feb 6, 2014, at 2:35 PM, Jane Hu <janejhu(a)gmail.com> wrote: > Hey, David > > Did some investigation on this issue, now attached is the revised program that created the group after reading in the exported file. Also attached is the occ file that the program exported using the revised program. > > In OCC, hopefully as well as in facet (not investigated), the group info is stored in the attributes, and have to be read in to create groups. Double checked your file, when exported, didn't create group attrib, hence group can't be recreated. > > Hope it helps. > > Jane > > > On Tue, Feb 4, 2014 at 12:09 PM, Jane Hu <janejhu(a)gmail.com> wrote: > Yes, Paul. I am now trying to work on it, and will consider putting it into the test suite. > > Jane > > > On Tue, Feb 4, 2014 at 10:48 AM, Paul Wilson <wilsonp(a)engr.wisc.edu> wrote: > Hi David, > > I've never used this capability with OCC, so I don't know if there may be an issue there. I think your simple example may be a good thing to test this with and possibly add to the test suite. > > Paul > > > On 01/27/2014 12:28 PM, David Thompson wrote: > Hi Paul, > > It doesn't look like you are not using all the right attribute management here. > > I'm not sure where this is documented (Tim?) but there is a reasonable example in the ReadCGM module of MOAB. Starting at line 178, you will see that if the flag 'act_att' is set to true (it is initialized to true at line 136), then the attribute_manager is set to automatically read and apply the attributes upon reading a file. > I've tried putting > > CGMApp::instance()->attrib_manager()->set_all_auto_read_flags(true); > CGMApp::instance()->attrib_manager()->set_all_auto_write_flags(true); > CGMApp::instance()->attrib_manager()->set_all_auto_actuate_flags(true); > > in the test program (just after startup() is called -- which registers default attributes -- and before any geometry or groups are created) to no effect. > > If you have any other ideas on what might be wrong, that would be great. > > Thanks, > David > > On 01/24/2014 05:12 PM, David Thompson wrote: > Hi Tim, > > > Exporting groups is sort of backwards; if you export the model entities that groups are part of, and attributes are on, then they'll go with, and (again, if attributes are on) will be restored on import. Attribute settings are controlled by CubitAttrib, IIRC. > > While I have been able to save attributes (UUIDs) on many entities back to a solid model, I am not seeing groups saved, whether they contain entities being written or not. I've attached a test program that demonstrates a group not being saved. Can you see something I am doing wrong? > > David > > > -- > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- > 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 > > > -- > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- > 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) > <groups-not-saved-to-OCC.cxx><test.occ>

1 0

r6132 - in cgm/trunk: geom test
by janehu＠mcs.anl.gov 06 Feb '14

06 Feb '14

Author: janehu Date: 2014-02-06 13:56:18 -0600 (Thu, 06 Feb 2014) New Revision: 6132 Added: cgm/trunk/test/groups-saved-to-OCC.cxx Modified: cgm/trunk/geom/RefEntityFactory.hpp cgm/trunk/test/Makefile.am Log: Added a testfile for RefGroup save and import tests, provided by David Thompson. Modified: cgm/trunk/geom/RefEntityFactory.hpp =================================================================== --- cgm/trunk/geom/RefEntityFactory.hpp 2014-02-05 18:51:59 UTC (rev 6131) +++ cgm/trunk/geom/RefEntityFactory.hpp 2014-02-06 19:56:18 UTC (rev 6132) @@ -6,7 +6,7 @@ // applications of the geometry module can provide their // own factory, otherwise this factory is used // -// Creator : Tim Tautges (in it's new state) +// Creator : Tim Tautges (in its new state) // // Creation Date : 9/99 //------------------------------------------------------------------------- Modified: cgm/trunk/test/Makefile.am =================================================================== --- cgm/trunk/test/Makefile.am 2014-02-05 18:51:59 UTC (rev 6131) +++ cgm/trunk/test/Makefile.am 2014-02-06 19:56:18 UTC (rev 6132) @@ -25,7 +25,7 @@ endif endif if build_OCC - TESTS += attribute_to_file loft offset_curves point_project imprint_bug subtract test_occ brick_occ merge_occ r_w operation section AngleCalc_occ CreateGeometry_occ GraphicsData_occ brick_facet merge_facet spheres cylinders multifaceted_works multifaceted_2trisPerSurface_works multifaceted + TESTS += attribute_to_file loft offset_curves point_project imprint_bug subtract test_occ brick_occ merge_occ r_w operation section AngleCalc_occ CreateGeometry_occ GraphicsData_occ brick_facet merge_facet spheres cylinders multifaceted_works multifaceted_2trisPerSurface_works multifaceted groups_saved_to_OCC endif check_PROGRAMS = $(TESTS) @@ -45,6 +45,7 @@ libcgm_test_la_SOURCES = TestUtilities.hpp \ TestUtilities.cpp +groups_saved_to_OCC_SOURCES = groups-saved-to-OCC.cxx multifaceted_2trisPerSurface_works_SOURCES = multifaceted-2trisPerSurface-works.cxx multifaceted_works_SOURCES = multifaceted-works.cxx multifaceted_SOURCES = multifaceted.cpp @@ -158,6 +159,7 @@ unite3.occ \ unite5.occ \ unite6.occ \ + groups_saved.occ \ proeexport.iges \ proe.occ \ diffuser.occ \ Added: cgm/trunk/test/groups-saved-to-OCC.cxx =================================================================== --- cgm/trunk/test/groups-saved-to-OCC.cxx (rev 0) +++ cgm/trunk/test/groups-saved-to-OCC.cxx 2014-02-06 19:56:18 UTC (rev 6132) @@ -0,0 +1,109 @@ +#include "AppUtil.hpp" +#include "CGMApp.hpp"

1 0

Re: [cgma-dev] RefGroup question
by Jane Hu 06 Feb '14

06 Feb '14

Hey, David Did some investigation on this issue, now attached is the revised program that created the group after reading in the exported file. Also attached is the occ file that the program exported using the revised program. In OCC, hopefully as well as in facet (not investigated), the group info is stored in the attributes, and have to be read in to create groups. Double checked your file, when exported, didn't create group attrib, hence group can't be recreated. Hope it helps. Jane On Tue, Feb 4, 2014 at 12:09 PM, Jane Hu <janejhu(a)gmail.com> wrote: > Yes, Paul. I am now trying to work on it, and will consider putting it > into the test suite. > > Jane > > > On Tue, Feb 4, 2014 at 10:48 AM, Paul Wilson <wilsonp(a)engr.wisc.edu>wrote: > >> Hi David, >> >> I've never used this capability with OCC, so I don't know if there may be >> an issue there. I think your simple example may be a good thing to test >> this with and possibly add to the test suite. >> >> Paul >> >> >> On 01/27/2014 12:28 PM, David Thompson wrote: >> >>> Hi Paul, >>> >>> It doesn't look like you are not using all the right attribute >>>> management here. >>>> >>>> I'm not sure where this is documented (Tim?) but there is a reasonable >>>> example in the ReadCGM module of MOAB. Starting at line 178, you will see >>>> that if the flag 'act_att' is set to true (it is initialized to true at >>>> line 136), then the attribute_manager is set to automatically read and >>>> apply the attributes upon reading a file. >>>> >>> I've tried putting >>> >>> CGMApp::instance()->attrib_manager()->set_all_auto_read_flags(true); >>> CGMApp::instance()->attrib_manager()->set_all_auto_write_flags(true); >>> CGMApp::instance()->attrib_manager()->set_all_auto_ >>> actuate_flags(true); >>> >>> in the test program (just after startup() is called -- which registers >>> default attributes -- and before any geometry or groups are created) to no >>> effect. >>> >>> If you have any other ideas on what might be wrong, that would be great. >>> >>> Thanks, >>> David >>> >>> On 01/24/2014 05:12 PM, David Thompson wrote: >>>> >>>>> Hi Tim, >>>>> >>>>> >>>>> Exporting groups is sort of backwards; if you export the model >>>>>> entities that groups are part of, and attributes are on, then they'll go >>>>>> with, and (again, if attributes are on) will be restored on import. >>>>>> Attribute settings are controlled by CubitAttrib, IIRC. >>>>>> >>>>>> While I have been able to save attributes (UUIDs) on many entities >>>>> back to a solid model, I am not seeing groups saved, whether they contain >>>>> entities being written or not. I've attached a test program that >>>>> demonstrates a group not being saved. Can you see something I am doing >>>>> wrong? >>>>> >>>>> David >>>>> >>>>> >>>>> -- >>>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- >>>> 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 >>>> >>>> >> -- >> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- >> 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)

1 0

Re: [cgma-dev] Cubit 14
by Grindeanu, Iulian R. 06 Feb '14

06 Feb '14

OK, last night, everything was fine. Thanks, Iulian ________________________________ From: Jane Hu [janejhu(a)gmail.com] Sent: Wednesday, February 05, 2014 12:53 PM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] Cubit 14 I've just did it, please double check. Thanks, Iulian! Jane On Wed, Feb 5, 2014 at 11:52 AM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov<mailto:[email protected]>> wrote: So that branch cgm12.2 is very old. Can you restore merge-cubit12.2 branch and rename it cgm12.2 ? these are the differences in iGeom.h, between the branch that worked and the branch that does not (cgm12.2 is way too old, I think) gnep~/install/cubser/cgm/include> diff iGeom.h /disks/itaps-buildslave/cgm-shared/build/itaps/ 77a78 > * \param *err Pointer to error type returned from function 81a83 > int* err, 89a92 > * \param *err Pointer to error type returned from function 92c95,96 < /*out*/ int *error_type ); --- > /*out*/ int *error_type, > int *err ); 457,486c461 < * For surfaces, closest point could be on the void space inside it. < * Get closest point for an array of entities and points. If either the < * number of entities or number of coordinate triples is unity, then all < * points or entities are queried for that entity or point, respectively, < * otherwise each point corresponds to each entity. storage_order should be < * a value in the iBase_StorageOrder enum. < * \param instance iGeom instance handle < * \param entity_handles Entity(ies) being queried < * \param entity_handles_size Number of entities being queried < * \param storage_order Storage order of input points < * \param near_coordinates Coordinates of starting point(s) < * \param near_coordinates_size Number of values in near_coordinates array < * \param on_coordinates Coordinates of closest points < * \param on_coordinates_allocated Allocated size of closest point array < * \param on_coordinates_size Occupied size of closest point array < * \param *err Pointer to error type returned from function < */ < < void iGeom_getEntClosestPtTrimmed( iGeom_Instance instance, < iBase_EntityHandle entity_handle, < double near_x, < double near_y, < double near_z, < double* on_x, < double* on_y, < double* on_z, < int* err ); < < /**\brief Get closest point for an array of entities and points < * For surfaces, it made sure the closest point in on surface. --- > * 1220c1195 < void iGeom_getEgFcSense( iGeom_Instance instance, --- > void iGeom_getEgFcSense( iGeom_Instance, 2712c2687 < void iGeom_uniteEnts( iGeom_Instance instance, --- > void iGeom_uniteEnts( iGeom_Instance instace, 3953,3980d3927 < /**\brief Return facet information from solid modeling engine < * < * Return facet information from solid modeling engine < * \param instance iGeom instance handle < * \param entity_handle Entity being queried < * \param dist_tolerance Tolerance guidance for faceting engine < * \param points List of vertices in faceting of curve or surface < * \param points_allocated Allocated size of vertex list array < * \param points_size Occupied size of vertex list array < * \param facets List of facets in faceting of surface < * \param facets_allocated Allocated size of facet list array < * \param facets_size Occupied size of facet list array < * \param *err Pointer to error type returned from function < */ < void iGeom_getFacets(iGeom_Instance instance, < iBase_EntityHandle entity, < double dist_tolerance, < double **points, int *points_allocated, int *points_size, < int **facets, int *facets_allocated, int *facets_size, < int *err); < < /* checks if a point is on a surface or a curve or a body*/ < void iGeom_isPositionOn(iGeom_Instance instance, < iBase_EntityHandle entity, < double x, < double y, < double z, < int *isOn); 3982c3929 < } /* extern "C" */ --- > } // extern "C" gnep~/install/cubser/cgm/include> ________________________________ From: Grindeanu, Iulian R. Sent: Wednesday, February 05, 2014 11:38 AM To: Jane Hu Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: RE: [cgma-dev] Cubit 14 well, cgm12.2 branch seems to be different from former mergecubit12.2 failure appears in lasso Can you check? Iulian ________________________________ From: Jane Hu [janejhu(a)gmail.com<mailto:[email protected]>] Sent: Wednesday, February 05, 2014 11:05 AM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] Cubit 14 Thanks, Iulian. Yes, we can use branches/cgm12.2 and branches/cgm13.1 for nightly build and get rid of others. Can you try them tonight? and hopefully they should run well, there's not essential code changes besides the name changes. Jane On Wed, Feb 5, 2014 at 10:44 AM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov<mailto:[email protected]>> wrote: Hi Jane, Buildbot was using cgmurl = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/branches/merge-cubit12.2' for 12.2 Notice an extra .2 :( Should it use now branches/cgm12.2 ? Also, instead of cgmurlt1311 = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.1' should it use branches/cgm13.1 ? There were 10 failures last night because of missing urls :( Iulian ________________________________ From: Jane Hu [janejhu(a)gmail.com<mailto:[email protected]>] Sent: Wednesday, February 05, 2014 10:18 AM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] Cubit 14 Hi, All I just made some changes according to email exchanges, please comment on if it's made the svn version of cgm system clearer. Keep in mind that it will be moved to git soon... Based on popular request, the branches are kept for continued development while the tags are snapshot of releases. I changed in following directories : Previous branch merge-cubit12 to branch cgm12.2, for continued enhancement development for version 12.2 or backport from above versions, if needed. Previous tags/13.1.1 to branches/cgm13.1, overwriting previous branch cgm13.1, and removed previous branch merge-cubit13.1(not developping any more on this branch), for continued enhancement development of version 13.1 or backport from above versions, if needed. Tagged previous merge-cubit12 as tags/12.2.1, changed the version, minor and patch numbers accordingly in configure.ac<http://configure.ac> and cgm_version.h. Trunk as development branch for cgm14.0 remains unchanged. For cgm repo. users, please download codes from following locations: tags/12.2.1 for cgm12.2 stable releases; tags/13.1.1 for cgm13.1 stable releases; trunk for cgm14.0 development code; Please do not use other repo locations to download cgm code since they may be outdated or unstable. cgm_version.h was added in trunk development and backported to cgm12.2 and cgm13.1 to support MOAB version query needs, current MOAB is in stable state using version numbers defined in each location. Hope it clarify the confusions, and go ahead, happy coding! Jane On Tue, Feb 4, 2014 at 5:12 PM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov<mailto:[email protected]>> wrote: OK, another source of confusion is in configure.ac<http://configure.ac>; does the configure.ac<http://configure.ac> need to contain the version, minor, and patch numbers? If those would be correct (updated), then make dist would create a tarball with the right name (cgma-13.1.tar.gz, or 13.1.1, etc) should we remove the branches that are not active anymore? Iulian ________________________________________ From: Paul Wilson [wilsonp(a)engr.wisc.edu<mailto:[email protected]>] Sent: Tuesday, February 04, 2014 3:23 PM To: Tautges, Timothy J.; Grindeanu, Iulian R.; Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] Cubit 14 Hi all, Perhaps this sheds some light on the situation: wilsonp@TodlawXPS ~/UW/research/software/cgm > find branches tags -depth -maxdepth 1 branches/cubit branches/cubit14.0 branches/merge-cubit12.2 branches/cgm13.1 branches/Version12.2 branches/merge-cubit13.1 branches/dispatch branches/cubit13.1 branches/merge-cubit12 branches tags/12.2.0b1 tags/13.1.0 tags/cubit10.2 tags/12.2.0 tags/13.1.1 tags wilsonp@TodlawXPS ~/UW/research/software/cgm > find . -name "cgm_version.h" ./trunk/cgm_version.h ./tags/13.1.0/cgm_version.h ./tags/13.1.1/cgm_version.h ./branches/merge-cubit12.2/cgm_version.h As you can see, there are many branches and tags, but only three of them plus the trunk have the cgm_version.h file. If I then search all the code for the use of CGM_MAJOR_VERSION, I get the following: trunk/cgm_version.h:1:#define CGM_MAJOR_VERSION 14 tags/12.2.0b1/geom/GeometryQueryTool.hpp:1059: static const int CGM_MAJOR_VERSION; tags/12.2.0b1/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; tags/13.1.0/cgm_version.h:1:#define CGM_MAJOR_VERSION 13 tags/cubit10.2/geom/GeometryQueryTool.hpp:826: static const int CGM_MAJOR_VERSION; tags/cubit10.2/geom/GeometryQueryTool.cpp:81:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; tags/12.2.0/geom/GeometryQueryTool.hpp:1059: static const int CGM_MAJOR_VERSION; tags/12.2.0/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; tags/13.1.1/cgm_version.h:1:#define CGM_MAJOR_VERSION 13 branches/cubit/geom/GeometryQueryTool.hpp:1037: static const int CGM_MAJOR_VERSION; branches/cubit/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; branches/cubit14.0/geom/GeometryQueryTool.hpp:1075: static const int CGM_MAJOR_VERSION; branches/cubit14.0/geom/GeometryQueryTool.cpp:96:const int GeometryQueryTool::CGM_MAJOR_VERSION = 13; branches/merge-cubit12.2/cgm_version.h:1:#define CGM_MAJOR_VERSION 12 branches/cgm13.1/geom/GeometryQueryTool.hpp:1117: static const int CGM_MAJOR_VERSION; branches/cgm13.1/geom/GeometryQueryTool.cpp:95:const int GeometryQueryTool::CGM_MAJOR_VERSION = 13; branches/Version12.2/geom/GeometryQueryTool.hpp:1059: static const int CGM_MAJOR_VERSION; branches/Version12.2/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; branches/merge-cubit13.1/geom/GeometryQueryTool.hpp:1077: static const int CGM_MAJOR_VERSION; branches/merge-cubit13.1/geom/GeometryQueryTool.cpp:95:const int GeometryQueryTool::CGM_MAJOR_VERSION = 13; branches/dispatch/geom/GeometryQueryTool.hpp:1059: static const int CGM_MAJOR_VERSION; branches/dispatch/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; branches/cubit13.1/geom/GeometryQueryTool.hpp:1077: static const int CGM_MAJOR_VERSION; branches/cubit13.1/geom/GeometryQueryTool.cpp:95:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; branches/merge-cubit12/geom/GeometryQueryTool.hpp:1059: static const int CGM_MAJOR_VERSION; branches/merge-cubit12/geom/GeometryQueryTool.cpp:91:const int GeometryQueryTool::CGM_MAJOR_VERSION = 10; Note: this variable does not appear to be used within CGM, although there is probably some value in updating some of these locations that currently carry the wrong value. If I then search for CGM_MAJOR_VERSION in MOAB, I get: wilsonp@TodlawXPS ~/UW/research/software/moab (master) > ack-grep CGM_MAJOR_VERSION src/io/ReadCGM.cpp 318:#if CGM_MAJOR_VERSION>13 329:#if CGM_MAJOR_VERSION>13 340:#if CGM_MAJOR_VERSION>13 380:#if CGM_MAJOR_VERSION>13 484:#if CGM_MAJOR_VERSION>12 So... it appears we may be the primary (only?) users of this variable as the primary (only?) users of ReadCGM. It seems that this could be resolved by a combination of removing some outdated branches and backporting cgm_version.h into those branches that remain. Let us know how we can help? Paul On 01/29/2014 02:42 PM, Tim Tautges (ANL) wrote: > Jane's off this week on personal leave, so we probably won't hear from > her until next week. > > But, keep in mind that a) ReadCGM is part of MOAB, so that's in the > mix too, and b) we can check for that file in the configure process > and set a cpp variable accordingly. > > - tim > > On 01/29/2014 09:49 AM, Grindeanu, Iulian R. wrote: >> Jane ? maybe there should be a better way of managing >> versions/branches/releases/tags? >> I can't answer any of those questions Andy and David have. I know >> that there is a plan to move cgm on bitbucket, but the >> releases/branches/tags will all be ported as they are now. >> Iulian >> _ >> ______________________________________ >> From: Andrew Davis [davisa(a)engr.wisc.edu<mailto:[email protected]>] >> Sent: Wednesday, January 29, 2014 9:27 AM >> To: Grindeanu, Iulian R.; Paul Wilson; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> >> Subject: Re: [cgma-dev] Cubit 14 >> >> Hi Iulian >> >> cgmurl I can see, I doubt I have ever used it, why is there more than >> one for cubit12.2? >> >> Also I was using 13.1 from branches (no cgm_version.h) , not 13.1.1 >> from tags (which has cgm_version.h) >> >> Out of curiosity, should there not be a 13.1.1 on branches? Perhaps now >> that 13.1 is out of date you could replace it with >> 13.1.1? Same for 12.2-merge? >> >> Andy >> >> >> On 01/29/2014 09:19 AM, Grindeanu, Iulian R. wrote: >>> buildbot uses these: >>> cgmurl = >>> 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/branches/merge-cubit12.2' >>> for cubit 12.2 >>> >>> cgmurlt1311 = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.1' >>> for cubit 13.1 >>> >>> cgmurltrunk = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk' >>> for Cubit14.0 >>> >>> What versions are you using? >>> What is not compiling for you? >>> >>> Iulian >>> ________________________________________ >>> From: Paul Wilson [wilsonp(a)engr.wisc.edu<mailto:[email protected]>] >>> Sent: Wednesday, January 29, 2014 9:15 AM >>> To: Andrew Davis; Grindeanu, Iulian R.; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> >>> Subject: Re: [cgma-dev] Cubit 14 >>> >>> Hi Andy, >>> >>> Can you remind me of the specific symptom? Is it the existence of the >>> version file that needs to be backported (perhaps not), or is it the >>> use >>> of the version info to change the behavior that needs to be backported >>> (perhaps)? >>> >>> Paul >>> >>> On 01/29/2014 09:10 AM, Andrew Davis wrote: >>>> Hi Julian >>>> >>>> The SVN >>>> >>>> Andy >>>> >>>> >>>> On 01/29/2014 09:07 AM, Grindeanu, Iulian R. wrote: >>>>> I think that current branches (mergecubit12.2, trunk, ) all have that >>>>> file; at least buildbot is not complaining. >>>>> Are you using a release tar file or svn repo? >>>>> ________________________________________ >>>>> From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]>] on >>>>> behalf of Andrew Davis [davisa(a)engr.wisc.edu<mailto:[email protected]>] >>>>> Sent: Wednesday, January 29, 2014 9:05 AM >>>>> To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> >>>>> Subject: [cgma-dev] Cubit 14 >>>>> >>>>> This is question kind of linked to both CGM and MOAB >>>>> >>>>> Jane fixed readCGM.cpp in MOAB, however this fix only works for CGM, >>>>> since it relies on cgm_version.h, which was included in CGM14.0, >>>>> however, when we compile with any version previous we do not have >>>>> this >>>>> header file availble to us. Would it be possible to back port the >>>>> cgm_version.h file back into previous CGM releases? >>>>> >>>>> Thanks >>>>> >>>>> Andy >>> -- >>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- >>> Paul Wilson ~ UW-Madison ~ 608-263-0807<tel:608-263-0807> ~ cal: http://bit.ly/pphw-cal >>> Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu >>> Faculty Director, Advanced Computing Infrastructure >>> >>> >> > -- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul Wilson ~ UW-Madison ~ 608-263-0807<tel: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) -- 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] Cubit 14
by Jane Hu 05 Feb '14

05 Feb '14

I've just did it, please double check. Thanks, Iulian! Jane On Wed, Feb 5, 2014 at 11:52 AM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov>wrote: > So that branch cgm12.2 is very old. > Can you restore merge-cubit12.2 branch and rename it cgm12.2 ? > these are the differences in iGeom.h, between the branch that worked and > the branch that does not (cgm12.2 is way too old, I think) > > gnep~/install/cubser/cgm/include> diff iGeom.h > /disks/itaps-buildslave/cgm-shared/build/itaps/ > 77a78 > > * \param *err Pointer to error type returned from function > 81a83 > > int* err, > 89a92 > > * \param *err Pointer to error type returned from function > 92c95,96 > < /*out*/ int *error_type ); > --- > > /*out*/ int *error_type, > > int *err ); > 457,486c461 > < * For surfaces, closest point could be on the void space inside it. > < * Get closest point for an array of entities and points. If either > the > < * number of entities or number of coordinate triples is unity, then > all > < * points or entities are queried for that entity or point, > respectively, > < * otherwise each point corresponds to each entity. storage_order > should be > < * a value in the iBase_StorageOrder enum. > < * \param instance iGeom instance handle > < * \param entity_handles Entity(ies) being queried > < * \param entity_handles_size Number of entities being queried > < * \param storage_order Storage order of input points > < * \param near_coordinates Coordinates of starting point(s) > < * \param near_coordinates_size Number of values in near_coordinates > array > < * \param on_coordinates Coordinates of closest points > < * \param on_coordinates_allocated Allocated size of closest point > array > < * \param on_coordinates_size Occupied size of closest point array > < * \param *err Pointer to error type returned from function > < */ > < > < void iGeom_getEntClosestPtTrimmed( iGeom_Instance instance, > < iBase_EntityHandle entity_handle, > < double near_x, > < double near_y, > < double near_z, > < double* on_x, > < double* on_y, > < double* on_z, > < int* err ); > < > < /**\brief Get closest point for an array of entities and points > < * For surfaces, it made sure the closest point in on surface. > --- > > * > 1220c1195 > < void iGeom_getEgFcSense( iGeom_Instance instance, > --- > > void iGeom_getEgFcSense( iGeom_Instance, > 2712c2687 > < void iGeom_uniteEnts( iGeom_Instance instance, > --- > > void iGeom_uniteEnts( iGeom_Instance instace, > 3953,3980d3927 > < /**\brief Return facet information from solid modeling engine > < * > < * Return facet information from solid modeling engine > < * \param instance iGeom instance handle > < * \param entity_handle Entity being queried > < * \param dist_tolerance Tolerance guidance for faceting engine > < * \param points List of vertices in faceting of curve or surface > < * \param points_allocated Allocated size of vertex list array > < * \param points_size Occupied size of vertex list array > < * \param facets List of facets in faceting of surface > < * \param facets_allocated Allocated size of facet list array > < * \param facets_size Occupied size of facet list array > < * \param *err Pointer to error type returned from function > < */ > < void iGeom_getFacets(iGeom_Instance instance, > < iBase_EntityHandle entity, > < double dist_tolerance, > < double **points, int *points_allocated, int > *points_size, > < int **facets, int *facets_allocated, int > *facets_size, > < int *err); > < > < /* checks if a point is on a surface or a curve or a body*/ > < void iGeom_isPositionOn(iGeom_Instance instance, > < iBase_EntityHandle entity, > < double x, > < double y, > < double z, > < int *isOn); > 3982c3929 > < } /* extern "C" */ > --- > > } // extern "C" > gnep~/install/cubser/cgm/include> > > ------------------------------ > *From:* Grindeanu, Iulian R. > *Sent:* Wednesday, February 05, 2014 11:38 AM > *To:* Jane Hu > > *Cc:* Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov > *Subject:* RE: [cgma-dev] Cubit 14 > > well, cgm12.2 branch seems to be different from former > mergecubit12.2 > failure appears in lasso > > Can you check? > > Iulian > ------------------------------ > *From:* Jane Hu [janejhu(a)gmail.com] > *Sent:* Wednesday, February 05, 2014 11:05 AM > *To:* Grindeanu, Iulian R. > *Cc:* Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev(a)mcs.anl.gov > *Subject:* Re: [cgma-dev] Cubit 14 > > Thanks, Iulian. Yes, we can use branches/cgm12.2 and branches/cgm13.1 > for nightly build and get rid of others. Can you try them tonight? and > hopefully they should run well, there's not essential code changes besides > the name changes. > > Jane > > > On Wed, Feb 5, 2014 at 10:44 AM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov>wrote: > >> Hi Jane, >> Buildbot was using >> cgmurl = ' >> https://svn.mcs.anl.gov/repos/ITAPS/cgm/branches/merge-cubit12.2' >> for 12.2 >> Notice an extra .2 :( >> >> Should it use now branches/cgm12.2 ? >> Also, instead of cgmurlt1311 = ' >> https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.1' >> should it use >> branches/cgm13.1 ? >> >> There were 10 failures last night because of missing urls :( >> >> Iulian >> ------------------------------ >> *From:* Jane Hu [janejhu(a)gmail.com] >> *Sent:* Wednesday, February 05, 2014 10:18 AM >> *To:* Grindeanu, Iulian R. >> *Cc:* Paul Wilson; Tautges, Timothy J.; Andrew Davis; >> cgma-dev(a)mcs.anl.gov >> >> *Subject:* Re: [cgma-dev] Cubit 14 >> >> Hi, All >> >> I just made some changes according to email exchanges, please comment >> on if it's made the svn version of cgm system clearer. Keep in mind that it >> will be moved to git soon... >> >> Based on popular request, the branches are kept for continued >> development while the tags are snapshot of releases. I changed in following >> directories : >> >> Previous branch merge-cubit12 to branch cgm12.2, for continued >> enhancement development for version 12.2 or backport from above versions, >> if needed. >> >> Previous tags/13.1.1 to branches/cgm13.1, overwriting previous branch >> cgm13.1, and removed previous branch merge-cubit13.1(not developping any >> more on this branch), for continued enhancement development of version 13.1 >> or backport from above versions, if needed. >> >> Tagged previous merge-cubit12 as tags/12.2.1, changed the version, >> minor and patch numbers accordingly in configure.ac and cgm_version.h. >> >> Trunk as development branch for cgm14.0 remains unchanged. >> >> For cgm repo. users, please download codes from following locations: >> tags/12.2.1 for cgm12.2 stable releases; >> tags/13.1.1 for cgm13.1 stable releases; >> trunk for cgm14.0 development code; >> >> Please do not use other repo locations to download cgm code since they >> may be outdated or unstable. >> >> cgm_version.h was added in trunk development and backported to cgm12.2 >> and cgm13.1 to support MOAB version query needs, current MOAB is in stable >> state using version numbers defined in each location. >> >> Hope it clarify the confusions, and go ahead, happy coding! >> >> Jane >> >> >> >> >> >> On Tue, Feb 4, 2014 at 5:12 PM, Grindeanu, Iulian R. <iulian(a)mcs.anl.gov>wrote: >> >>> OK, another source of confusion is in configure.ac; >>> does the configure.ac need to contain the version, minor, and patch >>> numbers? >>> If those would be correct (updated), then >>> make dist >>> would create a tarball with the right name (cgma-13.1.tar.gz, or 13.1.1, >>> etc) >>> >>> should we remove the branches that are not active anymore? >>> >>> Iulian >>> >>> ________________________________________ >>> From: Paul Wilson [wilsonp(a)engr.wisc.edu] >>> Sent: Tuesday, February 04, 2014 3:23 PM >>> To: Tautges, Timothy J.; Grindeanu, Iulian R.; Andrew Davis; >>> cgma-dev(a)mcs.anl.gov >>> Subject: Re: [cgma-dev] Cubit 14 >>> >>> Hi all, >>> >>> Perhaps this sheds some light on the situation: >>> >>> wilsonp@TodlawXPS ~/UW/research/software/cgm > find branches tags -depth >>> -maxdepth 1 >>> branches/cubit >>> branches/cubit14.0 >>> branches/merge-cubit12.2 >>> branches/cgm13.1 >>> branches/Version12.2 >>> branches/merge-cubit13.1 >>> branches/dispatch >>> branches/cubit13.1 >>> branches/merge-cubit12 >>> branches >>> tags/12.2.0b1 >>> tags/13.1.0 >>> tags/cubit10.2 >>> tags/12.2.0 >>> tags/13.1.1 >>> tags >>> wilsonp@TodlawXPS ~/UW/research/software/cgm > find . -name >>> "cgm_version.h" >>> ./trunk/cgm_version.h >>> ./tags/13.1.0/cgm_version.h >>> ./tags/13.1.1/cgm_version.h >>> ./branches/merge-cubit12.2/cgm_version.h >>> >>> As you can see, there are many branches and tags, but only three of them >>> plus the trunk have the cgm_version.h file. >>> >>> If I then search all the code for the use of CGM_MAJOR_VERSION, I get >>> the following: >>> >>> trunk/cgm_version.h:1:#define CGM_MAJOR_VERSION 14 >>> tags/12.2.0b1/geom/GeometryQueryTool.hpp:1059: static const int >>> CGM_MAJOR_VERSION; >>> tags/12.2.0b1/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> tags/13.1.0/cgm_version.h:1:#define CGM_MAJOR_VERSION 13 >>> tags/cubit10.2/geom/GeometryQueryTool.hpp:826: static const int >>> CGM_MAJOR_VERSION; >>> tags/cubit10.2/geom/GeometryQueryTool.cpp:81:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> tags/12.2.0/geom/GeometryQueryTool.hpp:1059: static const int >>> CGM_MAJOR_VERSION; >>> tags/12.2.0/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> tags/13.1.1/cgm_version.h:1:#define CGM_MAJOR_VERSION 13 >>> branches/cubit/geom/GeometryQueryTool.hpp:1037: static const int >>> CGM_MAJOR_VERSION; >>> branches/cubit/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> branches/cubit14.0/geom/GeometryQueryTool.hpp:1075: static const int >>> CGM_MAJOR_VERSION; >>> branches/cubit14.0/geom/GeometryQueryTool.cpp:96:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 13; >>> branches/merge-cubit12.2/cgm_version.h:1:#define CGM_MAJOR_VERSION 12 >>> branches/cgm13.1/geom/GeometryQueryTool.hpp:1117: static const int >>> CGM_MAJOR_VERSION; >>> branches/cgm13.1/geom/GeometryQueryTool.cpp:95:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 13; >>> branches/Version12.2/geom/GeometryQueryTool.hpp:1059: static const int >>> CGM_MAJOR_VERSION; >>> branches/Version12.2/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> branches/merge-cubit13.1/geom/GeometryQueryTool.hpp:1077: static const >>> int CGM_MAJOR_VERSION; >>> branches/merge-cubit13.1/geom/GeometryQueryTool.cpp:95:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 13; >>> branches/dispatch/geom/GeometryQueryTool.hpp:1059: static const int >>> CGM_MAJOR_VERSION; >>> branches/dispatch/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> branches/cubit13.1/geom/GeometryQueryTool.hpp:1077: static const int >>> CGM_MAJOR_VERSION; >>> branches/cubit13.1/geom/GeometryQueryTool.cpp:95:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> branches/merge-cubit12/geom/GeometryQueryTool.hpp:1059: static const >>> int CGM_MAJOR_VERSION; >>> branches/merge-cubit12/geom/GeometryQueryTool.cpp:91:const int >>> GeometryQueryTool::CGM_MAJOR_VERSION = 10; >>> >>> Note: this variable does not appear to be used within CGM, although >>> there is probably some value in updating some of these locations that >>> currently carry the wrong value. >>> >>> If I then search for CGM_MAJOR_VERSION in MOAB, I get: >>> >>> wilsonp@TodlawXPS ~/UW/research/software/moab (master) > ack-grep >>> CGM_MAJOR_VERSION >>> src/io/ReadCGM.cpp >>> 318:#if CGM_MAJOR_VERSION>13 >>> 329:#if CGM_MAJOR_VERSION>13 >>> 340:#if CGM_MAJOR_VERSION>13 >>> 380:#if CGM_MAJOR_VERSION>13 >>> 484:#if CGM_MAJOR_VERSION>12 >>> >>> >>> So... it appears we may be the primary (only?) users of this variable as >>> the primary (only?) users of ReadCGM. >>> >>> It seems that this could be resolved by a combination of removing some >>> outdated branches and backporting cgm_version.h into those branches that >>> remain. >>> >>> Let us know how we can help? >>> >>> Paul >>> >>> >>> On 01/29/2014 02:42 PM, Tim Tautges (ANL) wrote: >>> > Jane's off this week on personal leave, so we probably won't hear from >>> > her until next week. >>> > >>> > But, keep in mind that a) ReadCGM is part of MOAB, so that's in the >>> > mix too, and b) we can check for that file in the configure process >>> > and set a cpp variable accordingly. >>> > >>> > - tim >>> > >>> > On 01/29/2014 09:49 AM, Grindeanu, Iulian R. wrote: >>> >> Jane ? maybe there should be a better way of managing >>> >> versions/branches/releases/tags? >>> >> I can't answer any of those questions Andy and David have. I know >>> >> that there is a plan to move cgm on bitbucket, but the >>> >> releases/branches/tags will all be ported as they are now. >>> >> Iulian >>> >> _ >>> >> ______________________________________ >>> >> From: Andrew Davis [davisa(a)engr.wisc.edu] >>> >> Sent: Wednesday, January 29, 2014 9:27 AM >>> >> To: Grindeanu, Iulian R.; Paul Wilson; cgma-dev(a)mcs.anl.gov >>> >> Subject: Re: [cgma-dev] Cubit 14 >>> >> >>> >> Hi Iulian >>> >> >>> >> cgmurl I can see, I doubt I have ever used it, why is there more than >>> >> one for cubit12.2? >>> >> >>> >> Also I was using 13.1 from branches (no cgm_version.h) , not 13.1.1 >>> >> from tags (which has cgm_version.h) >>> >> >>> >> Out of curiosity, should there not be a 13.1.1 on branches? Perhaps >>> now >>> >> that 13.1 is out of date you could replace it with >>> >> 13.1.1? Same for 12.2-merge? >>> >> >>> >> Andy >>> >> >>> >> >>> >> On 01/29/2014 09:19 AM, Grindeanu, Iulian R. wrote: >>> >>> buildbot uses these: >>> >>> cgmurl = >>> >>> 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/branches/merge-cubit12.2' >>> >>> for cubit 12.2 >>> >>> >>> >>> cgmurlt1311 = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/tags/13.1.1' >>> >>> for cubit 13.1 >>> >>> >>> >>> cgmurltrunk = 'https://svn.mcs.anl.gov/repos/ITAPS/cgm/trunk' >>> >>> for Cubit14.0 >>> >>> >>> >>> What versions are you using? >>> >>> What is not compiling for you? >>> >>> >>> >>> Iulian >>> >>> ________________________________________ >>> >>> From: Paul Wilson [wilsonp(a)engr.wisc.edu] >>> >>> Sent: Wednesday, January 29, 2014 9:15 AM >>> >>> To: Andrew Davis; Grindeanu, Iulian R.; cgma-dev(a)mcs.anl.gov >>> >>> Subject: Re: [cgma-dev] Cubit 14 >>> >>> >>> >>> Hi Andy, >>> >>> >>> >>> Can you remind me of the specific symptom? Is it the existence of >>> the >>> >>> version file that needs to be backported (perhaps not), or is it the >>> >>> use >>> >>> of the version info to change the behavior that needs to be >>> backported >>> >>> (perhaps)? >>> >>> >>> >>> Paul >>> >>> >>> >>> On 01/29/2014 09:10 AM, Andrew Davis wrote: >>> >>>> Hi Julian >>> >>>> >>> >>>> The SVN >>> >>>> >>> >>>> Andy >>> >>>> >>> >>>> >>> >>>> On 01/29/2014 09:07 AM, Grindeanu, Iulian R. wrote: >>> >>>>> I think that current branches (mergecubit12.2, trunk, ) all have >>> that >>> >>>>> file; at least buildbot is not complaining. >>> >>>>> Are you using a release tar file or svn repo? >>> >>>>> ________________________________________ >>> >>>>> From: cgma-dev-bounces(a)mcs.anl.gov [cgma-dev-bounces(a)mcs.anl.gov] >>> on >>> >>>>> behalf of Andrew Davis [davisa(a)engr.wisc.edu] >>> >>>>> Sent: Wednesday, January 29, 2014 9:05 AM >>> >>>>> To: cgma-dev(a)mcs.anl.gov >>> >>>>> Subject: [cgma-dev] Cubit 14 >>> >>>>> >>> >>>>> This is question kind of linked to both CGM and MOAB >>> >>>>> >>> >>>>> Jane fixed readCGM.cpp in MOAB, however this fix only works for >>> CGM, >>> >>>>> since it relies on cgm_version.h, which was included in CGM14.0, >>> >>>>> however, when we compile with any version previous we do not have >>> >>>>> this >>> >>>>> header file availble to us. Would it be possible to back port the >>> >>>>> cgm_version.h file back into previous CGM releases? >>> >>>>> >>> >>>>> Thanks >>> >>>>> >>> >>>>> Andy >>> >>> -- >>> >>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >>> -- >>> >>> 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 >>> >>> >>> >>> >>> >> >>> > >>> >>> -- >>> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- >>> 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) > -- 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