Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Randomized Quasi-Monte Carlo Sampling in The Random Ray Method #3268

Draft
wants to merge 10 commits into
base: develop
Choose a base branch
from

Conversation

spasmann
Copy link

Description

This PR adds a randomized Halton sequence, a form of randomized Quasi-Monte Carlo (RQMC) sampling, as an alternative to typical random number sampling for use in TRRM. RQMC methods decrease the variance in the simulation by providing a more uniform distribution of samples for initializing ray positions and directions of travel compared to random samples.

The Halton sampling method can be specified using the Python API with:

model.settings.random_ray['sample_method'] = 'halton'

OpenMC's native rng is the default sampling method but it can also be specified using:

model.settings.random_ray['sample_method'] = 'prng'

QMC & RQMC Background

Quasi-Monte Carlo (QMC) techniques use low-discrepancy sequences in place of typical pseudo-random number generators in Monte Carlo techniques. Like pseudo-random number generators, low-discrepancy sequences are intended to produce $N$ points $U[0,1]^D$. Unlike pseudo-random numbers, low-discrepancy sequences use deterministic algorithms designed to maximize the distance between the points which is measured using discrepancy statistics.

Despite improved sampling characteristics, QMC techniques are not commonly used in particle transport applications. This is because each point generated in the sequence is dependent on the previous, making QMC techniques ill-suited for modeling the particle random-walk process. Fortunately, as the name implies, TRRM performs a ray-tracing procedure uniformly through the problem, bypassing the need to explicitly model the scattering or fission processes. This provides a well-suited application for (R)QMC techniques.

Standard QMC methods are inherently deterministic, each time a sequence is initialized the same samples are generated. However, for each batch in the TRRM rays are emitted at different locations and traveling in different directions. Therefore new QMC samples are required for each batch. Most QMC sequences are extensible in $D$ however QMC performance takes a significant hit beyond $D>9$. Instead, we can utilize randomized-QMC (RQMC) techniques. RQMC represents a host of techniques which attempt to randomize or shuffle the original QMC sequence but maintain the low-discrepancy of the samples. By randomizing the sequence each iteration, we can generate a unique set of RQMC samples for each set of particles. Additionally, by randomizing the QMC samples we can estimate the variance of the integral (just like in analog MC and traditional Random Ray), something that is difficult to do with unrandomized QMC.

The image below shows samples from a pseudo-random number generator, the Halton sequence, and the randomized Halton sequence.

image

A few helpful resources on QMC and RQMC include

Implementation

The RQMC method implemented here is Owen's randomization of the Halton sequence. Owen’s randomization is well-suited for applications like TRRM because it introduces independent random permutations to the samples, making it possible to generate $R$ distinct sample sets. Similar to OpenMC's native RNG, the reproducibility of samples is ensured by seeding OpenMC's native RNG which is used in the randomization process. Additionally, Owen's randomization allows for the efficient generation of new samples in parallel by constructing rows in the range $\left[N, N^\prime\right]$. Finally, Owen's randomization method was chosen for its straightforward implementation and lack of any additional user input.

Verification & Performance

The implementation has been verified by evaluating fission pin cell powers from the 2D-C5G7 problem. The performance boost provided by the RQMC samples compared to random samples will vary by problem. In general, RQMC should give better performance to problems with higher spatial sensitivity e.g. a fine spatial mesh or TRRM's linear source approximation.

Results were generated on one Perlmutter node (2x AMD EPYC 7763), utilizing one MPI rank and 256 OpenMP threads. In the following figures, each data point represents the mean result from 80 individual simulations (each set with a different seed), while the shaded regions represent one standard deviation.

142,964 Flat Source Regions

image

Surprisingly, simulations using Halton samples were on average over 10% faster using a fine mesh.
 
drawing

17,924 Linear Source Regions

image

The coarse mesh runtimes are nearly identical.

drawing

Runtime Performance

It is very unlikely that the Halton sampling algorithm itself is faster than OpenMC's native RNG (although I have not compared them). My current hypothesis is that the Halton samples result in reduced shared memory contention because the samples are generated in such a way that each subsequent point will be "far away" from the previous point. The plot below shows the percent speedup of the Halton sample simulations compared to the RNG simulations as a function of the number of OpenMP threads used and generally supports this hypothesis.

However, the trend is noisy, and I would have expected this phenomenon to be more pronounced on coarse meshes. Instead, the runtime performance on the coarse mesh simulations were nearly identical. I'll need to run more tests to figure out what exactly is giving the Halton a runtime advantage in the fine mesh simulations. In any case, it doesn't seem that the Halton sampling hurts runtime, I think this makes sense as the bulk of the compute time is spent in the ray tracing procedure.

drawing

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)

@spasmann spasmann requested a review from jtramm as a code owner January 18, 2025 17:12
@spasmann spasmann marked this pull request as draft January 18, 2025 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant