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

Re: [cgma-dev] RefGroup question
by David Thompson 27 Jan '14

27 Jan '14

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 >

1 0

Re: [cgma-dev] RefGroup question
by Paul Wilson 25 Jan '14

25 Jan '14

Hi David, 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 <https://bitbucket.org/fathomteam/moab/src/1e89e1024c147fd9a617a4a34a698b44c…>, 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. This is all in CubitAttribManager.hpp <http://trac.mcs.anl.gov/projects/ITAPS/browser/cgm/trunk/geom/CubitAttribMa…> which also contains methods for auto_write_flag() that you might need to establish before you write your file to ensure that they are written in your file. I hope this helps, Paul 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

1 0

Re: [cgma-dev] RefGroup question
by David Thompson 24 Jan '14

24 Jan '14

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

1 0

Migrating repo to git
by Tim Tautges (ANL) 23 Jan '14

23 Jan '14

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

1 0

Re: [cgma-dev] RefGroup question
by Tim Tautges (ANL) 23 Jan '14

23 Jan '14

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. - tim On 01/23/2014 04:48 PM, David Thompson wrote: > Hi all, > > I've been unable to determine from the documentation whether RefGroup instances can be exported along with a solid model by any or all of the backends. It doesn't appear that they can be; my experiments passing groups to CubitCompat_export_solid() have been unsuccessful with "OCC" and "FACET_TYPE" file_type arguments. > > Thanks, > David > -- ================================================================ "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

RefGroup question
by David Thompson 23 Jan '14

23 Jan '14

Hi all, I've been unable to determine from the documentation whether RefGroup instances can be exported along with a solid model by any or all of the backends. It doesn't appear that they can be; my experiments passing groups to CubitCompat_export_solid() have been unsuccessful with "OCC" and "FACET_TYPE" file_type arguments. Thanks, David

1 0

Throwing Exception
by Alexander Vizard 23 Jan '14

23 Jan '14

Hello, I have installed the MeshKit software, and am in the process of studying the EBMesh example. Here, I am running the default geometry, under default conditions, and am obtaining the following error: libc++abi.dylib: terminate called throwing an exception Abort trap: 6 The code has not been altered, besides the fact that the directories in the makefile were set to those that apply to my particular machine, as instructed. my execution line is as follows: ./example_ebmesh /Users/avizard/moab/MeshKit/data/sphere.stp 1 10 10 10 0 output.vtk .03 I am using Mac OS X (version 10.8.4). Thanks in advance for your assistance, and I look forward to hearing back from you soon. -- Alexander Vizard Research Assistant George Washington University avizard(a)gwmail.gwu.edu

1 0

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

22 Jan '14

Yes, I've just done this in revision 6116. Thanks for the reminder! Jane On Wed, Jan 22, 2014 at 8:26 AM, David Thompson <david.thompson(a)kitware.com>wrote: > 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> > > -- 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

r6116 - cgm/trunk/geom/facet
by janehu＠mcs.anl.gov 22 Jan '14

22 Jan '14

Author: janehu Date: 2014-01-22 10:43:54 -0600 (Wed, 22 Jan 2014) New Revision: 6116 Modified: cgm/trunk/geom/facet/FacetModifyEngine.hpp Log: updated build_facet_surface() message to include a general instruction of usage. Modified: cgm/trunk/geom/facet/FacetModifyEngine.hpp =================================================================== --- cgm/trunk/geom/facet/FacetModifyEngine.hpp 2014-01-21 19:56:22 UTC (rev 6115) +++ cgm/trunk/geom/facet/FacetModifyEngine.hpp 2014-01-22 16:43:54 UTC (rev 6116) @@ -966,6 +966,14 @@ //- order entities. Use an optional feature_angle to break //- surface + //- Define separate CubitPoint* for the CubitFacet list and CubitQuadFacet + //- list if they are going to create different surfaces. + //- Facets sharing the same CubitPoint* will be created into one surfaces. + //- Separate call of build_facet_surface will try to build different + //- surfaces, and won't be able to use shared CubitPoint* from other + //- build_facet_surface call. + //- As long as facets are defined, the CubitPoint list should be left empty + CubitStatus smooth_facets( RefFace *ref_face_ptr, int niter, CubitBoolean free_laplacian ); //- attempt to clean up facets by smoothing the points on the surface CubitStatus create_shell_offset( BodySM *bodysm_ptr, BodySM *&new_bodysm, double offset );

1 0

Re: [cgma-dev] CMake build system
by David Thompson 22 Jan '14

22 Jan '14

Hi Tim and Jane, > 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... As long as there is a path to get fixes moved into these files, that would be great; currently they do not include complete install rules (I've pushed a branch to a clone[1] of CGM at github to fix most of this), they do not build a single cgm library (things are broken into convenience libraries for each engine, for instance), there is no cgm.make created so that projects can build against a CMake-built version of CGM, and the tests are not built. I'll continue to update the cmake branch at the link below until it's ready for a merge, but it would be nice to hear how the changes might be fed upstream into cubit (or if some of the changes are at cross purposes to cubit). Thanks, David [1]: https://github.com/vibraphone/cgma/tree/cmake > > 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