OK, last night, everything was fine. Thanks, Iulian ________________________________ From: Jane Hu [[email protected]] Sent: Wednesday, February 05, 2014 12:53 PM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; [email protected] 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. <[email protected]<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; [email protected]<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 [[email protected]<mailto:[email protected]>] Sent: Wednesday, February 05, 2014 11:05 AM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; [email protected]<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. <[email protected]<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 [[email protected]<mailto:[email protected]>] Sent: Wednesday, February 05, 2014 10:18 AM To: Grindeanu, Iulian R. Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; [email protected]<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. <[email protected]<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 [[email protected]<mailto:[email protected]>] Sent: Tuesday, February 04, 2014 3:23 PM To: Tautges, Timothy J.; Grindeanu, Iulian R.; Andrew Davis; [email protected]<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 [[email protected]<mailto:[email protected]>] Sent: Wednesday, January 29, 2014 9:27 AM To: Grindeanu, Iulian R.; Paul Wilson; [email protected]<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 [[email protected]<mailto:[email protected]>] Sent: Wednesday, January 29, 2014 9:15 AM To: Andrew Davis; Grindeanu, Iulian R.; [email protected]<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: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Andrew Davis [[email protected]<mailto:[email protected]>] Sent: Wednesday, January 29, 2014 9:05 AM To: [email protected]<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)