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

Wed Jan 29 10:36:30 CST 2025

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
> >> > >
>
>