[cgma-dev] Seg fault when loading OCC geometry with associations

Tim Tautges tautges at mcs.anl.gov
Sat Mar 28 18:06:28 CDT 2009



Jed Brown wrote:
> On Sat 2009-03-28 15:02, Tim Tautges wrote:
>>
>> Jed Brown wrote:
>>> My brick generator creates some boundary conditions using the Cubit
>>> conventions, and creates a geometric model using CGM (built with OCC)
>>> via iGeom_createBrick.  If I associate the boundary sets with the brick
>>> (wrong, but bear with me) using iRel (geometry first, I get seg-faults
>>> if I try mesh first) and save the mesh (in .h5m) and geometry (to a
>>> .brep, with TYPE=OCC) then I can load them with another program.  When I
>>> try to get the geometric entity related to a boundary set, I get a point
>>> instead of the volume that I should get.
>>>
>> Hmm.  Right now, Lasso (my iRel implementation) matches mesh to geometry  
>> by matching mesh set global id (GLOBAL_ID tag) and geometric dimension  
>> (GEOM_DIMENSION tag) to geom entity global id and type/dimension.  Do  
>> the tags on the mesh sets and geom entities match like that?
> 
> Since I'm creating the geometry and mesh at the same time, and setting
> relations using Lasso, shouldn't this be taken care of?  Both the mesh
> and geometry files have tags ASSOCIATION0, but neither GLOBAL_ID or
> GEOM_DIMENSION have been applied to my boundary sets.  I'm not sure how
> to read the .brep output but there is no mention of GLOBAL_ID or
> GEOM_DIMENSION.
> 

Yeah, iRel currently does *not* look for associations it saved to the 
mesh/geometry, rather I count on having to call inferAssociations again 
at the start of a run.  I'm surprised I've never thought of doing that, 
but that just shows I've been using Cubit to generate the mesh up to now 
(that's changing more quickly now).

> Looking at brick_curvy.cub, there is no ASSOCIATION0 tag, but the
> boundary sets are tagged with GEOM_DIMENSION=2 and GLOBAL_ID.  The
> geometry is in ACIS so I can't load the geometry or view what tags are
> present (I don't know how to read a .cub except what MOAB gets from it).
> BTW, thanks to whoever made iGeom_load fail for incompatible geometry
> engines instead of silently succeeding without loading any geometry.  If
> I need to set up these tags manually, do I just make
> 
>   MeshSet:GLOBAL_ID      = GeomEnt:GLOBAL_ID
>   MeshSet:GEOM_DIMENSION = GeomEnt:GEOM_DIMENSION
> 
> (which of course implies that GLOBAL_ID cannot be sequential on both the
> mesh and the geometry) or am I misunderstanding you?
> 

Yep, that's how it needs to be done for now.  And yes, this does assume 
that id spaces for entities of different dimension are independent.

>> I know that's pretty specific, eventually we may have something more  
>> general, but not soon.
> 
> I just want to be able to create mesh and geometry, set relationships
> using iRel, save the result, and recover the relations.  I don't imagine
> the current solution should have trouble with this.
> 
> 
> As a separate issue, is there a quick way to get a mesh of a geometric
> entity for visualization (can be low quality, ideally triangular strips
> for surfaces)?  I assume not yet, but it if we could then it's not a lot
> of work to get it into VisIt next to the mesh.
> 

As a matter of fact, the latest version of MOAB has a ReadCGM class, 
which can read geometry files into a facet-based representation.  We 
haven't tried it yet, but it should work directly with the ITAPS reader 
for Visit.

Also, I heard from the Visit guys that they'll be moving to an open svn 
repo in about a month, so you'll be able to anonymous checkout.  They're 
just getting started on redoing the set structure within Visit, which 
will make it possible eventually to browse the geometric topology sets 
as a graph.

- tim
> 
> Jed

-- 
================================================================
"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 at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706



More information about the cgma-dev mailing list