-
Notifications
You must be signed in to change notification settings - Fork 35
Add Serpent depletion conversion script #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Creates an equivalent depletion chain using decay and fission yield files distributed with Serpent. Some steps are taken to clean up and fix a few issues. The fixes are detailed in the script and here for completeness. First, the files appear to be ENDF-6 formatted files concatenated together. Unfortunately, there is a TEND record after each dataset, so :func:`openmc.data.endf.get_evaluations` will only read and return the first evaluation. For this reason, we must read the file until all records have been found manually. Secondly, the decay file does not have a tape indent (TPID) record, which can throw off the first reading. This exception can be caught, but it currently involves skipping the first item in the file. At the time of this writing, this skipped item contains the decay data for a neutron. Lastly, there is a single negative uncertainty in the Co-55 k-shell conversion energies. This quantity is not used in the depletion chain, but it must be altered to prevent downstream failures. Supports reading in an additional chain file and applying branching ratios prior to exiting.
paulromano
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the Serpent files sss_endfb7.dec and sss_endfb7.nfy are just directly from ENDF/B-VII.0. In the case of the decay file, it's literally byte for byte the same. For the fission yields, ENDF/B-VII.0 gives as separate files; the Serpent version just concatenates them (running cat *.endf > sss_endfb7.nfy gives a file with the exact same size as the actual one). So, I think it would be more appropriate to call this script generate_endfb70_chain.py, and have it download the decay/fission yield sublibraries as some of the other scripts do. It looks like the original neutron data distributed with Serpent is also from ENDF/B-VII.0, so this script could get that data as well. I'm not sure what the difference would be between that and using ENDF/B-VII.1 data.
| if ev.gnd_name == "Co55": | ||
| # Fix negative uncertainty | ||
| sec = ev.section[8, 457] | ||
| ev.section[8, 457] = "0".join([sec[:762], sec[764:]]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this should be
| ev.section[8, 457] = "0".join([sec[:762], sec[764:]]) | |
| ev.section[8, 457] = " 0".join([sec[:762], sec[764:]]) |
no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure enough, there is a space in your comment as well. I was a little confused why a character was missing. Will fix that in the next iteration
| raise NotADirectoryError(neutron_dir) | ||
|
|
||
| if args.output.exists() and not args.output.is_file(): | ||
| raise IOError(f"{args.output} exists but is not a file") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IOError no longer exists (if you go to a Python prompt and type IOError, it will give you OSError)
| raise IOError(f"{args.output} exists but is not a file") | |
| raise OSError(f"{args.output} exists but is not a file") |
|
I think we could go about it two ways that would be, as you pointed out, identical. If the user wants to use the same files as provided by Serpent without the download, I think that should be supported. Alternatively, downloading the files also makes sense, as the data are identical. If anything, downloading the separate files would make processing the fission yield files less of a Would it make sense to :
I do think using the same neutron data as Serpent would be more consistent. What do you think about downloading the ENDF/B-VII.0 neutron data if the |
|
Yeah, I think just downloading the decay/fission product libraries is cleaner and avoids the TPID issue. I'm fine having the script download the VII.0 neutron data. A contrarian viewpoint -- instead of providing a way for users to use old/bad/wrong data in OpenMC, why don't we tell them to use ENDF/B-VII.1 decay/fission product libraries in Serpent if they really want to compare? Having just gone through this myself, it really is as simple as just concatenating the ENDF files and telling Serpent where to find them. |
|
Closing this in favor of the general script proposed in #23 |
Creates an equivalent depletion chain using decay and fission yield files distributed with Serpent. Some steps are taken to clean up and fix a few issues. The fixes are detailed in the script and here for completeness.
First, the files appear to be ENDF-6 formatted files concatenated together. Unfortunately, there is a TEND record after each dataset, so :func:
openmc.data.endf.get_evaluationswill only read and return the first evaluation. For this reason, we must read the file until all records have been found manually.Secondly, the decay file does not have a tape indent (TPID) record, which can throw off the first reading. This exception can be caught, but it currently involves skipping the first item in the file. At the time of this writing, this skipped item contains the decay data for a
neutron.
Lastly, there is a single negative uncertainty in the Co-55 k-shell conversion energies. This quantity is not used in the depletion chain, but it must be altered to prevent downstream failures.
Supports reading in an additional chain file and applying branching ratios prior to exiting.
Postscript
I am very open to suggestions on this. I tried making a fake decay file with a blank line at the top to get around
https://github.com/openmc-dev/openmc/blob/3f5373c71bd8331a18c61637214fb2372dcd47b3/openmc/data/endf.py#L408-L413
with out a lot of success.
Post-postscript
Also, the code is formatted with
blackwhich explains some of the lines with just closing parenthesis or single-argument lines.