[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