Generalization reaction rate calcutions

[jakehader]

Based on the changes proposed in https://github.com/terrapower/armi/pull/810#discussion_r937171187, the following suggestions were made to further improve the reaction rate calculation for blocks/components but we're not yet implemented.

1. Let's change the xsType input to be microSuffix, so that this encapsulates both the XS Type (i.e., A, B, C) as well as the burnup group (i.e., A, B, C) so that we can actually get reaction rates based on burnup-dependent cross sections.

To do this, we can use self.getMicroSuffix(), where on the block level this is implemented as is, but on a component this is implemented as reaching up to its parent and getting it from the block-level.

2. It would be advantageous for us to standardize the dictionary of reaction rates that can be obtained from the nuclide data library - {"nG": 0, "nF": 0, "n2n": 0, "nA": 0, "nP": 0, "n3n": 0}. This is a bit of a refactor, but having this mapping of these strings to the following xsLibrary micros would be good:

        ("nG", libNuc.micros.nGamma),
        ("nF", libNuc.micros.fission),
        ("n2n", libNuc.micros.n2n),
        ("nA", libNuc.micros.nalph),
        ("nP", libNuc.micros.np),

Just grepping around the code base, I see this mapping occurring in blocks.py/getReactionRates, composites.py/getReactionRates, component.py/getReactionRateDict, isotopicsDepletionInterface.py/makeXsecTable, and crossSectionTable.py/CrossSectionTable.

It might make sense to have the strings for nG, nF, n2n, nA, nP, etc. mapped back to xsCollections.py module-level constants that already exist:

NGAMMA = "nGamma"      # radiative capture
NAPLHA = "nalph"       # (n, alpha)
NP = "np"              # (n, proton)
ND = "nd"              # (n, deuteron)
NT = "nt"              # (n, triton)
FISSION_XS = "fission" # (n, fission)
N2N_XS = "n2n"         # (n,2n)
NUSIGF = "nuSigF"      
NU = "neutronsPerFission"

[keckler]

I'm gonna work on this. Thinking about it more, this is really a bug that is leading to inaccuracies in my calculations against data.

[keckler]

911 addresses Point (1) above.

Point (2) is for another PR. Not sure I'm gonna do that one at this point though.

[john-science]

As to your Point (2) above, I think if you want to make a chunk of data "standard" in this way, we would use a class. So there would be a class (even a very, very small one) that has attributes: self.nG, self.nF, self.n2n, self.nA, self.nP, self.n3n, all with a well-defined type.

The benefit here is there isn't some "standard dictionary with six magic keys" that everyone just has to know about. No one could forget one, and screw things up.

Just thinking aloud here.