Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
There may be some changes required to Sphere SDDR with this update - it looks like the raw user value is used with label = isotope which is OK for FNG-SDDR as the mapping is done in the raw config. We don't have that for sphere SDDR so the isotope numbers will be retained. Likely best to retain the original behaviour through try except statement.
There was a problem hiding this comment.
I will double check this, yes
| tcf.index = self.irr_scenario.cooling_labels | ||
| tcf = tcf.T | ||
|
|
||
| tcf = tcf.mul(df["Value"], axis=0) |
There was a problem hiding this comment.
It looks like the tally data keeps the original OpenMC names eg Nb92_m1 whereas the correction factor table is using the f4enix converted convention, Nb92m. Would likely result in a NaN value. Same for the error.
Looks not to be captured in tests as only ground state included.
There was a problem hiding this comment.
yeah I think in this PR I avoided the issues of metastables, for the final version I should account for it
| nuclides = [] | ||
| for nuclide in df.index: | ||
| # Convert OpenMC metastables to F4Enix convention | ||
| nuclide = nuclide.replace("_m1", "m").replace("_m2", "m") |
There was a problem hiding this comment.
Assuming 2nd metastable state same as first?
There was a problem hiding this comment.
At the moment there is no distinction, do you have cases in mind where both the first and second metastable of an isotope are important and should be distinguished?
| from jade.post.sim_output import MCNPSimOutput, OpenMCSimOutput, OpenMCSphereSimOutput | ||
|
|
||
| logger = logging.getLogger(__name__) | ||
| pd.set_option('future.no_silent_downcasting', True) |
There was a problem hiding this comment.
This is only in pandas >2.2 so we should add to the toml.
There was a problem hiding this comment.
F4Enix already has a requirement on pandas > 3.x, I do not want to add a potential conflict by adding a different pandas req also in JADE
There was a problem hiding this comment.
I think I remember seeing that its contribution was almost negligible and removed it since it was a bit of a headache to account for metastables. The final version will need to address the issue
2 participants
The following PR:
This PR introduces D1S capabilities for OpenMC to JADE for the first time. Unlike MCNP, where D1S calculations are handled as if they were performed by a separate code, it was possible to simply extend the existing functionality of the
openmccode without the need to create a new one.Input generation and run
For D1SUNED, two additional files are required: one to specify the decay reactions to be followed and another to specify the time correction factors to be applied in order to obtain SDDR at different cooling times. Moreover, D1SUNED requires specially generated libraries that must be mixed with the transport library in the input.
OpenMC takes a different approach. Regarding the libraries, nothing changes compared to a standard transport calculation. The only additional requirement is that a chain file (containing all possible reactions) must be made available through an additional environmental variable (
OPENMC_CHAIN_FILE). Moreover, time correction factors are not needed at run time. Results are computed at shutdown, and the dose at different cooling times is obtained during post-processing. This also means that an SDDR tally in OpenMC must always specify a filter indicating which daughters (called "parents" in OpenMC) need to be tracked, and no "total dose" tally is possible. This limitation cannot be avoided because, to obtain the dose at a different cooling time, the time correction factor for each daughter must be computed and applied.All of this means that no modifications were needed for the generation or execution of OpenMC inputs, with the small exception of the irradiation file concept, which I will discuss in a moment.
Post-processing
While the OpenMC approach simplifies input generation and execution, it shifts the complexity to the post-processing stage. OpenMC provides its own methods to apply time correction factors to the results, but after looking into them, I found that integrating them into JADE would have been somewhat cumbersome.
I decided to use F4Enix to compute the time correction factors (I think the irradiation support we developed there is quite neat) and apply them to the dose tally. At that point, I could have followed two different approaches:
I chose the second approach. With only a couple of additional functions, JADE can now read a very simply formatted ASCII irradiation scenario (provided together with the input files) and use it to compute the appropriate time correction factors, apply them, and produce a tally in the
[User, Time, Value, Error]DataFrame format, matching the D1SUNED output.This should make it extremely straightforward to implement new D1S benchmarks with OpenMC.
As for the selection of daughters ("parents" in OpenMC), as mentioned earlier, they can simply be listed in a dedicated OpenMC filter inside
tallies.xml.Missing features
OpenMC can only filter by daughter isotopes (i.e., the ones producing the decay photons). It cannot filter for parent isotopes (i.e., the ones that gets activated and lead to the daughters radioactive isotopes). This is probably a feature that we need to request to OpenMC developers in the future. It will involve tallying how many daughters are produced by the different possible parents.