John Tramm
John Tramm
Closed by #3072
This is very cool! The general idea for the implementation looks great as well -- seems like an elegant way of getting this done. I'm also interested in hearing more...
After a quick look through, the main thing that jumps out to me is the use of transport corrected XS data. It should be pretty trivial to have the random...
Once this PR (https://github.com/xtensor-stack/xtensor/pull/2821) gets merged into xtensor, I think we should be able to just update the xtensor version in OpenMC to get it working again with LLVM 19.
I think it currently accepts either a string to use a predefined group structure, or a `openmc.mgxs.EnergyGroups` object for that argument. The latter could be initialized with an arbitrary group...
This is a great point! Yes, as it is now, it's quite wasteful that the forward flux statepoint is lost when running in adjoint mode. As you said, it would...
Currently the lack of shared secondaries is a real killer in terms of performance. The excess memory usage is an issue but, in my experience, is usually not a deal...
Yes, thanks @vitmog for proposing this optimization! This is a nice implementation for sure -- I would be on board for including it if there were a demonstrated use case...
This is great -- thanks so much @spasmann! The only potential change that comes to mind might be to have the python statepoint object variables stored in a `random_ray` dictionary...
@paulromano - that is definitely a valid point. In general it is not good to store the same data twice if it can be avoided. There is however the case...