Closed nelsonag closed 8 years ago
I have an interesting finding to share. So I made a script (the one which yielded PR #702) to compare libraries of the same isotope/metastable state at all the temperatures. I ran tihs so far only on the MCNP6 endf70 data.
I found that for the most part it behaves exactly as you would expect: cross sections and the x/s energy grid are T-dependent and thats mostly it. This holds for all reaction channel x/s, even though BROADR typically doesn't broaden in the fast range, since the ACER thinning algorithm has a chance to change the energy grid. Having said that we could probably force the grid to be the same in the fast range and it'd be OK.
There were two surprises though:
I wanted to give a little update on this:
du
command on the jeff-3.2 data which has loads of temperatures).default_xs
with default_temperature
and the xs
attribute of a nuclide/element/macroscopic/sab with a temperature
attribute on a material (I did the same on the pyapi side too)xs
. I dislike the idea as it makes the least sense (they should all be the same!), but it will solve this problem.Ok, so otherwise, expect this issue to be resolved with the following set of PRs:
temperature
attribute/element instead of xs
aren't worth it.nuclide_header.F90
and associated code so the data representation within OpenMC also removes redundant temperature independent data.
A PR analogous to #3 but for MG mode shouldn't be necessary since all the data is temperature-dependent, and therefore there isn't much of a driver to separate it out. If we find a good enough reason, or just to make MG look like CE (even though the MG data isn't in the nuclide class like it is for CE...), expect a future PR.
Oh, I should have added what the data format looks like for early digestion:
Within the file U235.h5
:
\U235
\energy # Every temperature has an independent energy grid due to NJOY thinning
\294K
\600K
\kTs
\294K
\600K
\reactions
\reaction_002
\294K
\threshold_idx
\xs
\600K
\threshold_idx
\xs
\Q_value
\center_of_mass
\products
\...
A few notes:
@nelsonag Sorry I've been mute so far. This all sounds great. Regarding the S(a,b) table issue, I think your option (b) sounds pretty sensible (having it pick the closest temperature and putting out a warning).
Two suggestions:
threshold_idx
as an attribute on the xs
dataset.I agree with option (b).
On Tue, Aug 23, 2016 at 10:42 AM, Paul Romano notifications@github.com wrote:
@nelsonag https://github.com/nelsonag Sorry I've been mute so far. This all sounds great. Regarding the S(a,b) table issue, I think your option (b) sounds pretty sensible (having it pick the closest temperature and putting out a warning).
Two suggestions:
- For storing the kTs, you could just have a single dataset that is an array of kTs.
- Store threshold_idx as an attribute on the xs dataset.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mit-crpg/openmc/issues/697#issuecomment-241754214, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_TM-F_O6NdQ6EKbdiQZa27tyWYbVpqks5qiwbpgaJpZM4JeU_H .
Re: kTs -- On second thought, it's easy to add a new group/dataset whereas I'm not sure what happens if you try to modify an existing dataset, so I think you're right on this one.
Closed by #712. Yay!
Some continuous-energy nuclear data is independent of material temperature; this includes the nuclide metadata and, energy-angle information, and for some evaluations, fast energy cross sections for some reaction channels. To significantly reduce the storage size and better set us up for temperature dependence, it would make sense if the data files for multiple temperatures were 1) combined in to a single file, and 2) redundant information removed.
That is, if the current data format of:
be re-written to be: