Random Ray Point Source Locator

[jtramm]

Description

This PR introduces the ability for the random ray solver to accept point sources when in fixed source mode. Previously, external sources had to be defined via a domain constraints (in terms of cell, material, or universe ids). To represent something like a "smeared" point source with a domain constraint is actually kind of a pain, as the user would have to manually make a small cell in the geometry where the source domain could be applied, and make the corresponding edits to the outer cell to be the complement.

The upcoming PR #3011 will solve all of these issues and allow for any type of source to be used. However, in the interim, it would be nice to allow the random ray solver to handle more source types.

In this PR, OpenMC will now automatically relate a point source to the appropriate source region -- even when automatic mesh subdivision is being used (which is not totally trivial, as the source regions are not known in advance -- they are discovered only when a ray visits them during transport).

To be clear, the point source is not exactly represented (as it will be in PR #3011) -- it is still going to be "smeared" out to fill up the full volume of the source region it is in, thus becoming a volumetric source. However, if a user is overlaying a mesh, the error caused by the "smearing" goes down as the mesh resolution increases. This was not really the case with the old behavior if using a domain constraint, as all subdivided mesh cells within the original domain would also contain the source.

This new feature should make it much easier to get up and running with the random ray solver, as point sources are very typical in "hello world" style input decks for fixed source problems.

Validation

I ran the kobayashi dogleg, with the normal problem definition where the source is spread out over a 10x10x10 cm^3 cell. I also ran a modified problem that has a point source at {5, 5, 5} in the middle of the same cell. I then overlaid a finer resolution subdivision mesh, so that hopefully the point source will appear in a single subdivided source region rather than being applied to the entire 10x10x10 cm^3 cube.

Here's a 2D slice plot showing the flux in the source region when using the domain constraint:

vs. using a point source:

The results look good! Notably the point source plot looks a little noisier, which is as expected given that the source is taking up a much smaller volume so is becoming less efficient to integrate.

In the future, PR #3011 will introduce the ability to calculate first collided source terms for any source type, thus greatly improving the efficiency and accuracy of things like point sources (and also allowing support for all types of spatial/angular distributions). For now though, this PR at least adds basic support for point sources while we await PR #3011.

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)

[paulromano]

Nice improvement for now while we wait for #3011. Thanks @jtramm!