Create a new class for particle ray tracing

[vitmog]

Description

The new ParticleRay class should be derived from the Ray class, and it will implement the computation of geometrical, XS, and time parameters of the cell crossings by a ray emitted from the given origin location in the given direction both with and without usage of known geometry state. Also, it will provide the following optional abilities:

• Limit the geometrical/optical/time length of the ray;
• Enable/disable the XS/time computations;
• Keep the crossed cell, geometry length, XS, and time segment-wise data in a std::vector entity for further reusing;
• Provide an alternative way to fill the ray during the ordinary particle tracing process;
• Provide an API for moving a particle along the ray on the given geometrical/optical/time distance.

Such feature aims to simplify the implementation and code maintenance of a wide range of diverse efficient techniques intended predominantly for fixed-source problems, for example:

• Point estimator;
• Other expected-value estimators [1];
• The volume ray tracing estimator used in PR Ray tracing volume calculation and geometry testing #3645;
• Prohibition of leakage (holding particles at the edge of the model) which is extremely efficient for the skyshine problems [1].

Also, the proposed encapsulation will allow us to implement the saving of a ParticleRay entity in secondary_bank. Then, the multiple reuse of a once-filled ray is able to dramatically improve performance of aggressive splitting during free path length sampling (#3791) in highly absorbing media [1] instead of exponential transform.

This approach has proved to be efficient in my experience [1].

The implementation of ParticleRay is quite straightforward in general, and it can be started as an extension of the similar existent class VolEstRay from PR #3645. In principle, the ParticleRay implementation should replace VolEstRay if the Ray Tracing Volume Calculation reviewing process advances.

I am looking for feedback.

Alternatives

To leave it as is and implement specific the geometry tracing functionality for each case where it is needed.

Compatibility

Internal modification, no API changes, no changes of the existing code. It is intended for future developments and not yet merged features (#3109, #3645), which are currently under design.

References

1. V.G. Mogulian. An approach to radiation shielding evaluations using estimators by expected scoring. 2025. doi:10.5281/zenodo.16781416.

[vitmog]

@paulromano @pshriwise How is it going along the OpenMC development priorities? Are you interested in OpenMC development toward shielding applications? If so, is there a need for such dose rate mapping ability in OpenMC as presented in doi:10.5281/zenodo.16781416?

@jtramm An ideal (by the total number of computational operations) implementation of this approach requires storing XS and ray segment-wise data for each splitting point. Thus, the size of records would be increased and become variable from one case to another. I guess it is not compatible again with shared secondaries, as discussed in #3656. Is that right?