Skip to content

Conversation

@drewejohnson
Copy link
Contributor

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.

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 black which explains some of the lines with just closing parenthesis or single-argument lines.

shimwell and others added 2 commits January 19, 2020 21:41
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.
Copy link
Contributor

@paulromano paulromano left a 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:]])
Copy link
Contributor

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

Suggested change
ev.section[8, 457] = "0".join([sec[:762], sec[764:]])
ev.section[8, 457] = " 0".join([sec[:762], sec[764:]])

no?

Copy link
Contributor Author

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")
Copy link
Contributor

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)

Suggested change
raise IOError(f"{args.output} exists but is not a file")
raise OSError(f"{args.output} exists but is not a file")

@drewejohnson
Copy link
Contributor Author

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 hackworkaround.

Would it make sense to :

  1. accept a decay file, downloading ENDF/B-VII.0 data if not given, and
  2. accept a fission yield file, downloading ENDF/B-VII.0 data if not given

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 neutron_dir argument is not provided?

@paulromano
Copy link
Contributor

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.

@drewejohnson
Copy link
Contributor Author

Closing this in favor of the general script proposed in #23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants