Angular flux tallying capabilities for Random Ray

[j-fletcher]

Description

Currently, only tallies based on the scalar flux are possible in Random Ray mode. Beyond the tallies themselves, the ability to output angular flux information will enable automated source biasing over angle--in addition to space and energy--as part of the FW-CADIS workflow. Additionally, accumulating the batch-wise angular flux in each source region is a necessary precursor to computing anisotropic scattering source terms.

Compatibility

As the reduction in memory overhead from not storing angular fluxes at the boundary is one of the key advantages of Random Ray over conventional MOC, care should be taken that in storing and tallying potentially $N_\Omega$ flux values in $N_E$ energy bins in $N_{SR}$ source regions we do not erase most if not all of those gains. Likewise, anisotropic scattering sources could potentially require storing a significant amount of groupwise angular data in each source region of the geometry.

However, if the scope is limited to simply tallying the angular flux in certain regions of phase space, the groupwise angular flux could easily be banked in a select number of source regions by simply adding a new vector in each region to which each passing ray contributes delta_psi_, in the same way as is done with scalar_flux_new_. Additional changes will be needed to SourceRegion to indicate when a given region is in the area of interest where angular flux will be tallied, and to the TallyTask class to indicate when a specific tally score is based on the angular flux instead of the scalar flux. Finally, while tally scores are currently updated at the end of each batch, "live" RandomRay instances will need a method to determine which angular bin to accumulate to during transport. Therefore, the angular binning structure defined on such a tally will likely need to be shared by FlatSourceDomain and dictate the size of the "scalar_flux_new_" analogue mentioned earlier.

[ChasingNeutrons]

One possible way of obtaining angular flux estimates could be in a postprocessing step. Barry Ganapol is fond of "Faux Quadratures", i.e., quadrature points which don't contribute to the scalar flux integration. This is used in his work to obtain angular flux estimates at specifically chosen angles at specific locations. One could do something similar for random ray as a postprocessing step, depending on what the intention is. After estimating the scalar flux, one could do a sweep of rays chosen deterministically to hit certain bits of phase space and provide angular fluxes. As usual, this would involve starting the rays far enough back from that point such that initial guess angular flux errors are attenuated, however the ray could be terminated once it contributes to the chosen point. I don't have any feel for how much more efficient or complex this would be than tallying live, and one wouldn't directly have access to uncertainty in the angular flux (due to the active cycles) from this approach either.

[j-fletcher]

After estimating the scalar flux, one could do a sweep of rays chosen deterministically to hit certain bits of phase space and provide angular fluxes. As usual, this would involve starting the rays far enough back from that point such that initial guess angular flux errors are attenuated, however the ray could be terminated once it contributes to the chosen point. I don't have any feel for how much more efficient or complex this would be than tallying live, and one wouldn't directly have access to uncertainty in the angular flux (due to the active cycles) from this approach either.

Thanks for the suggestion! I could definitely see that approach being useful in a few cases like "low-N" problems or where a rough estimate of the angular flux might suffice, such as for generating source biasing/weight window parameters (where I'm going with this capability next). In problems with a localized fixed source and a local response of interest it would be fairly simple to leave the flux accumulation loop untouched and just add an extra step during or after FlatSourceDomain::random_ray_tally() that backs rays out at each quadrature angle from the ROI. In terms of operations it would eliminate needing to check during each (active batch) region crossing whether angular tallying is needed in RandomRay::attenuate_flux_flat_source() and we'd only have to accumulate/normalize the angular flux in each direction once.

I still lean towards the "live" tallying method though since I sense it's probably better suited to more general applications for the angular flux--in no small part due to access to statistics as you mentioned, but also as with every additional source region where angular flux information is requested, $N_{\Omega}$ additional post-processing rays would need to be tracked, which could get quite intensive. Additionally, banking the angular flux from rays in active cycles samples from a uniform distribution of ray starting points over the full geometry, which would also help minimize initial-value bias.