I’m reporting a critical issue regarding reaction rate generation during depletion. Even when using the exact official depletion.ipynb tutorial (develop branch) openmc-notebooks/depletion.ipynb at develop · openmc-dev/openmc-notebooks, the depletion_results.h5 file contains no reaction rate data, leading to a KeyError on any isotope access.
System Configuration:
OpenMC: 0.14.3
Cross Sections: JEFF 3.3
Chain File: JEFF 4.0 thermal (and others from the same set)
The Issue: The depletion run completes “successfully” (k-eff is calculated, concentrations evolve), but the results object is stripped of reaction rates.
Python
# This fails even if U235 is the main fuel component
results.get_reaction_rate('1', 'U235', 'fission')
> KeyError: 'U235'
Observations:
It seems that OpenMC 0.14.3 does not correctly map the reaction channels from the JEFF 4.0 chain to the tallies during the transport operator phase.
No warnings are issued during the run indicating that tallies failed to initialize.
Question: Is there a known regression in 0.14.3 regarding how the Operator handles the mapping between the depletion chain and the reaction rate tallies when using JEFF 4.0? How can I force the IntegratedDepletionSolver to populate these datasets when the automatic tallying fails?
I did not use JEFF4.0 to make such depletion calculations, but with other nuclear data it works fine. Now I’m using 0.15.3, it is a while that i did not use 0.14 version.
Anyway, did you tried to get atom numbers:
results.get_atoms(“1”, “U235”)
to see if the same error persists, and it is really a mapping problem? Not related to something else. I encountered such like “keyerror” in past, when doing depletion calculation, it was mainly related to mismatching labels, like material ID if I’m not wrong, but “U235” it is an attributed keyword, so it is weird that it generated such issue!!!
To run the tutorial, I actually used the chain_simple.xml file provided directly by the OpenMC team (from the official notebooks repo). So in principle, everything should be aligned with the reference setup.
I did try:
results.get_atoms("1", "U235")
and this works fine — I can retrieve atom densities without any issue. In fact, as a workaround, I’ve been reconstructing reaction rates from that data, but honestly it feels a bit hacky and I’d really prefer a clean, native solution.
So I don’t think this is a mismatch problem. All the other functions behave correctly, whether I use material names or IDs. I also dug a bit deeper by inspecting results[0].rates directly to check if maybe “U235” was labeled differently internally, but it turns out the list is simply empty. That suggests the reaction rates were never written at all, even though the nX.h5 step files seem to contain the expected data during the run.
That’s why I’m leaning more toward an issue in how the tallies are initialized or mapped during depletion with this setup.
By the way, since you mentioned you’re using 0.15.3: do you think it would be a good idea for me to upgrade? I initially stayed on 0.14.3 because I was worried about documentation gaps, fewer examples, or possible compatibility issues with my current workflow. But if this kind of issue is resolved in newer versions, it might be worth it.
First, I agree with you since the command about atom_number worked fine and also for other functions as you rported, so the problem is not a mismatching ID, it should be an issue with tally initialization or mapping. So, I think that you should verify the Tally definition (probably if you can share the few lines you did for tallies instantiation, it may help to see better)
About, 0.15.3 version, I think that is a good idea to upgrade, but before you migrate totally to that version, it is recommended to have just another environment with 0.15.3 version, in such case you will be able to run your models untill you are sure that everthing is ok with.
Thanks for the feedback! Regarding the tallies : I am actually using the exact code provided by the openmc-dev team in their official tutorial (depletion.ipynb) without changing a single line.
Since the notebook works as intended on their end but fails to produce reaction rates on mine, it really suggests that the issue isn’t coming from the Python script itself. Instead, it seems to be an internal code issue or a discrepancy in how tallies are initialized between their environment and my version.
As for upgrading to 0.15.3, I’ll take your advice and set up a separate environment to test the migration. That said, I have some major projects currently in progress that I need to finalize before I can fully commit to an update.
In the meantime, I’ll keep investigating the internal mapping, but if anyone else has encountered missing ReactionRates, I’d love to hear about it!