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

Re: [cgma-dev] Facet/Cholla engine
by David Thompson 22 Jan '14

22 Jan '14

Hi Jane, > I tried both of your programs, you are right that the key for success in build_facet_surface relies on the how the CubitPoints are defined. I have observed the following: Thanks for the confirmation. It would be great if your observations and/or the documentation string in my earlier message could be put in the build_facet_surface() documentation of geom/facet/FacetModifyEngine.hpp so that people don't have to search the mailing list to find out how to use the engine. Should I try to merge your observations into the documentation below? Thanks, David > > 1. If you define new CubitPoints for each facet, even they share the same location, the code is creating separate surface for each facet. > > 2. It doens't matter if you provide the point list or not as long as the facets are created through different sets of points. I attach another file here to demonstrate, where you can see, if you define 4 facets using 12 different points (just pointer different), even you don't provide the point list, the code still generates 4 surfaces(which is prefered). When building a body, the duplicate vertices and edges are merged, leaving 4 refedges and 4 refpoints in the model. > > 3. If you define facets using shared points, you indicates to connect the edges and don't separate the model on the points. In this case, you have to give all such facets in one build_facet_surface call, otherwise, code crashes on not being able to find the shared edges. > > I'll put the feature-angle issue as an enhancement bug to the system. > > Thanks and have a nice day! > > Jane > > > > > On Sat, Jan 18, 2014 at 3:08 PM, David Thompson <david.thompson(a)kitware.com> wrote: > Hi Jane, > > I've found a combination of things that allow me to build models with multiple faceted surfaces per shell. It boils down to creating disjoint sets of CubitPointData instances for each FacetSurface, but which re-use a given CubitPoint shared among facets on the same FacetSurface. When multiple FacetSurfaces are combined into a shell, the facet engine merges the duplicate vertices on their common boundaries. I tried passing an empty point_list, but that failed. Passing CubitFacetData instances to the same build_facet_surface() call that have coincident points encoded in multiple CubitPointData instances (instead of a shared instance) also fails. Attached are working examples (one build 4 FacetSurfaces from 4 triangles, the other 2 FacetSurfaces from 4 triangles). > > It would be nice if the documentation for build_facet_surface() was updated to include some mention of this: > > //- Create one or more new FacetSurfaces with all of its lower > //- order entities. Use an optional feature_angle to break > //- surface. > //- > //- Where the input CubitFacet and/or CubitQuadFacet instances > //- share a vertex, they should reference the same CubitPoint > //- pointer. However, no CubitPoint instance shared with a > //- surface created by a separate call to build_facet_surface() > //- should be referenced; if multiple build_facet_surface() calls > //- are made, points on shared boundaries between will be merged > //- when the a shell containing the surfaces is created. > //- > //- The point_list should contain exactly the points in > //- the input facets and no others. > > I still have not been able to get surface-splitting by feature_angle working, so that is probably still worth a bug report. > > David > > > > > -- > 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) > <multifaceted-works.cxx>

1 0

Re: [cgma-dev] CMake build system
by Tim Tautges (ANL) 21 Jan '14

21 Jan '14

Actually, ideally, we'd like to get to the point of using the same CMakeLists.txt files as cubit uses, possibly modulo including / not including some of the init stuff unique to ANL's version of CGM (presumably controllable using a CMake variable/option). Sandia/CSimsoft peple, feel free to chime in here... - tim On 01/21/2014 11:01 AM, Jane Hu wrote: > David, > > The CMakeLists.txt files were from cubit14.0 codes, and were used for a reference when we integrated cgm on cubit for > file lists. But not actually used on CGM part. Please disregard this part of code. > > Jane > > > On Tue, Jan 21, 2014 at 10:49 AM, David Thompson <david.thompson(a)kitware.com <mailto:[email protected]>> wrote: > > Hi all, > > Now that I can build the most modern cgm on my machine, I see that some subdirectories of CGM now have > CMakeLists.txt files -- each creating a separate project, and with no toplevel project. When I add a toplevel > project, it does not quite build. When I fix it so things compile, there is no libcgm created; instead a separate > library exists for each subdirectory (I guess autoconf builds libcgm from these "convenience libraries"?). > > Are the CMake files work in progress or remnants that have been abandoned? > > Thanks, > David > > > > > -- > 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) -- ================================================================ "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

1 0

r6115 - cgm/trunk/test
by janehu＠mcs.anl.gov 21 Jan '14

21 Jan '14

Author: janehu Date: 2014-01-21 13:56:22 -0600 (Tue, 21 Jan 2014) New Revision: 6115 Added: cgm/trunk/test/multifaceted-2trisPerSurface-works.cxx cgm/trunk/test/multifaceted-works.cxx cgm/trunk/test/multifaceted.cpp Modified: cgm/trunk/test/Makefile.am Log: Adding three tests for facet engine creating surfaces from facets. Provided by David Thompson. Modified: cgm/trunk/test/Makefile.am =================================================================== --- cgm/trunk/test/Makefile.am 2014-01-21 16:28:34 UTC (rev 6114) +++ cgm/trunk/test/Makefile.am 2014-01-21 19:56:22 UTC (rev 6115) @@ -16,7 +16,7 @@ TESTS += webcut hollow_acis brick_acis merge_acis AngleCalc_acis CreateGeometry_acis GraphicsData_acis else if WITH_CUBIT - TESTS += webcut merge_acis brick_acis spheres cylinders + TESTS += webcut merge_acis brick_acis spheres cylinders multifaceted_works multifaceted_2trisPerSurface_works multifaceted else TESTS += brick_facet merge_facet if DEV @@ -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 + 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 endif check_PROGRAMS = $(TESTS) @@ -45,6 +45,9 @@ libcgm_test_la_SOURCES = TestUtilities.hpp \ TestUtilities.cpp +multifaceted_2trisPerSurface_works_SOURCES = multifaceted-2trisPerSurface-works.cxx +multifaceted_works_SOURCES = multifaceted-works.cxx +multifaceted_SOURCES = multifaceted.cpp cylinders_SOURCES = cylinders.cpp spheres_SOURCES = spheres.cpp webcut_SOURCES = webcut.cpp @@ -167,6 +170,9 @@ fillet.occ \ curves.brep \ spheres.sat \ + multifaceted-2trisPerSurface-works.stl \ + multifaceted-works.stl \ + multifaceted.stl \ mmgr.log Added: cgm/trunk/test/multifaceted-2trisPerSurface-works.cxx =================================================================== --- cgm/trunk/test/multifaceted-2trisPerSurface-works.cxx (rev 0) +++ cgm/trunk/test/multifaceted-2trisPerSurface-works.cxx 2014-01-21 19:56:22 UTC (rev 6115) @@ -0,0 +1,126 @@ +#include "AppUtil.hpp" +#include "CGMApp.hpp" +#include "GeometryQueryTool.hpp"

1 0

Re: [cgma-dev] Facet/Cholla engine
by Jane Hu 21 Jan '14

21 Jan '14

David, I tried both of your programs, you are right that the key for success in build_facet_surface relies on the how the CubitPoints are defined. I have observed the following: 1. If you define new CubitPoints for each facet, even they share the same location, the code is creating separate surface for each facet. 2. It doens't matter if you provide the point list or not as long as the facets are created through different sets of points. I attach another file here to demonstrate, where you can see, if you define 4 facets using 12 different points (just pointer different), even you don't provide the point list, the code still generates 4 surfaces(which is prefered). When building a body, the duplicate vertices and edges are merged, leaving 4 refedges and 4 refpoints in the model. 3. If you define facets using shared points, you indicates to connect the edges and don't separate the model on the points. In this case, you have to give all such facets in one build_facet_surface call, otherwise, code crashes on not being able to find the shared edges. I'll put the feature-angle issue as an enhancement bug to the system. Thanks and have a nice day! Jane On Sat, Jan 18, 2014 at 3:08 PM, David Thompson <david.thompson(a)kitware.com>wrote: > Hi Jane, > > I've found a combination of things that allow me to build models with > multiple faceted surfaces per shell. It boils down to creating disjoint > sets of CubitPointData instances for each FacetSurface, but which re-use a > given CubitPoint shared among facets on the same FacetSurface. When > multiple FacetSurfaces are combined into a shell, the facet engine merges > the duplicate vertices on their common boundaries. I tried passing an empty > point_list, but that failed. Passing CubitFacetData instances to the same > build_facet_surface() call that have coincident points encoded in multiple > CubitPointData instances (instead of a shared instance) also fails. > Attached are working examples (one build 4 FacetSurfaces from 4 triangles, > the other 2 FacetSurfaces from 4 triangles). > > It would be nice if the documentation for build_facet_surface() was > updated to include some mention of this: > > //- Create one or more new FacetSurfaces with all of its lower > //- order entities. Use an optional feature_angle to break > //- surface. > //- > //- Where the input CubitFacet and/or CubitQuadFacet instances > //- share a vertex, they should reference the same CubitPoint > //- pointer. However, no CubitPoint instance shared with a > //- surface created by a separate call to build_facet_surface() > //- should be referenced; if multiple build_facet_surface() calls > //- are made, points on shared boundaries between will be merged > //- when the a shell containing the surfaces is created. > //- > //- The point_list should contain exactly the points in > //- the input facets and no others. > > I still have not been able to get surface-splitting by feature_angle > working, so that is probably still worth a bug report. > > David > > -- 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] CMake build system
by Jane Hu 21 Jan '14

21 Jan '14

David, The CMakeLists.txt files were from cubit14.0 codes, and were used for a reference when we integrated cgm on cubit for file lists. But not actually used on CGM part. Please disregard this part of code. Jane On Tue, Jan 21, 2014 at 10:49 AM, David Thompson <david.thompson(a)kitware.com > wrote: > Hi all, > > Now that I can build the most modern cgm on my machine, I see that some > subdirectories of CGM now have CMakeLists.txt files -- each creating a > separate project, and with no toplevel project. When I add a toplevel > project, it does not quite build. When I fix it so things compile, there is > no libcgm created; instead a separate library exists for each subdirectory > (I guess autoconf builds libcgm from these "convenience libraries"?). > > Are the CMake files work in progress or remnants that have been abandoned? > > Thanks, > David -- 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

CMake build system
by David Thompson 21 Jan '14

21 Jan '14

Hi all, Now that I can build the most modern cgm on my machine, I see that some subdirectories of CGM now have CMakeLists.txt files -- each creating a separate project, and with no toplevel project. When I add a toplevel project, it does not quite build. When I fix it so things compile, there is no libcgm created; instead a separate library exists for each subdirectory (I guess autoconf builds libcgm from these "convenience libraries"?). Are the CMake files work in progress or remnants that have been abandoned? Thanks, David

1 0

Re: [cgma-dev] Missing include on Mavericks (+patch)
by Jane Hu 21 Jan '14

21 Jan '14

Thank you, David! I've double checked on linux platform, and it works too. Already check it in the cgm system, revision 6114. Jane On Mon, Jan 20, 2014 at 12:22 PM, David Thompson <david.thompson(a)kitware.com > wrote: > Hi all, > > I've found a fix for the Mavericks compile issue. The new Apple libc++ > uses a specialization for std::vector<bool> that prevents DLIList<bool> > from re-using the std::vector<X>::const_reference typedef blindly. The > following fixes things for me: > > --- a/util/DLIList.hpp > +++ b/util/DLIList.hpp > @@ -40,7 +40,7 @@ public: > friend class DLIListIterator<X>; > > typedef typename std::vector<X>::reference reference; > - typedef typename std::vector<X>::const_reference const_reference; > + typedef const typename std::vector<X>::value_type& const_reference; > typedef typename std::vector<X>::pointer pointer; > typedef typename std::vector<X>::const_pointer const_pointer; > > > and should work for other platforms. > > David > > > On Dec 10, 2013, at 1:21 PM, David Thompson <david.thompson(a)kitware.com> > wrote: > > > Hi Rajeev, > > > >> I’m getting similar error on Mavericks. > >> Did you find a solution? > > > > Not yet. My workaround is to use svn version 6078 with the patch at the > start of this thread. > > > > David > > > > > > > >>> From: David Thompson <david.thompson(a)kitware.com> > >>> Subject: Re: [cgma-dev] Missing include on Mavericks (+patch) > >>> Date: December 2, 2013 at 6:31:03 PM CST > >>> To: Jane Hu <janejhu(a)gmail.com> > >>> Cc: CGMA Development <cgma-dev(a)mcs.anl.gov> > >>> > >>> Hi Jane, > >>> > >>>> Current trunk is only buildable with occ, there's a bug which prevent > cubit build on cgm14.0 and I am working on it. > >>> > >>> I am using OCC, so that's not the problem. > >>> > >>>> ... Please let us know when you figured out the cause. > >>> > >>> OK. > >>> > >>> Thanks, > >>> David > >>> > >>>> On Mon, Dec 2, 2013 at 3:08 PM, David Thompson < > david.thompson(a)kitware.com> wrote: > >>>> Hi Jane, > >>>> > >>>>> It's just been done. Happy coding! > >>>> > >>>> Thanks! However, when I updated to catch this fix, I ran into another > issue: > >>>> > >>>> libtool: compile: clang++ -I. -I/Users/dcthomp/Source/cgm/geom -I.. > -I../geom/parallel -I../itaps -I/Users/dcthomp/Source/cgm/util -I. -g -Wall > -mmacosx-version-min=10.9 > --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk > -arch x86_64 -Wall -pipe -pedantic -MT CubitAttribManager.lo -MD -MP -MF > .deps/CubitAttribManager.Tpo -c > /Users/dcthomp/Source/cgm/geom/CubitAttribManager.cpp -fno-common -DPIC -o > .libs/CubitAttribManager.o > >>>> /Users/dcthomp/Source/cgm/geom/CubitAttribManager.cpp:108:28: error: > no viable conversion from 'CubitBoolean' (aka 'bool') to > >>>> 'const_reference' (aka > '__bit_const_reference<std::__1::vector<bool, std::__1::allocator<bool> > > >') > >>>> mAutoActuateFlags.append(auto_actuate_flag); > >>>> ^~~~~~~~~~~~~~~~~ > >>>> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__bit_reference:124:7: > note: > >>>> candidate constructor (the implicit copy constructor) not viable: > no known conversion from 'CubitBoolean' (aka 'bool') to > >>>> 'const std::__1::__bit_const_reference<std::__1::vector<bool, > std::__1::allocator<bool> > > &' for 1st argument > >>>> class __bit_const_reference > >>>> ^ > >>>> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__bit_reference:140:5: > note: > >>>> candidate constructor not viable: no known conversion from > 'CubitBoolean' (aka 'bool') to 'const > >>>> __bit_reference<std::__1::vector<bool, std::__1::allocator<bool> > > > &' for 1st argument > >>>> __bit_const_reference(const __bit_reference<_Cp>& __x) _NOEXCEPT > >>>> ^ > >>>> /Users/dcthomp/Source/cgm/util/DLIList.hpp:448:31: note: passing > argument to parameter 'new_item' here > >>>> void append(const_reference new_item); > >>>> ^ > >>>> > >>>> I haven't been able to figure out the source of this problem. Both > Apple's new C++ library and the old GNU one specialize vector<bool>, so > that does not appear to be the cause. If it helps, I had not updated since > before you moved the cubit-14 branch to the trunk. > >>>> > >>>> David > >>>> > >>>> > >>>>> On Mon, Dec 2, 2013 at 12:43 PM, David Thompson < > david.thompson(a)kitware.com> wrote: > >>>>> Hi all, > >>>>> > >>>>> When I try building on OS X Mavericks using the latest Xcode, I get > an error that pid_t is not defined in util/CubitProcess.h. It appears that > <unistd.h> must be included for this type to be defined. A patch is below. > Could someone apply it or help me revise it so I can build without patching > CGM? > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> --- a/util/CubitProcess.hpp > >>>>> +++ b/util/CubitProcess.hpp > >>>>> @@ -20,6 +20,7 @@ > >>>>> #include <windows.h> > >>>>> typedef PROCESS_INFORMATION PidType; > >>>>> #else > >>>>> +# include <unistd.h> > >>>>> typedef pid_t PidType; > >>>>> #endif > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> 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

r6114 - cgm/trunk/util
by janehu＠mcs.anl.gov 21 Jan '14

21 Jan '14

Author: janehu Date: 2014-01-21 10:28:34 -0600 (Tue, 21 Jan 2014) New Revision: 6114 Modified: cgm/trunk/util/DLIList.hpp Log: Check in fix for the Mavericks compile issue reported and solved by David Thompson. Double checked for occshared and static build as well as cubitshared build. All passed make check. Modified: cgm/trunk/util/DLIList.hpp =================================================================== --- cgm/trunk/util/DLIList.hpp 2014-01-08 18:21:46 UTC (rev 6113) +++ cgm/trunk/util/DLIList.hpp 2014-01-21 16:28:34 UTC (rev 6114) @@ -40,7 +40,7 @@ friend class DLIListIterator<X>; typedef typename std::vector<X>::reference reference; - typedef typename std::vector<X>::const_reference const_reference; + typedef const typename std::vector<X>::value_type& const_reference; typedef typename std::vector<X>::pointer pointer; typedef typename std::vector<X>::const_pointer const_pointer;

1 0

Re: [cgma-dev] Missing include on Mavericks (+patch)
by David Thompson 20 Jan '14

20 Jan '14

Hi all, I've found a fix for the Mavericks compile issue. The new Apple libc++ uses a specialization for std::vector<bool> that prevents DLIList<bool> from re-using the std::vector<X>::const_reference typedef blindly. The following fixes things for me: --- a/util/DLIList.hpp +++ b/util/DLIList.hpp @@ -40,7 +40,7 @@ public: friend class DLIListIterator<X>; typedef typename std::vector<X>::reference reference; - typedef typename std::vector<X>::const_reference const_reference; + typedef const typename std::vector<X>::value_type& const_reference; typedef typename std::vector<X>::pointer pointer; typedef typename std::vector<X>::const_pointer const_pointer; and should work for other platforms. David On Dec 10, 2013, at 1:21 PM, David Thompson <david.thompson(a)kitware.com> wrote: > Hi Rajeev, > >> I’m getting similar error on Mavericks. >> Did you find a solution? > > Not yet. My workaround is to use svn version 6078 with the patch at the start of this thread. > > David > > > >>> From: David Thompson <david.thompson(a)kitware.com> >>> Subject: Re: [cgma-dev] Missing include on Mavericks (+patch) >>> Date: December 2, 2013 at 6:31:03 PM CST >>> To: Jane Hu <janejhu(a)gmail.com> >>> Cc: CGMA Development <cgma-dev(a)mcs.anl.gov> >>> >>> Hi Jane, >>> >>>> Current trunk is only buildable with occ, there's a bug which prevent cubit build on cgm14.0 and I am working on it. >>> >>> I am using OCC, so that's not the problem. >>> >>>> ... Please let us know when you figured out the cause. >>> >>> OK. >>> >>> Thanks, >>> David >>> >>>> On Mon, Dec 2, 2013 at 3:08 PM, David Thompson <david.thompson(a)kitware.com> wrote: >>>> Hi Jane, >>>> >>>>> It's just been done. Happy coding! >>>> >>>> Thanks! However, when I updated to catch this fix, I ran into another issue: >>>> >>>> libtool: compile: clang++ -I. -I/Users/dcthomp/Source/cgm/geom -I.. -I../geom/parallel -I../itaps -I/Users/dcthomp/Source/cgm/util -I. -g -Wall -mmacosx-version-min=10.9 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -Wall -pipe -pedantic -MT CubitAttribManager.lo -MD -MP -MF .deps/CubitAttribManager.Tpo -c /Users/dcthomp/Source/cgm/geom/CubitAttribManager.cpp -fno-common -DPIC -o .libs/CubitAttribManager.o >>>> /Users/dcthomp/Source/cgm/geom/CubitAttribManager.cpp:108:28: error: no viable conversion from 'CubitBoolean' (aka 'bool') to >>>> 'const_reference' (aka '__bit_const_reference<std::__1::vector<bool, std::__1::allocator<bool> > >') >>>> mAutoActuateFlags.append(auto_actuate_flag); >>>> ^~~~~~~~~~~~~~~~~ >>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__bit_reference:124:7: note: >>>> candidate constructor (the implicit copy constructor) not viable: no known conversion from 'CubitBoolean' (aka 'bool') to >>>> 'const std::__1::__bit_const_reference<std::__1::vector<bool, std::__1::allocator<bool> > > &' for 1st argument >>>> class __bit_const_reference >>>> ^ >>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__bit_reference:140:5: note: >>>> candidate constructor not viable: no known conversion from 'CubitBoolean' (aka 'bool') to 'const >>>> __bit_reference<std::__1::vector<bool, std::__1::allocator<bool> > > &' for 1st argument >>>> __bit_const_reference(const __bit_reference<_Cp>& __x) _NOEXCEPT >>>> ^ >>>> /Users/dcthomp/Source/cgm/util/DLIList.hpp:448:31: note: passing argument to parameter 'new_item' here >>>> void append(const_reference new_item); >>>> ^ >>>> >>>> I haven't been able to figure out the source of this problem. Both Apple's new C++ library and the old GNU one specialize vector<bool>, so that does not appear to be the cause. If it helps, I had not updated since before you moved the cubit-14 branch to the trunk. >>>> >>>> David >>>> >>>> >>>>> On Mon, Dec 2, 2013 at 12:43 PM, David Thompson <david.thompson(a)kitware.com> wrote: >>>>> Hi all, >>>>> >>>>> When I try building on OS X Mavericks using the latest Xcode, I get an error that pid_t is not defined in util/CubitProcess.h. It appears that <unistd.h> must be included for this type to be defined. A patch is below. Could someone apply it or help me revise it so I can build without patching CGM? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> --- a/util/CubitProcess.hpp >>>>> +++ b/util/CubitProcess.hpp >>>>> @@ -20,6 +20,7 @@ >>>>> #include <windows.h> >>>>> typedef PROCESS_INFORMATION PidType; >>>>> #else >>>>> +# include <unistd.h> >>>>> typedef pid_t PidType; >>>>> #endif >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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] Facet/Cholla engine
by David Thompson 18 Jan '14

18 Jan '14

Hi Jane, I've found a combination of things that allow me to build models with multiple faceted surfaces per shell. It boils down to creating disjoint sets of CubitPointData instances for each FacetSurface, but which re-use a given CubitPoint shared among facets on the same FacetSurface. When multiple FacetSurfaces are combined into a shell, the facet engine merges the duplicate vertices on their common boundaries. I tried passing an empty point_list, but that failed. Passing CubitFacetData instances to the same build_facet_surface() call that have coincident points encoded in multiple CubitPointData instances (instead of a shared instance) also fails. Attached are working examples (one build 4 FacetSurfaces from 4 triangles, the other 2 FacetSurfaces from 4 triangles). It would be nice if the documentation for build_facet_surface() was updated to include some mention of this: //- Create one or more new FacetSurfaces with all of its lower //- order entities. Use an optional feature_angle to break //- surface. //- //- Where the input CubitFacet and/or CubitQuadFacet instances //- share a vertex, they should reference the same CubitPoint //- pointer. However, no CubitPoint instance shared with a //- surface created by a separate call to build_facet_surface() //- should be referenced; if multiple build_facet_surface() calls //- are made, points on shared boundaries between will be merged //- when the a shell containing the surfaces is created. //- //- The point_list should contain exactly the points in //- the input facets and no others. I still have not been able to get surface-splitting by feature_angle working, so that is probably still worth a bug report. David

1 0