[cgma-dev] Cubit 14
Grindeanu, Iulian R.
iulian at mcs.anl.gov
Wed Feb 5 11:52:56 CST 2014
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 at 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 at gmail.com]
Sent: Wednesday, February 05, 2014 11:05 AM
To: Grindeanu, Iulian R.
Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev at 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 at mcs.anl.gov<mailto:iulian at 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 at gmail.com<mailto:janejhu at gmail.com>]
Sent: Wednesday, February 05, 2014 10:18 AM
To: Grindeanu, Iulian R.
Cc: Paul Wilson; Tautges, Timothy J.; Andrew Davis; cgma-dev at mcs.anl.gov<mailto:cgma-dev at 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<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 at mcs.anl.gov<mailto:iulian at mcs.anl.gov>> 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 at engr.wisc.edu<mailto:wilsonp at engr.wisc.edu>]
Sent: Tuesday, February 04, 2014 3:23 PM
To: Tautges, Timothy J.; Grindeanu, Iulian R.; Andrew Davis; cgma-dev at mcs.anl.gov<mailto:cgma-dev at mcs.anl.gov>
Subject: Re: [cgma-dev] Cubit 14
Hi all,
Perhaps this sheds some light on the situation:
wilsonp at 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 at 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 at 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 at engr.wisc.edu<mailto:davisa at engr.wisc.edu>]
>> Sent: Wednesday, January 29, 2014 9:27 AM
>> To: Grindeanu, Iulian R.; Paul Wilson; cgma-dev at mcs.anl.gov<mailto:cgma-dev at 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 at engr.wisc.edu<mailto:wilsonp at engr.wisc.edu>]
>>> Sent: Wednesday, January 29, 2014 9:15 AM
>>> To: Andrew Davis; Grindeanu, Iulian R.; cgma-dev at mcs.anl.gov<mailto:cgma-dev at 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 at mcs.anl.gov<mailto:cgma-dev-bounces at mcs.anl.gov> [cgma-dev-bounces at mcs.anl.gov<mailto:cgma-dev-bounces at mcs.anl.gov>] on
>>>>> behalf of Andrew Davis [davisa at engr.wisc.edu<mailto:davisa at engr.wisc.edu>]
>>>>> Sent: Wednesday, January 29, 2014 9:05 AM
>>>>> To: cgma-dev at mcs.anl.gov<mailto:cgma-dev at 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<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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140205/a7d13294/attachment-0001.html>
More information about the cgma-dev
mailing list