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

Tue Feb 4 23:16:20 CST 2025

Hi Steve,
The convention for higher order nodes is given by the rules in const CN::ConnMap CN::mConnectivityMap[MBMAXTYPE][3] = {

in src/MBCNArrays.hpp

For quad-edge connectivity map, the order for higher order nodes follows the order of edges 
 // quad-edge
    { { 2,
        4,
        { 2, 2, 2, 2 },
        { MBEDGE, MBEDGE, MBEDGE, MBEDGE, MBMAXTYPE, MBMAXTYPE, MBMAXTYPE, MBMAXTYPE, MBMAXTYPE, MBMAXTYPE, MBMAXTYPE,
          MBMAXTYPE },
        { { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 0 } } },

so if 12345678 is your quad8, node 5 is between 1 and 2, 6 is between 2 and 3,  ...  8 is between 4 and 1

node 9 is in center

If you need to revert it, it should be

4321 7 6 5 8  

Every finite element code might have different conventions for higher order nodes, but MOAB  readers/writers should make the conversion correctly 

I hope this helps
Iulian

________________________________________
From: Steve Hughey <hugheyst at gmail.com>
Sent: Tuesday, February 4, 2025 12:42 PM
To: Grindeanu, Iulian R.
Cc: moab-dev at mcs.anl.gov
Subject: Re: [MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh

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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:moab-dev-bounces at mcs.anl.gov>> on behalf of Steve Hughey
>> >> > > <hugheyst at gmail.com<mailto:hugheyst at gmail.com>>
>> >> > > *Date: *Wednesday, January 22, 2025 at 05:12
>> >> > > *To: *moab-dev at mcs.anl.gov<mailto:moab-dev at mcs.anl.gov> <moab-dev at mcs.anl.gov<mailto: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
>> >> > >
>>