Support pre-evaluated data in Chain.from_endf

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.

[drewejohnson]

Companion to the from_endf method, but acts on instances of Evaluation, Decay, and FissionProductYields objects. The from_endf method reads the appropriate files and passes the instances off to from_evaluation for internal processing.

This is the first part in what I hope will be a two PR process allowing users to create equivalent depletion chains to what Serpent uses. I'm working on a hackscript know that will come up later after some more development. The goal is that the script will produce the evaluations by reading the .dec and .nfy files that usually ship with Serpent, and then create chain using from_evaluations

Edit

The from_evaluations method has been removed. Instead, users can pass pre-evaluated Decay, FissionProductYields and/orEvaluation instances in place of file names

[paulromano]

Thanks for the enhancement @drewejohnson. In other places in the Python API, we have from_endf methods take either a str or an Evaluation instance (for example, look at IncidentNeutron.from_endf). To be consistent I think the best thing here would be to have a single from_endf method that takes either a list of str of a list of Evaluation. Would you be up for making that change?

[drewejohnson]

No problem @paulromano. I'll have that up shortly. Also, would the script for making an equivalent Serpent depletion chain be a good candidate for the scripts directory? Or something like the data repository?

[drewejohnson]

So it turns out that the Decay objects created from the decay file have some negative uncertainties in some of the discrete spectrum values. This causes the conversion to ufloat to fail. Specifically, I'm getting failures for cobalt 55 at

openmc/openmc/data/decay.py

Lines 430 to 432 in de99fae

	iflen(values) ==12:
	di['k_shell_conversion'] =ufloat(*values[8:10])
	di['l_shell_conversion'] =ufloat(*values[10:12])

This means that, at least for the Serpent decay file, we won't be able to pass Evaluations, as Decay(evaluation) fails.

I put together a MinimalDecay object that just contains information needed for depletion: half life, name, decay modes, and average decay energies. We can do some duck typing and pass in this object that has the information the chain method needs. With this, I can make this equivalent Chain.

I don't think changing how the Decay objects store data is worthwhile, but also having two decay-like classes could make refactoring and future changes tricky. Would love to hear your thoughts and suggestions

[paulromano]

@drewejohnson I'm generally trying to move those types of scripts over to the data repo, so feel free to put a PR there.

For the decay file that runs into trouble, which library is it from? I probably wouldn't be a huge fan of having a separate decay class to maintain. Perhaps we can just do a check for negative uncertainties, print a warning, and set them to zero?

[drewejohnson]

I'll put in a PR for my script in the data repo once we get this sorted. Otherwise the script may fail due to these reasons.

The cobalt 55 evaluation comes from 2005/2006 BNL distributions. I've provided the header below

 27-Co- 55 BNL EVAL-NOV05 A.A. Sonzogni (from ENSDF)
/ENSDF/ DIST-DEC06
----ENDF/B-VII MATERIAL 540
-----RADIOACTIVE DECAY DATA
------ENDF-6 FORMAT
*********************** Begin Description ***********************
** ENDF/B-VII RADIOACTIVE DECAY DATA FILE **
** Produced at the BNL from the ENSDF database **
** Authors: NSDD **
** Translated into ENDF format by A.A. Sonzogni, November 2005 **
*****************************************************************

One Decay class is surely best, agree. For the checks, what do you think about having some function in openmc.checkvalue that takes a value and uncertainty, and performs some checks? We could either set negative uncertainties to zero, or the absolute value. With some warnings. I think some of the library generation scripts make similar warnings anyway.

[paulromano]

Ok, so that Co55 decay file is from ENDF/B-VII.0. The one negative uncertainty is the only one that appears in the whole VII.0 library. In light of that, one possible alternative (we have done this in other places), is to have the processing/conversion script make a one-off modification of the offending evaluation and leave the main code in tact:

# Get evaluationsevals=openmc.data.endf.get_evaluations('endfb70')
# Fix negative uncertainty in Co55co55= [xforxinevalsifx.gnd_name='Co55'][0]
sec=co55.section[8, 457]
co55.section[8, 457] =sec[:762] +' 0'+sec[764:]
# Continue processingforxinevals:
dec=openmc.data.Decay(x)
...

For what it's worth, I consider it a feature that things fail when the data is clearly wrong (rather than letting it silently pass). I can't tell you how many evaluation bugs I've reported to ENDF and JEFF because of this behavior.

[drewejohnson]

Agree, catching these errors is useful. I guess if / when control over these uncertainties is added (set zero, set absolute, etc.) some options for warning / error control would be nice. But that is for a later PR.

For this, I will re-work the Chain implementation to string file names or Evaluation instances. This should play well with the conversion script.

Thanks for looking into the ENDF data! 💯

[paulromano]

Thanks for iterating on this @drewejohnson.