XDGMesh Object

[pshriwise]

Description

This introduces an initial integration of the XDG libarary for support of CAD-based mesh geometry in OpenMC. This code change provides tally support for volumetric mesh.

Capabilities

Previously, a tracklength estimator was not available for libMesh meshes due to the lack of support for surface-to-surface raytracing natively. XDG adds this support for libMesh meshes to enable raytracing for meshes that partially overlap the domain or have gaps.

Tetrahedral Mesh	MOAB	LibMesh	XDG (libMesh or MOAB)
Tracklength Estimator	✔	✖	✔
Collision Estimator	✔	✔	✔

Hexahedral Mesh (coming soon)	MOAB	LibMesh	XDG (libMesh or MOAB)
Tracklength Estimator	✖	✖	✔
Collision Estimator	✖	✔	✔

Algorithmic Changes

Previously, the MOAB tracklength estimator employed an algorithm that first determined all of the segments lying within elements for a given track and then performed a point location call at the midpoint of each segment. This algorithm is robust but computationally inefficient.

In XDG, a more standard element adjacency walk has been implemented requiring only one point location call per track. In the case that a track exits the mesh as elements are traversed, surface-to-surface ray tracing is employed to determine the track's re-entry location, if any.

This algorithmic change brings us up to date with standard ways of approaching this problem -- to great effect!

Results

Simple problems

The tally capabilities of this library have been tested on several simple problems (benchmark problems as well, but we'll save those for a later date). Below is a set of results using XDG for a superimposed mesh tally (CSG geometry) in OpenMC. A significant improvement is seen. The improved threaded scalability comes from the transition to a modern raytracing kernel (Embree) and, in the case of MOAB, bypassing most of the standard interface calls for element connectivity, coordinates, and adjacency. Serial improvements are the outcome of algorithmic changes to the tally routine (walking elements instead of many point location calls). The combination of these result in massive speedups in a problem like this where most of the cost is in the tally kernel computing element crossings (up to 300x). A per-element result comparison of the XDG tally to the MOAB tally using a tracklength estimator is shown below. The distribution of the differences is a little unusual, possibly indicating something systematic, but the absolute scale of the differences is quite small.

Production problem: WISTEL-D

@connormoreno was kind enough to provide us with a WISTEL-D model to test this out on.

This model uses meshes in a number of ways:

• The geometry is a DAGMC surface mesh (here we're using double-down as well for the raytracer)
• A mesh source is used to sample neutron locations within the plasma volume. This is supported by XDG's find_element point locatoin capability.
• An unstructured mesh heating tally is included for heating in the first wall.

It's noted in the figure, but the maximum difference between the tally results of a MOAB tracklength estimator (current capability) and the XDG mesh (also using MOAB but with the improvements noted above) is extremely small and the performance improvement is significant. This simulation ran 300M particles in total.

Testing

The existing unstructured mesh tests for the direct MOAB/libMesh implementations have been adapted for use in XDG with the same measures of tally equivalence using tetrahedral mesh containing groups of elements that conform to the boundaries of a regular mesh.

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[nuclearkevin]

Just stopping by to say this is awesome! Looking forward to integrating this into Cardinal and testing it out on some tally AMR problems

[shimwell]

I had a question about the Python API design. Currently users create unstructured meshes like this:

umesh = openmc.UnstructuredMesh("mesh.vtk", library="moab")
umesh = openmc.UnstructuredMesh("mesh.exo", library="libmesh")                                              

Since XDGMesh inherits from UnstructuredMesh on the C++ side, would it make sense to follow the same pattern rather than introducing a separate class? For example:

umesh = openmc.UnstructuredMesh("mesh.e", library="xdg-moab")
umesh = openmc.UnstructuredMesh("mesh.e", library="xdg-libmesh")

Instead of:

from openmc.xdg import XDGMesh         
xdg_mesh = XDGMesh("mesh.e", library="moab")

From a user perspective XDG feels like another backend for unstructured meshes rather than a fundamentally different concept, so keeping it under the same class might make the API easier to discover and reduce some of the duplication. Happy to hear your thoughts if there's a reason to keep them separate though am I missing something something

[shimwell]

Just a couple of questions here.

Looking at the tests it looks like supported files for 'moab' library are .h5 and .e (which is also exodus format?). I was happy when I saw .vtk in the docstring as a supported file type can we please have a vtk file in the test suit as well.

Would it be good to add .e to the moab supported files, does moab allow .exo? if not then I guess we want a comment to say .e is exodus format.

Suggested change

	Location of the unstructured mesh file. Supported files for 'moab'
	library are .h5 and .vtk. Supported files for 'libmesh' library are
	exodus mesh files .exo.
	Location of the unstructured mesh file. Supported files for 'moab'
	library are .h5, .vtk and .e (exodus). Supported files for 'libmesh'
	library are exodus mesh files .exo.