- moab-dev - mailman3.cels.anl.gov

Re: [MOAB-dev] [CELS WordPress Sites] Installation of Moab on MacOS 26.1
by Mahadevan, Vijay S. 10 Dec '25

10 Dec '25

Dear Christophe, I don’t quite understand the error below. The link is perhaps garbled. Did your autoreconf command fail? Can you verify that your home-brew is up to date? Please do send the autoreconf.log file so that we can take a closer look. Also, you should not be using 5.0.0. That version is probably a decade old! Please update to 5.6.0. Best, Vijay From: Christophe Chalons <christophealexandrechalons(a)gmail.com> Date: Monday, December 8, 2025 at 09:02 To: Mahadevan, Vijay S. <mahadevan(a)anl.gov> Subject: [CELS WordPress Sites] Installation of Moab on MacOS 26.1 [You don't often get email from christophealexandrechalons(a)gmail.com. Learn why this is important at https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;… ] Hello, When I try the command 'brew install moab' I have the following issue : Christophes-MacBook-Pro:Homebrew christophechalons$ brew install moab ==> Fetching downloads for: moab ✔︎ Formula moab (5.0.0) [Verifying 11.9MB/ 11.9MB] ==> Installing moab from brewsci/science ==> autoreconf -fi Last 15 lines from /Users/christophechalons/Library/Logs/Homebrew/moab/01.autoreconf.log: 2025-12-08 13:53:52 +0000 autoreconf -fi If reporting this issue please do so at (not Homebrew/* repositories): https://urldefense.us/v3/__https://gcc02.safelinks.protection.outlook.com/?… <https://urldefense.us/v3/__https://gcc02.safelinks.protection.outlook.com/?… > I don't understand why...I tried to remove the /Users/christophechalons/Library/Logs/Homebrew/moab directory but to no avail. Thank you in advance for your help, Regards, Christophe Chalons

2 2

MOAB v5.6.0 is now available
by Vijay S. Mahadevan 15 Nov '25

15 Nov '25

Dear MOAB users, A new release of the MOAB library (v5.6.0) is now available. The tarball can be downloaded at http://web.cels.anl.gov/projects/sigma/downloads/moab/moab-5.6.0.tar.gz (SHA: 8d24a38619eb9fd326c7bdf9fdb01466149a0ab7dc3ef1caffda728858bf5a85). If you are working with release branches in Bitbucket, please use the newly created "5.6.0" tag to get the latest changes. I've shared below the notable updates, including a revamped CMake build system, new Conan package manager support, Scikit-Build support for PyMOAB installation, and considerable documentation updates, along with several new features to support Earth system solvers. - *PR #748 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: A new *edge-splitting tool **for conservative flux remaps* between unstructured grids - *PR #746 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: *Enhanced documentation* and tight Doxygen integration - *PR #741 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Improved *CMake build system* and dependency management - *PR #736 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Optimized *parallel reading and linear map* application algorithms - *PR #734 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Add *elevated edge visualization* for E3SM maps - *PR #707 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Support *uniform API for online/offline remap* computations - *PR #683 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Use *CAAS nonlinear filter* for bounds preservation - *PR #681 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: *Remove ITAPS, iMesh, and CGM *dependencies - *PR #666 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: *Compare H5M files* utility for regression testing - *PR #665 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: Add option for culling the mesh in E3SM *domain reader* (use NO_CULLING to disable) - *PR #664 <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/pull-reque… >*: *Auto-download Zoltan* for automatic configuration of partitioner In addition to the above-listed changes, this release includes bug fixes, configuration updates, easier Python usage, and several performance improvements targeted at specific problem areas. Detailed release notes are available in RELEASE_NOTES.md <https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab/src/master… >. *Deprecation Notice:* - This will be the last version of MOAB where autotools will be fully supported. Please transition your build system and workflows to use CMake when building MOAB. - The ITAPS interfaces (iMesh/iRel) have been removed, and legacy PyMOAB Python binding installations via CMake/autotools have been deprecated in this release. Please use Scikit-Build for PyMOAB installations. Special thanks to all contributors who made this release possible: - Ahnaf Tahmid Chowdhury - Iulian Grindeanu - Vijay Mahadevan - Baptiste Mouginot - Patrick Shriwise - Tim Tautges - Paul Wilson - And all users who have emailed the list, submitted issues, and pull requests to make the MOAB library better As always, please let us know if you encounter issues with the new release. Best, Vijay

1 0

errors during make check
by Charles Henkel 08 Nov '25

08 Nov '25

Context Ubuntu 24.04 LTS virtual machine hosted in Hyper-V on Windows Server 2016 Working on the head of the repo obtained by git clone https://urldefense.us/v3/__https://bitbucket.org/fathomteam/moab__;!!G_uCfs… (short hash 19bb18718) Problem Failure during "make check" on vtk_test Contents of test/io/test-suite.log: ======================================== MOAB 5.5.1: test/io/test-suite.log ======================================== # TOTAL: 11 # PASS: 10 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: vtk_test ============== *** buffer overflow detected ***: terminated FAIL vtk_test (exit status: 139) Potential Cause During "make all", these errors occurred several times: In file included from /usr/include/stdio.h:980, from /usr/include/c++/13/cstdio:42, from /usr/include/c++/13/ext/string_conversions.h:45, from /usr/include/c++/13/bits/basic_string.h:4109, from /usr/include/c++/13/string:54, from ../../../src/src/moab/Range.hpp:166, from ../../../src/src/moab/Interface.hpp:47, from ../../../src/src/moab/Core.hpp:19, from ../../../src/test/io/VtkTest.cpp:1: In function 'int snprintf(char*, size_t, const char*, ...)', inlined from 'bool test_read_write_element(const double*, unsigned int, const int*, const int*, unsigned int, unsigned int, unsigned int, moab::EntityType)' at ../../../src/test/io/VtkTest.cpp:959:20: /usr/include/x86_64-linux-gnu/bits/stdio2.h:54:35: warning: 'int __builtin___snprintf_chk(char*, long unsigned int, int, long unsigned int, const char*, ...)' specified bound 4096 exceeds destination size 4019 [-Wstringop-overflow=] 54 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55 | __glibc_objsize (__s), __fmt, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 56 | __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~ ________________________________ Charles S. Henkel Henkel Technical Computing, LLC 5816 N Saint Louis Ave Loveland, CO 80538 Office (970)776-9735 Mobile (970)732-2159

1 1

Issue with DataCoupler
by Andrei Shvarts 12 Mar '25

12 Mar '25

Hello, I am one of the core developers of MoFEM, for which MOAB is a backbone. Recently, we have been looking for functionality to transfer data between meshes, and it appears that MOAB provides two options: Coupler and DataCoupler classes, the latter described as a more advanced version of the former. As a starting point, we would need a constant projection from tags on elements in the source mesh to tags on elements in the target mesh. Coupler seems to handle this; however, we need to use 9-value tags (for stress tensors), while Coupler appears to support only scalar tags. We could store each stress component as a separate scalar tag and interpolate them individually, but this seems rather tedious, especially since the DataCoupler class appears to support multi-value tags. However, I have been unable to transfer data from element tag to element tag using DataCoupler; the result is always zero. Even the datacoupler_test with the default meshes does not seem to work, as the resulting element tag values are all zero. I ran the test with the following command: ./datacoupler_test -itag element_field -meth 0 -outfile out.h5m I have compiled develop branch, commit f4c7a65af7cc9d520577877eeef39fd9e2493fde Could you advise me please if I am using DataCoupler correctly? Many thanks, Kind regards, Andrei –––––––––––––– Dr Andrei Shvarts Lecturer – Infrastructure & Environment Glasgow Computational Engineering Centre James Watt School of Engineering University of Glasgow

1 0

Re: [MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh
by Steve Hughey 04 Feb '25

04 Feb '25

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(a)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(a)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(a)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(a)gmail.com> > >> Sent: Tuesday, January 28, 2025 5:14 PM > >> To: Steve Hughey; Grindeanu, Iulian R. > >> Cc: Paul Wilson; moab-dev(a)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(a)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(a)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.ht… > >> >> > >> >> On Wed, Jan 22, 2025 at 1:16 PM Steve Hughey <hugheyst(a)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(a)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/10m8e6GN8… > >, > >> >> > > 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(a)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_uCf… > >> >>> > 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!c1oZ… > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > *From: *moab-dev <moab-dev-bounces(a)mcs.anl.gov> on behalf of > Steve Hughey > >> >> > > <hugheyst(a)gmail.com> > >> >> > > *Date: *Wednesday, January 22, 2025 at 05:12 > >> >> > > *To: *moab-dev(a)mcs.anl.gov <moab-dev(a)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 > >> >> > > > >> >

2 1

Re: [MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh
by Grindeanu, Iulian R. 29 Jan '25

29 Jan '25

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(a)gmail.com> Sent: Tuesday, January 28, 2025 5:14 PM To: Steve Hughey; Grindeanu, Iulian R. Cc: Paul Wilson; moab-dev(a)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(a)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(a)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.ht… >> >> On Wed, Jan 22, 2025 at 1:16 PM Steve Hughey <hugheyst(a)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(a)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/10m8e6GN8…>, >> > > 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(a)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_uCf… >>> > 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!c1oZ…> >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > *From: *moab-dev <moab-dev-bounces(a)mcs.anl.gov> on behalf of Steve Hughey >> > > <hugheyst(a)gmail.com> >> > > *Date: *Wednesday, January 22, 2025 at 05:12 >> > > *To: *moab-dev(a)mcs.anl.gov <moab-dev(a)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 >> > >

2 1

Re: [MOAB-dev] MOAB finding shells bounding closed regions in nonmanifold mesh
by Steve Hughey 26 Jan '25

26 Jan '25

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(a)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.ht… > > On Wed, Jan 22, 2025 at 1:16 PM Steve Hughey <hugheyst(a)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(a)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/10m8e6GN8… > >, > > > 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(a)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_uCf… > > > 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!c1oZ… > > > > > > > > > > > > > > > > > > > > > > > > > > *From: *moab-dev <moab-dev-bounces(a)mcs.anl.gov> on behalf of Steve > Hughey > > > <hugheyst(a)gmail.com> > > > *Date: *Wednesday, January 22, 2025 at 05:12 > > > *To: *moab-dev(a)mcs.anl.gov <moab-dev(a)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 > > > >

1 0

MOAB finding shells bounding closed regions in nonmanifold mesh
by Steve Hughey 22 Jan '25

22 Jan '25

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

2 2

Permissions for moab PR
by Tim Tautges 27 Dec '24

27 Dec '24

Hi gang, I'd like to submit a moab PR that adds conan support; conan is a utility for managing 3rd party libraries, and makes it easy to e.g. download/build things like eigen, hdf5, etc. I have a working build under conan supporting hdf5 and mpi, and think it's worth submitting a PR for. However, when I go to the Pull Requests page, the "Create pull request" button is greyed out, saying I don't have permission to submit a PR. My account is under the name "Tim Tautges" at this email address. - tim

1 0

Re: [MOAB-dev] gaher entities at root process
by Lukasz Kaczmarczyk 22 Nov '24

22 Nov '24

Hi Thanks for this. Kind regards, Lukasz From: Vijay S. Mahadevan <vijay.m(a)gmail.com> Date: Friday, 22 November 2024 at 18:20 To: Lukasz Kaczmarczyk <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> Cc: moab-dev(a)mcs.anl.gov <moab-dev(a)mcs.anl.gov> Subject: Re: gaher entities at root process Dear Lukasz, Sorry about the delay in responding. I've been swamped with various deadlines, but I have something that you can use. Please look at the branch: vijaysm/example-gather-mesh and under examples/advanced/GatherMeshOnRoot.cpp, it demonstrates how one can use ParallelComm to accumulate entities from different processes on the root. It's what I want to call the equivalent of a MPI_Gather operation: Mesh_Gather. You can add options to move the tags as well; this should be trivial within this infrastructure. Let me know what you think. It is not extensively documented but hopefully, the usage and ideas are straightforward. The one thing that I dislike in this workflow is that you need to perform a local "merge" of entities - especially the shared edge/vertices. I don't exactly see how one can avoid this at the moment. I will submit a PR for that branch and we will get that merged as well. Best, Vijay On Fri, Nov 15, 2024 at 6:35 AM Lukasz Kaczmarczyk <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: > > Hi Vijay, > > Thank you for your response. > > I needed to accumulate a subset of the mesh on the root task, on top of its local portion of the mesh. I have the same internal surface distributed across a subset of processors and need to accumulate the root volumes adjacent to it. This is > required only temporarily for some topological queries. > > > > I created a minimal working example that is not functioning as expected. I must be making a silly mistake somewhere, but I cannot figure out why it is not working. See the attached file and mesh. The mesh is partitioned for two processes. > > > mpirun -np 2 ./mwe_send_entities > > > Regards, > Lukasz > > > > > From: Vijay S. Mahadevan <vijay.m(a)gmail.com> > Date: Thursday, 14 November 2024 at 15:38 > To: Lukasz Kaczmarczyk <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> > Cc: moab-dev <moab-dev-bounces(a)mcs.anl.gov> > Subject: Re: gaher entities at root process > > Hi Lukasz, > > Let me understand the context correctly here. Do you want to > accumulate some subset of the mesh on the root task, on top of its > local piece of the mesh? Or is the motivation to collect the entities > on the root to perform some other task on them that only the root > process is capable of achieving? > > > An easier approach, but a bit wasteful, is probably to keep the entire mesh on the zero processors while the rest remains distributed and data from the parts is gathered. That I can make working., > > I would not recommend this, especially since the approach will not > scale well with mesh resolution. > > Your usage of send_entities/recv_messages looks correct according to > the API, but why are you not using recv_entities to be consistent > here? Having a MWE will help debug and provide a better solution for > this particular workflow for meshes of interest. > > In our climate simulations, we handle migration of entire meshes from > one set of processes to another set with adaptive repartitioning. > These involve communication of entities between processes and I'll see > if we can create an example out of that to just send parts of a mesh > to the root. > > Best, > Vijay > > On Wed, Nov 13, 2024 at 7:31 PM Lukasz Kaczmarczyk > <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: > > > > Hi Vijay, > > > > > > I am looking for advice on how to gather some entities on the zero processor. Is there a good way to do this? I couldn't find a working example for send_entities and recv_messages from pcomm. > > > > An easier approach, but a bit wasteful, is probably to keep the entire mesh on the zero processors while the rest remains distributed and data from the parts is gathered. That I can make working., > > > > However, I am not sure what the best policy is. > > > > What is my mistake: > > > > int to_proc = 0; > > > > Range orig_ents = ents; > > > > bool adjs = false; > > > > bool tags = false; > > > > bool store_remote_handles = false; > > > > bool is_iface = false; > > > > Range final_ents; > > > > int incoming1 = 0; > > > > int incoming2 = 0; > > > > TupleList entprocs; > > > > std::vector<MPI_Request> recv_remoteh_reqs; > > > > bool wait_all = true; > > > > > > > > int from_proc = 1; > > > > std::vector<std::vector<EntityHandle>> L1hloc; > > > > std::vector<std::vector<EntityHandle>> L1hrem; > > > > std::vector<std::vector<int>> L1p; > > > > std::vector<EntityHandle> L2hloc; > > > > std::vector<EntityHandle> L2hrem; > > > > std::vector<unsigned int> L2p; > > > > > > > > pcomm->recv_messages( > > > > from_proc, store_remote_handles, is_iface, final_ents, incoming1, > > > > incoming2, L1hloc, L1hrem, L1p, L2hloc, L2hrem, L2p, recv_remoteh_reqs); > > > > > > > > pcomm->send_entities(to_proc, orig_ents, adjs, tags, > > > > store_remote_handles, is_iface, final_ents, > > > > incoming1, incoming2, entprocs, > > > > recv_remoteh_reqs, wait_all); > > > > > > > > > > Kind Regards, > > Lukasz > > > >

1 0