[cgma-dev] Cubit 14
Jane Hu
janejhu at gmail.com
Wed Feb 5 12:53:31 CST 2014
I've just did it, please double check. Thanks, Iulian!
Jane
On Wed, Feb 5, 2014 at 11:52 AM, Grindeanu, Iulian R. <iulian at 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 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>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]
>> *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
>>
>> *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 at 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 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
>>> 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]
>>> >> Sent: Wednesday, January 29, 2014 9:27 AM
>>> >> To: Grindeanu, Iulian R.; Paul Wilson; 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]
>>> >>> Sent: Wednesday, January 29, 2014 9:15 AM
>>> >>> To: Andrew Davis; Grindeanu, Iulian R.; 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 [cgma-dev-bounces at mcs.anl.gov]
>>> on
>>> >>>>> behalf of Andrew Davis [davisa at engr.wisc.edu]
>>> >>>>> Sent: Wednesday, January 29, 2014 9:05 AM
>>> >>>>> To: 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 ~ 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140205/aebd6a87/attachment-0001.html>
More information about the cgma-dev
mailing list