Splitting during free path sampling

[vitmog]

Description

Currently, the split/roulette technique can be applied after the collision and each geometry boundary surface crossing events during free path length (FPL) sampling. The latter provides "biasing" of the sampled FPL distribution, which is an extremely efficient tool for variance reduction in particle transport through highly absorbing media. However, for using this feature in an efficient manner, the current implementation requires separating existing geometry cells of homogeneous shielding blocks (often almost monolithic in contrast with the source regions) into artificial ones, which is significantly slowing the calculation due to extra geometrical and XS computations, and it is not always possible in practice.

Proposed technique

The simplest way for FPL sampling modification in OpenMC appears to be applying the weight window mesh (WW-mesh) boundaries splitting. It could provide a geometry topology independent solution of this problem and the lower cost of ray tracing. For example, the definition of the WW-mesh with the step value less than $1/\Sigma_{a}$ should efficiently and automatically replace even exponential transform, including arbitrary non-monotonic forms of the "biasing" function, which can be unique to each problem.

Implementation

At this point, the OpenMC meshes already have the required ray tracing functionality, which, as I assume, should be much faster than the geometrical tracing at least for the regular meshes. Thus, implementation of this approach requires just creating an additional inner loop within calling Particle::apply_weight_windows() inside Particle::event_cross_surface(). If so, for the history-based simulation, just to make this straightforward modification could be enough.

Help request

For the event-based simulation, the issue is open. It seems to me that parallelizing the WW-mesh loop is not necessary, because the mesh step should be much cheaper than the geometry cell step, and the total number of splitting copies to the bank does not change significantly in comparison with the existing situation, so it should not affect the current balancing. In general, my understanding of the parallelization issues is limited, so I would be grateful if someone could correct me.

While such a feature definitely complicates the core part of the code, I would like to hear the opinion of the maintainers and community members about it and how it is going along the plans of development, if it seems to be needed.

Alternatives

There are a wide range of alternative optimizing solutions for FPL-splitting, which are not related to splitting on WW-mesh boundaries. However, they all require the same technical modification and can be implemented after this one. Thus, it can be considered as a further development direction.

It is also possible to apply importance sampling for FPL instead of splitting via computing the cross-section of importance function by the particle's ray. However, it requires computing the pdf normalization before sampling, so preliminary ray tracing of both WW-mesh and geometry should be needed. Also, it could be desirable to keep this data for secondaries, but it would complicate the current logic of OpenMC.

Compatibility

Providing a new interface option enabling the WW-mesh splitting eliminates any backward compatibility issues.