Add chi cross sections to MGXS machinery

[yardasol]

Description

This PR adds a chi cross section to the existing MGXS machinery. This cross section will be used in the kinetic random ray simulation mode. I have not been able to find anywhere in the MGMC code where chi_prompt or chi_delayed are used, so I have been unable to add chi to the MGMC machinery. If anyone knows where in the source code these cross sections are used, that would be helpful. But if they aren't no problem I suppose.

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)

[nelsonag]

@yardasol, if memory serves, MG transport doesnt use chi, instead it builds the more accurate nu-fission matrix to determine outgoing fission neutron energy from an incident neutron. Does this help clarify?

…

On Fri, Jan 16, 2026, 12:56 PM Olek ***@***.***> wrote: @yardasol <https://github.com/yardasol> requested your review on: openmc-dev/openmc#3740 <#3740> Add `chi` cross sections to MGXS machinery as a code owner. — Reply to this email directly, view it on GitHub <#3740 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5GMYXIVCF5ZHVA3M5J7L4HEX6RAVCNFSM6AAAAACR6JYOFOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRSGEYDEOJZHE4DQNA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[jtramm]

@nelsonag - the way we have implemented the random ray solver we do currently use Chi (math is here):

https://docs.openmc.org/en/latest/methods/random_ray.html#power-iteration

Let me know if there's another way of doing this though!

@yardasol - we currently use CHI_PROMPT for random ray's Chi variable, as empirically this seemed to be where the Chi we needed was stored. Should the random ray solver now use CHI instead?

[yardasol]

@jtramm Both CHI and CHI_PROMPT are needed for kinetic simulations (the former for establishing an initial condition, the latter for the actual kinetic simulation). This PR adds such functionality to the MGXS machinery, and modifies the random ray machinery to use CHI in lieu of CHI_PROMPT (since the current simulation mode assumes the system is static). This is done in the associated changes for flat_source_domain.cpp

[yardasol]

@nelsonag Thanks for that clarification! Do you recall which file this machinery lives in?

[nelsonag]

Sure, it's in xsdata.cpp, see the XsData::fission_*_from_hdf5 methods. These load the users input (chi + nu fission no delayed, chi + nu fission with delayed, nu fission matrix no delayed, etc) and build the chi prompt and chi delayed matrices accordingly. If no delayed data is used, then we put the total data within prompt. No matter what, the output will be a chi matrix and a nu fission vector, for both prompt (or total) and delayed. These are then used in Mgxs:: sample_fission_energy to select the outgoing group based on the incoming group. I haven't given it much thought yet, but why do you need something different for random ray?

…

On Thu, Jan 22, 2026, 12:12 PM Olek ***@***.***> wrote: *yardasol* left a comment (openmc-dev/openmc#3740) <#3740 (comment)> @nelsonag <https://github.com/nelsonag> Thanks for that clarification! Do you recall which file this machinery lives in? — Reply to this email directly, view it on GitHub <#3740 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5GM3ZGBJDSFX2LHL2A3D4IEHHLAVCNFSM6AAAAACR6JYOFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBVHE2DCNRRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[yardasol]

@nelsonag Thanks for that explanation! @jtramm My understanding based on FlatSourceDomain::flatten_xs() is that chi_ is a flattened source_region x energy vector. If the mgxs machinery truly is returning a chi matrix, then aren't we just picking the diagonals of the matrix and missing all the off-diagonal components? Should we fix this for users using fission matrices for their MGXS?