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