Implement Virtual Lattice Method for Efficient Simulation of Dispersed Fuels

[liangjg]

Description

This PR introduces a "virtual lattice" method, an acceleration technique designed to improve the performance and reduce the memory footprint of MC simulations for systems containing a large number of randomly dispersed particles.

Background

Simulating explicit, randomly distributed particles is computationally prohibitive due to the geometric complexity. Locating a neutron among hundreds of thousands of spheres is a major performance bottleneck.
The existing create_triso_lattice function implements a "physical lattice" approach. While this provides acceleration, it has several drawbacks:

• It modifies the model geometry by creating a large number of cuboid cells.
• This leads to a massive increase in the number of surfaces and cells, significantly inflating memory usage and input file size.
• It complicates post-processing, as tallies on particles (which are split by the lattice) must be manually recombined.
• The complex geometry can negatively impact parallel efficiency at large scales.

Implementation

The virtual lattice method decouples the acceleration structure from the actual CSG model. Instead of physically dividing the geometry, it works as follows:

• Overlay Mesh: A regular, hypothetical mesh is overlaid on the region containing the dispersed particles. This mesh exists only as an in-memory data structure and does not create new surfaces or cells in the OpenMC geometry.
• Pre-computation Map: During initialization, a map is built that associates each virtual lattice element with a list of the particles (e.g., TRISO spheres) that intersect it.
• Accelerated Search: During particle transport, the code first identifies which virtual lattice element the particle is in. It then only needs to test for intersections with the small subset of spheres associated with that element, dramatically reducing the search space for:
  • Finding the cell a particle is in.
  • Calculating the distance to the nearest surface.
  • Processing surface crossings.
    This approach retains the acceleration benefits of a lattice structure while avoiding the overhead of a physical one.

As demonstrated in the associated paper, the virtual lattice method provides substantial advantages over the physical lattice method.

• Reduced Time Consumption: Faster transport calculations due to a simpler geometry and more efficient search algorithm (up to ~36% reduction in simulation time for the HTR-PM model).
• Massively Lower Memory Footprint: The geometry is a single universe filled with particles, leading to dramatic reductions in memory (e.g., from >192 GB to <1 GB for the HTR-PM model).
• Improved Parallel Efficiency: Better load balancing leads to significantly higher parallel efficiency at large scales (e.g., 83% vs 56% weak scaling efficiency).
• Simplified Workflow: Tallying on whole particles is straightforward, as they are no longer geometrically split. This also greatly simplifies specifying burnable materials for large-scale depletion.

Usage

The feature is exposed to the user via a simple boolean flag in the Python API. To use the new method, a user simply sets virtual=True:

# Old physical lattice
lattice = openmc.model.create_triso_lattice(...)

# New virtual lattice
lattice = openmc.model.create_triso_lattice(..., virtual=True)

This implementation is based on the methodology and results presented in the following paper. For a detailed theoretical background, performance analysis, and validation, please refer to:
Liang, J., Li, R., & Liu, Z. (2024). Virtual lattice method for efficient Monte Carlo transport simulation of dispersion nuclear fuels. Computer Physics Communications, 295, 108985. [https://doi.org/10.1016/j.cpc.2023.108985]

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 15) 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)

[liangjg]

Hi @paulromano ,

As requested, I've opened the pull request for the new virtual lattice feature, based on the work in our recent CPC paper.

I've run into a few points where I could use your guidance and help to get this PR ready for review:

1. Merge conflicts with develop: The initial implementation was based on v0.13.0. I've attempted to rebase it onto the latest develop branch, but there are significant conflicts, especially with the recent refactoring in the geometry module. I'm not yet familiar with the new architecture and am struggling to resolve them correctly. I would greatly appreciate your guidance on how to best adapt this feature to the new geometry logic.
2. Documentation: to be updated.
3. Future Enhancement (Follow-up Discussion): This feature enables extremely large models (e.g., 4.2x10^5 pebbles with ~10^4 TRISOs each). A challenge arises for depletion simulations when one wants to apply distributed materials on the TRISO particles, as specifying a unique material for each of the ~4.2 billion TRISO particles is impractical. But in most cases, one wants to assign materials on a per-pebble basis rather than a per-TRISO basis, so it is possible to implement a material_step or similar concept. For example, a user could provide 100k materials and specify that each material should be applied to the next 10k TRISO particles (material_step=10000). This is likely out of scope for this PR, but I wanted to put it on your radar, or maybe you have better ideas.

Thanks for your time. Let me know what the best next steps are.

[cn-skywalker]

@liangjg Hi
Dear Professor Liang, I often use the TRISO function and have also been following your work for a long time.
I'm very glad that you can contribute your code to openmc. I believe this is a great learning opportunity for me. If possible, I also want to participate in the development of this function.I previously completed the development of CLS implicit methods based on version 0.15.2. However, only normal particle transport can be accomplished, and the coupling of the tally module has not yet been completed. I am already relatively familiar with this geometric search architecture. If there are any unfinished tasks, you can communicate with me.