[MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh

Grindeanu, Iulian R. iulian at mcs.anl.gov
Tue Jan 28 21:09:16 CST 2025


Hello Steve,

this GTT functionality is mostly used to describe a volumetric mesh model in terms of geometry.

It is used also by our cubit reader, it tries to preserve in the mesh, using mesh sets, special geometry tags, and parent/children relationships between sets, the "geometric" / topology model

For example, a geometric surface bounded by 4 curves, that form a loop, after meshing with surface mesh elements, will have a natural geometry description in MOAB with:
one surface set of geometry dimension 2
4 edge sets corresponding to  those 4 boundary curves, in which the edges are ordered
4 vertex sets coresponding to 4 geometry vertices, each containing one node
the surface set is parent to 4 edge sets, and  each edge set is parent to 2 vertex sets

We cannot build in MOAB a geometry, starting from an existing mesh, the way CGM could.
We do have in FBEngine some useful tools, but it assumes pretty much that the topology is already built (I mean, those geometry sets). A smooth curve/surface framework exists too.



Also, we do not have in MOAB a tool to correct the orientation of the surface mesh, to have a consistent normal. You would have to write it yourself, unfortunately.

 I would say it is pretty easy.
I mean, if your surface mesh is correct and connected, you can just start from one element that is correctly oriented, and advance by edge adjacency, until you exhaust the mesh. Changing the orientation means reversing the connectivity array.  (of course, I assume that your mesh is a 2d manifold, if you have edges that are common to 3 elements you cannot orient it. Basically,  all your edges that are adjacent to 2 cells are internal, and all edges adjacent to one cell are boundary edges ).

I hope this helps
Iulian


________________________________________
From: Vijay S. Mahadevan <vijay.m at gmail.com>
Sent: Tuesday, January 28, 2025 5:14 PM
To: Steve Hughey; Grindeanu, Iulian R.
Cc: Paul Wilson; moab-dev at mcs.anl.gov
Subject: Re: [MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh

Hi Steve, > Thank you for your detailed response. I looked into the discrete geometry module and, while it is interesting, I unfortunately do not think it will satisfy my needs. My meshes have sharp features and already largely use quadratic
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Steve,

> Thank you for your detailed response. I looked into the discrete geometry module and, while it is interesting, I unfortunately do not think it will satisfy my needs. My meshes have sharp features and already largely use quadratic elements for the smooth portions. I will keep it in mind for future potential uses though!

Understood. Yes, this is one of the downsides to the scheme and while
we added in some feature detection capabilities, I don't think they
are robust enough for many real world problems. If you do end up
playing with it, would like to hear your thoughts.

> I think the next step requires defining or verifying the orientation of my surfaces in the usual way (right-hand rule with surface always to the left of its boundary) to help constrain a DFS of my surface-curve adjacency map. I'd like to update the connectivity of each face to get a consistent normal over each surface and to store a single sense for the entire surface rather than one for each face. Is there an idiomatic way to deal with this in MOAB?

I think @Grindeanu, Iulian R. worked on GTT and may have ideas to help you here.

> Also, given that I am trying to reconstruct geometry from the mesh, is there an advantage to using MOAB's geometry set functionality? Because that feature seems fairly closely associated with the now-defunct CGM project, I have written my own containers to store relationships between the geometric entities.

You are correct in this assumption that the GEOM* sets were originally
added to help deal with a mesh representation of a solid geometry, and
this requires CGM. Our original thought was to create a direct
interface to OCC or EGADS to make this happen directly from MOAB but
none of us have had the time to get to this yet.

Vijay

On Sun, Jan 26, 2025 at 7:02 PM Steve Hughey <hugheyst at gmail.com> wrote:
>
> Hi Vijay,
>
> Thank you for your detailed response. I looked into the discrete geometry module and, while it is interesting, I unfortunately do not think it will satisfy my needs. My meshes have sharp features and already largely use quadratic elements for the smooth portions. I will keep it in mind for future potential uses though!
>
> I have thought some more about my problem and think I am closing in on a solution that I hope MOAB can help with. I think the next step requires defining or verifying the orientation of my surfaces in the usual way (right-hand rule with surface always to the left of its boundary) to help constrain a DFS of my surface-curve adjacency map. I'd like to update the connectivity of each face to get a consistent normal over each surface and to store a single sense for the entire surface rather than one for each face. Is there an idiomatic way to deal with this in MOAB? Some of the logic in GeomTopoTool::geometrize_surface_sets() looks relevant; perhaps I just need to mimic that.
>
> Also, given that I am trying to reconstruct geometry from the mesh, is there an advantage to using MOAB's geometry set functionality? Because that feature seems fairly closely associated with the now-defunct CGM project, I have written my own containers to store relationships between the geometric entities. I am always happier, of course, to take advantage of someone else having already thought through my problem and written code.
>
> Thanks,
> Steve
>
> On Wed, Jan 22, 2025 at 2:14 PM Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>
>> Dear Steve,
>>
>> > > However, I am now faced with the problem of finding closed regions. I have
>> > > some ideas on how to do this based on concepts from half-facet data
>> > > structures, but the MOAB classes FBEngine and GeomTopoTool caught my
>> > > attention. I have tried reading the interface specification for these and
>> > > have been unable to determine whether they could be useful for my closed
>> > > regions problem. I have seen many allusions in the code to geometry and
>> > > topology representation, but I haven’t been able to connect the dots. My
>> > > hope is that someone has already thought through this problem and
>> > > implemented a solution. I would appreciate any insight you can provide, and
>> > > in the meantime I will continue testing things.
>>
>> You are correct in the assumption that some effort in MOAB exists
>> along the lines of what you need. For example, FBiGeom is a
>> Facet-based geometry interface that could be used to reconstruct a
>> higher-order geometry representation from a bounded tesselation that
>> can queried directly to compute normals and enclosed/connected
>> regions. However, since we deprecated and removed support for ITAPS,
>> none of this code is reusable.
>>
>> We also have an implementation of a WALF-based higher-order surface
>> reconstruction method [1] that can generate feature-aware discrete
>> geometry. This scheme can also be useful for constructing an enclosing
>> boundary for a given mesh. However, I don't know how useful this might
>> be for your case as there may be restrictions wrt
>> regularity/smoothness of the boundary mesh that is being used to
>> reconstruct the high-order surface.
>>
>> > I am hoping to take advantage of any extant machinery in MOAB for
>> > addressing these problems. I have looked briefly at the CGM library, but
>> > since it's no longer under development, I hesitate to adopt it.
>>
>> CGM would be appropriate if you had solid geometry that matched your
>> mesh. However, due to funding and other constraints, we recently
>> deprecated CGM and would not recommend it for what you need. We do not
>> have the manpower to provide support or maintenance.
>>
>> My current suggestion would be to look at the DiscreteGeometry module
>> [2] and reconstruction scheme [1] to see if they are useful. If not,
>> we may have to custom write a boundary reconstruction scheme that
>> satisfies your needs.
>>
>> Best,
>> Vijay
>>
>> [1] https://web.cels.anl.gov/projects/sigma/docs/moab/HiReconstruction_8hpp.html
>> [2] https://web.cels.anl.gov/projects/sigma/docs/moab/classmoab_1_1DGMSolver.html
>>
>> On Wed, Jan 22, 2025 at 1:16 PM Steve Hughey <hugheyst at gmail.com> wrote:
>> >
>> > Hi Paul,
>> >
>> > Thank you for your response and suggestions!
>> >
>> > In the terminology of the slides you sent, I am looking for a way to
>> > construct from a raw mesh file the geometric Volumes, Surfaces, Curves, and
>> > Nodes that make up the meshed geometry, similar to how CUBIT creates
>> > mesh-based geometry from importing a mesh file. I've written a program that
>> > uses the Skinner heavily to break the mesh down into connected meshed
>> > Volumes, Surfaces, Curves, and Nodes; it also finds all of the
>> > upward/downward adjacencies between these. If something equivalent to this
>> > exists in MOAB, I am very interested to hear about it.
>> >
>> > Regardless, the next step I need to take is to find the empty Volumes
>> > bounded by any subset of Surfaces in my geometry. These are important in
>> > boundary-element codes because materially homogeneous regions of space are
>> > represented by their boundaries only. Boundary-element meshes can contain
>> > many of these unmeshed volumes and non-manifold curves where different
>> > materials abut each other.
>> >
>> > I am hoping to take advantage of any extant machinery in MOAB for
>> > addressing these problems. I have looked briefly at the CGM library, but
>> > since it's no longer under development, I hesitate to adopt it.
>> >
>> > Thank you,
>> >
>> > Steve
>> >
>> > On Wed, Jan 22, 2025 at 11:24 AM Paul Wilson <paul.wilson at wisc.edu> wrote:
>> >
>> > > Hi Steve,
>> > >
>> > >
>> > >
>> > > The GeomTopoTool assumes that a mesh-based geometry follows the data model
>> > > conventions described in slides 1-6 of this summary
>> > > <https://urldefense.us/v3/__https://docs.google.com/presentation/d/10m8e6GN8DhLpNHHSOMniZ2pDU9DOAiD0xJF1Zyewzh8/edit*slide=id.g3b5f37914c_0_117__;Iw!!G_uCfscf7eWS!c1oZJ1JijGmIvdML0MotOwV3GWtr5fqBfxhmWMcy7yqyb53gbIG2AVFmXedMUDxrYu9Dm4Lak8QfebIWOqA9$>,
>> > > and assumes that the relationships defined there are embedded when the
>> > > mesh-based geometry is created.
>> > >
>> > >
>> > >
>> > > I’m not sure I fully understand your question/use case, but you may also
>> > > be interested in the MOAB skinner
>> > > <https://ftp.mcs.anl.gov/pub/fathom/moab-docs/classmoab_1_1Skinner.html>
>> > > that is designed to identify boundary elements.
>> > >
>> > >
>> > >
>> > > I hope this is somewhat helpful,
>> > >
>> > > Paul
>> > >
>> > >
>> > >
>> > > --
>> > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
>> > > Paul P.H. Wilson (he/him/his)
>> > > Grainger Professor of Nuclear Engineering
>> > > Chair, Department of Nuclear Engineering & Engineering Physics
>> > > o: 608-263-0807, c: 608-469-9615
>> > > paul.wilson at wisc.edu
>> > > 153 Engineering Research Bldg
>> > > 1500 Engineering Dr, Madison, WI 53706
>> > > Zoom Meeting Room: https://urldefense.us/v3/__https://uwmadison.zoom.us/j/6082630807__;!!G_uCfscf7eWS!c1oZJ1JijGmIvdML0MotOwV3GWtr5fqBfxhmWMcy7yqyb53gbIG2AVFmXedMUDxrYu9Dm4Lak8QfefhqeGPH$
>>> > Zoom Phone Access: +1-929-205-6099, Access code: 6082630807
>> > >
>> > > Computational Nuclear Engineering Research Group
>> > > <https://urldefense.us/v3/__http://cnerg.engr.wisc.edu__;!!G_uCfscf7eWS!c1oZJ1JijGmIvdML0MotOwV3GWtr5fqBfxhmWMcy7yqyb53gbIG2AVFmXedMUDxrYu9Dm4Lak8QfeRLDrXMw$>
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > *From: *moab-dev <moab-dev-bounces at mcs.anl.gov> on behalf of Steve Hughey
>> > > <hugheyst at gmail.com>
>> > > *Date: *Wednesday, January 22, 2025 at 05:12
>> > > *To: *moab-dev at mcs.anl.gov <moab-dev at mcs.anl.gov>
>> > > *Subject: *[MOAB-dev] MOAB finding shells bounding closed regions in
>> > > nonmanifold mesh
>> > >
>> > > Hello,
>> > >
>> > > I am using MOAB as the basis for a sort of mesh-based geometry model in a
>> > > finite element/boundary element code. I must assume that the mesh
>> > > connectivity and Exodus block specifications are the only information I
>> > > have about the geometry. I have been able to use MOAB’s various adjacency
>> > > queries to break the input mesh into connected components with adjacencies
>> > > between them, largely along the lines of CUBIT’s mesh-based geometry
>> > > engine. The meshes are pretty general, containing quads, tris, hexes, tets,
>> > > prisms, and pyramids, and typically contain nonmanifold edges.
>> > >
>> > > However, I am now faced with the problem of finding closed regions. I have
>> > > some ideas on how to do this based on concepts from half-facet data
>> > > structures, but the MOAB classes FBEngine and GeomTopoTool caught my
>> > > attention. I have tried reading the interface specification for these and
>> > > have been unable to determine whether they could be useful for my closed
>> > > regions problem. I have seen many allusions in the code to geometry and
>> > > topology representation, but I haven’t been able to connect the dots. My
>> > > hope is that someone has already thought through this problem and
>> > > implemented a solution. I would appreciate any insight you can provide, and
>> > > in the meantime I will continue testing things.
>> > >
>> > > Thanks,
>> > > Steve
>> > >



More information about the moab-dev mailing list