John Tramm
John Tramm
@gridley -- I've refactored the random ray solver into classes, so the random ray stuff is no longer adding any global variables to OpenMC (besides a handful of things to...
Hi @yardasol -- if you're happy with the changes I've made, please switch your review status from "requested changes" to "approved". Thanks!
Most of the basic theory and documentation for random ray is going in with PR #2823.
The MCPL format does sound great for this use case. As @yrrepy said, the only tricky bit seems to be the particle ID. MCPL appears to have an arbitrary user...
Yes, haha, I had a similar idea about re-using the polarization vector, but agree it seems janky. One idea that comes to mind is that at the end of the...
Thanks @makeclean -- let me know if you run into any issues! Besides the Kobayashi dog leg, I've also been using the UKAEA octomak benchmark for testing/development. There's a few...
Thanks @gridley! Yes, I agree that this brings things much closer to WW capabilities. > Because the WW mesh likely is Cartesian and some approximation error is acceptable in generating...
> Alright, reasonable enough to me. It's easy to debug even if it did cause a segfault from a failed dynamic cast. The opportunity for a seg fault is always...
Thanks @yardasol! Yes, random ray Shannon entropy for random ray is currently under a separate PR (#3030) so the discussion in the docs on this topic is already slated to...
> But the more I think about this: is there enough use of openmc multi-group data to justify this being placed in openmc? I feel like multi-group is pretty rare...