Weight Window Birth Scaling

[jtramm]

Overview

Currently, particles starting in regions with very low weight window values may aggressively split shortly after being born. This reduces sampling efficiency as there is no reason to place such great importance on particles right at birth.

This PR introduces two normalization factors to improve the behavior of weight windows so as to prevent aggressive splitting or rouletting right after particles are born.

Improvement 1: Scaling by Weight Window Value at Birth

The first normalization step involves adding a new variable to the particle object (ww_born_) that records the weight window value of the particle when it is born. This value can then be used to divide any weight windows before they are applied to the particle.

Improvement 2: Scaling by Particle Birth Weight

In the context of importance sampling, particles may be sampled with very low weights leading to immediate weight window effects right after birth. Thus, the second normalization step involves multiplying weight window values by the particle's starting weight.

Testing

To test this problem, I use a greatly simplified 2D model of JET that retains some key characteristics. Namely, it is a 40x40 meter model that has a 2.5m thick bioshield and 30cm thick borated concrete liner around a room filled with air. Inside the room, there is a large donut shape in the middle of the room that contains a 14.1 MeV plasma source (with chamber walls, steel shielding, and coolant layers around it).

Geometry:

This is a great test case for weight windows, as we can see the high difficultly that analog MC has in delivering particles to all areas of the bioshield. Below, we see the analog MC flux without any weight windows, with particles only able to explore a few 10's of cm into the concrete wall.

Below, we can see that random ray FW-CADIS generated weight windows (with 2 energy groups, on a 10cm resolution mesh) are highly effective, scoring tallies everywhere in just a few minutes on my laptop:

To test the improvement that scaling delivers, I ran the problem for a target time of around 300 seconds on my laptop and studied three cases: 1) without weight windows, 2) with weight windows (no scaling), and 3) with weight windows (with scaling, as in this PR). As all the runtimes are around the same, the key figures of merit are the average relative error for all tallies (with flux tallied at 10cm mesh resolution) and the particle tracking rate.

Results summary:

	No Weight Windows	Regular Weight Windows	Scaled Weight Windows (This PR)
Particles/batch	450,000	1,000	45,000
Batches	50	10	10
Runtime [s]	295	338	386
Particles/s	76,151	30	1,166
Cells Hit [%]	83.0	100.0	100.0
Avg Relative Error [%]	22.8	9.7	7.6
Maximum Relative Error [%]	100.0	99.2	94.6

The weight windows perform well both with and without the scaling. In both cases, the weight windows are able to deliver scoring particles to all regions, whereas without any weight windows very few particles migrate into the bio shield at all. The scaling strategy does show significant improvements both numerically and practically as compared to the unscaled weight window usage. For relatively equal runtimes, we get a non-trivial decrease in average relative error (form 9.7% to 7.6%) and a significant improvement in particle tracking rate from 30 particles/sec to over 1000 particles/sec. While the tracking rate by itself is somewhat meaningless, lower tracking rates create two practical problems: 1) load imbalances between threads become more significant due to threads waiting for long particle histories to complete on other threads, and 2) for a given target runtime, fewer starting particles are sampled, potentially adding noise/bias given that the starting source distribution is not as well explored.

To get an idea of why the scaling is important, we can look at the random ray FW-CADIS weight windows for the fast group on this problem:

as can be seen above, particles in the plasma region of the problem are starting in areas with lower bound weight window values of 10^-3. Absent the new scaling technique, this means that each sampled particle is likely to immediately split into 1,000 copies. Even if the max_split variable is set to a lower value, the particle will still aggressively split over its first few events, such that 1,000 copies will still be made very early in its lifetime. Thus, the new scaling technique ensures that particles at least travel to the wall of the tokamak before mild splitting events begin to occur.

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)

[Copilot]

Pull Request Overview

This PR improves weight window scaling to prevent aggressive particle splitting by introducing two normalization factors: one based on the weight window value at particle birth and another based on the particle’s birth weight.

• Introduces a new particle attribute (ww_born_) to record the birth weight window value.
• Normalizes weight windows in apply_weight_windows() using the particle’s starting weight and ww_born_.
• Updates simulation initialization to set the ww_born_ value before applying weight window adjustments.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/weight_windows.cpp	New logic to initialize and scale weight windows using ww_born_.
src/simulation.cpp	Sets the initial ww_born_ value and invokes apply_weight_windows().
include/openmc/particle_data.h	Adds the ww_born_ member and corresponding accessors.

[makeclean]

That's very useful, you'll also get much less biassing due to low source sampling rate too - which frankly is a common theme in applications, often limiting analysis throughput in 'real' applications. Super useful, big fan.

[paulromano]

Thanks @jtramm for this simple but important PR! I'm going to give it a whirl on a few problems but thus far the logic looks sound.

@pshriwise let us know if you want to review before we merge.

[pshriwise]

Looks good to me! Thank you @jtramm!