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

Tue Feb 4 12:42:38 CST 2025

Hi Iulian,

I have one additional question. Reversing the connectivity array to flip a
face normal works for linear faces, but for QUAD8 (and presumably other
higher-order elements), this fails. I see that the corners of the elements
are stored first in the connectivity array, but I am having a difficult
time parsing the ordering for the other vertices in higher-order elements.
I have read Tim Tautges' paper "CANONICAL NUMBERING SYSTEMS FOR
FINITE-ELEMENT CODES" referenced in CN.hpp and want to make sure I
understand the ordering system it describes.

Am I correct in my interpretation that to flip the normal of a face with
higher-order nodes without breaking the ordering system, I must reverse the
corner nodes and the higher-order nodes separately? And if I have an
element like a QUAD9 that actually has a higher-order node interior to the
face, is that node stored after those assigned to the edges because it
resolves the face? To give a concrete example, let's say I have a QUAD9
with connectivity [1,2,3,4,5,6,7,8,9]. My understanding is that the quad
with opposite normal should have connectivity [4,3,2,1,8,7,6,5,9]. My
reasoning is that the first four nodes resolve the corners (dimension 0),
the next four resolve the edges (dimension 1), and the last resolves the
face itself (dimension 2).

Thanks again,
Steve

On Fri, Jan 31, 2025 at 4:58 PM Vijay S. Mahadevan <vijay.m at gmail.com>
wrote:

> We are glad you are able to find MOAB helpful for your problems of
> interest. Do let us know if there are other hurdles you run into.
>
> We are also happy to accept new contributions to improve the
> high-order reconstruction algorithms, if you have the time to submit a
> PR :-)
>
> Best,
> Vijay
>
> On Wed, Jan 29, 2025 at 10:36 AM Steve Hughey <hugheyst at gmail.com> wrote:
> >
> > Thanks Iulian, I think I'm on the same page with everyone now. While it
> sounds like I will need to write what I'm looking for from scratch, I
> appreciate all the time you, Vijay, and Paul have taken to answer my
> questions, and I really appreciate all your work on MOAB. I find it quite
> useful.
> >
> > I have made some progress on my problem, using a constrained DFS to find
> all feasible closed shells in an acceptable runtime. I plan to try using
> the ray casting functionality in MOAB to ensure outward normals for each
> shell so I can try out some ideas I have for winnowing the candidates down
> to the irreducible volumes I'm looking for.
> >
> > Steve
> >
> > On Tue, Jan 28, 2025 at 10:09 PM Grindeanu, Iulian R. <
> iulian at mcs.anl.gov> wrote:
> >>
> >> 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
> >> >> > >
> >>
>