Given a requested energy, will take fission yields from that
energy on all nuclides and hold them as constant throughout
the simulation. If the requested energy is not found for a specific
nuclide, then the closest energy is used. The default is to
take the thermal 0.0253 eV yields.
This is now the helper attached to the Operator. The user can
select what energy of yields they would like to use.
Closes#1308 by providing a way to validate the contents of
the depletion chain. This method iterates over all the nuclides
and calls their validation method with the same input arguments,
(strict, quiet, and tolerance). For the case where
strict == False, quiet == False, and a nuclide fails the validation,
the method returns early rather than continuing to iterate over all
other nuclides. Type and value checking are also done on the
tolerance argument.
Two tests were added to test_deplete_chain.py
The more interesting test works with the simple chain and various
manipulations to check the robustness of the method.
The other just checks the type and value checking on tolerance.
Method Nuclide.validate traverses over decay mode and reaction lists,
as well as all fission yield data to check for inconsistencies.
The following checks are performed:
1) For all non-fission reactions and decay modes, do the sum of
branching ratios equal about 1?
2) For fission reactions, do the sum of fission yield
fractions equal about 2?
Users are allowed to supply three control arguments:
- strict: bool that controls if errors are raised [True] or
warnings [False]
- quiet: bool that controls if warnings are printed [False] or
supressed [True]
- tolerance: float that provides some wiggle room on the comparisons
``y - tol <= x <= y + tol``
The method returns a boolean if 1) no inconsistencies were found and
strict evaluates to True, 2) strict evaluates to False regardless of
quiet. If ``strict`` evaluates to False and ``quiet``
evaluates to True, the method will return at the first inconsistency.
No type checking is done because this will potentially be called
by ``openmc.deplete.Chain`` for many nuclides as the primary
entry point. Type and value checking will be done there.
A unit test was added that creates a valid nuclide, and then
strategically invalidates it to check for the various exceptions
and error messages.
Previously the yields were appended into the libraries
attribute. Now, the yields are returned directly and not
appended at all. It is up to the caller to place these yields
in the correct location.
The Operator maintains a list of of the libraries that is updated
through the unpacking method, and then set onto the Chain
after working through all local materials
Create an empty matrix to fit energy-dependent fission
rates for [materials, energies, nuclides].
Use the nonzero method on total fission rate to find
indicies along the first and last axis for non-zero total
fission rate. Populate corresponding fractional fission
rates by dividing group fission rates by total fission rate,
using the indices for materials and nuclides with non-zero
total fission rate.
Use numpy.where to find where total fission rate is zero,
and directly set these locations to zero in the final
result matrix.
Also clean up some lint in openmc.deplete.nuclide related to
old variable names and unused imports.
Operator now has a new helper for tallying fission rates
and computing fission yields using energy dependency.
The FissionYieldHelper creates fission rate tallies across
burnable materials with an energy filter. The energy filter
corresponds to each energy group for which there are fission
yields.
During the operator's unpacking of tallies, this helper
computes a relative fission contribution by normalizing
fission rates, such that the sum of all group fission rates
in each material and each nuclide is unity.
A single fission yield for each parent nuclide is computed
by weighting the energy-dependent fission yields by
these relative contributions.
A nested dictionary {parent: {product: yield}} is added to
a library, and then attached to the depletion chain
at the end of the unpacking. These libraries are used
during the depletion process instead of the only-thermal
yields from before.
A test was added that creates a proxy helper that doesn't
use the C-API, but unpacks the "fission tally" and
computes the fission yield library in an identical manner
as the actual class. Since the proxy helper is a subclass
of the one used in real transport, the functionality
is consistent.
Add two new classes for working with fission yield data
on the Chain. The primary class is FissionYieldDistribution.
This class stores distributions for one nuclide with
potentially many energies, with the assumption that the
products don't change __too__ much across energy.
Looking at the CASL chain and one generated by ENDF data,
this appears to be the case. Most distributions are
"full" in the sense that energies produce the same products.
There are some cases where one or two products may not
exist for a given energy.
The FissionYieldDistribution retains a dictionary-like behavior,
e.g. d[0.0253]["Xe135"] is a valid command and returns the
yield for Xe-135 at a "thermal" spectrum, due to yields provided
at 0.0253 eV. This is done with a helper class, _FissionYield,
implemented first to support this behavior, but also to
allow vector-operations in combining fission yields.
These _FissionYield objects store the same product vector and
a view into the underlying yield_matrix for a single energy.
To support simple weighting of yields, the __mull__ and
__iadd__ methods are implemented. A copy method is provided
to remove the chance of modifying the original yield data.
test_deplete_chain and test_deplete_nuclide have been modified
in order to utilize these classes, without ruining the validity
of the tests. Tests for the view / copy methods and vector
operations on _FissionYield objects are included.
In support of using energy dependent fission yields, this
commit allows a dictionary of fission yields to be passed
into Chain.form_matrix. The dictionary is expected to
be of the form
{source_name: {target_name: yield_fraction}}
where source_name and target_name are string GND names
for fissionable nuclide and fission yield products, respectively.
Currently, the fission yield dictionary does not have to be passed,
defaulting to using the thermal yield values. This is done to
make testing easier, and for back compatability. The goal of this
feature, however, is to pass material [and thus spectrum] specific
yields into this method.
The test test_deplete_chain::test_form_matrix has been modified
to pass the exact fission yield dictionary into Chain.form_matrix.
The resulting matrix is compared against the matrix when
no yields are passed.
Much of the previous API is intact, with the major change
being CRAM functions are imported from openmc.deplete.cram
in the test_deplete_cram.
The integrator abstract classes are placed in
openmc/deplete/abc.py with all concrete classes going in to
openmc/deplete/integrators.py
Documentation updated accordingly
Called with a single integer corresponding to the current
depletion step. This method is intended to document the current
beginning-of-step calculations prior to any depletion at each step
and at the final simulation.
The Operator uses this method to write a statepoint using the
C API.
Also rename the Integrator _get_bos_data_from_openmc to
_get_bos_data_from_operator for generality. It is here that the
write_bos_data method is called.
The new class method ResultsList.from_hdf5 should be
used to load in results data, rather than passing
the file name into the __init__ method. __init__
passes directly to list.__init__ now.
The motivation for this is to resolve the depletion
restart with MPI bug #1275. To do this, each Operator
will create it's own ResultsList and distribute reaction
rates and densities according to what materials are burned
on this process. Rather than use a normal list, this Operator
expects the various accessor methods like get_atoms to be
present on self.prev_res
- SI_Integrator must be passed positive integer.
- Number of powers computed must be equal to the
number of time steps
Added unit test to ensure that the right errors are raised.
Each scheme is capable of different amounts of concentration
and reaction data, depending on the number of intermediate
transport solutions of interest. The PredictorIntegrator
stores data from a single solution, while the CF4Integrator and
EPC_RK4_Integrator store four stages. This discrepancy can cause
issues when saving data in the depletion output file, as
either some data is calculated and thrown away [more stages going
to fewer stages] or excess space is not utilized [fewer stages
going in to a restart that previously used more stages].
Each subclass of Integrator is expected to declare a
_N_STAGES attribute that provides information on the number of
stages expected. Iterative schemes like SI_CELI_Integrator
only report two stages, for the initial concentration and
first prediction, rather than at each iteration point.
Logic that checks for consistent sizes is included in the
initialization of the Integrators, and has been removed
from Results.save
Add three functions that can be used to modify EnergyFunctionFilters
through the C-API:
- openmc_energyfunc_filter_set_data: set energy and y data
- openmc_energyfunc_filter_get_energy: obtain energies used in
interpolation
- openmc_energyfunc_filter_get_y: obtain ordinate values
These functions are modeled after openmc_energy_filter_[get|set]_bins.
The set_data function relies upon the new
EnergyFunctionFilter::set_data function, which is analogous
to EnergyFilter::set_bins function. Checks are performed
to make sure the energy and ordinate vectors are of equal
size before resetting and populating energy and y
private members.
An EnergyFunctionFilter did exist in openmc.capi, and has
now been flushed out to provide a better __init__ method,
as well as properties for retrieving energies and ordinates
for interpolation.
Many repetitions of the following change:
- assert y1[3] == approx(s2[0])
- assert y2[3] == approx(s2[1])
+ assert y1[2] == approx(s2[0])
+ assert y2[2] == approx(s2[1])
This causes many of the restart tests to fail, because all
schemes but the predictor save repeated data under restart conditions.
Performing one normal depletion event, non-restarted, and then
one restart event, as these tests do, should produce vectors for
time and densities like:
t = [t0, t1, t2]
a = [a0, a1, a2]
| ^ after restart
^ non-restart run
With this, the current tests would fail due to an IndexError, as
the atom vectors should only have three elements. Instead,
non-predictor schemes return vectors
t = [t0, t1, t1, t2]
a = [a0, a1, a1, a2]
and one can access a[3] to obtain the desired EOS concentrations.
The depletion function openmc.deplete.si_leqi has been
removed in favor of the SI_LEQI_Integrator class. The same
depletion scheme can be obtained with the following commands:
>>> leqi = openmc.deplete.SI_LEQI_Integrator(operator, dt, power)
>>> leqi.integrate()
The expression can be onlined for compactness.
The si_celi_inner function has been removed completely now,
as the SI_CELI iteration is performed by directly calling
SI_CELI_Integrator.__call__ through the SI_LEQI_Integrator.
This is similar to how the LEQIIntegrator handles the initial steps.
Tests have been updated to use this class, and the class has been
added to the documentation. No pure-function integration
schemes exist anymore.
The si_celi depletion function has been removed. The
SI-CELI method can be implemented with
>>> from openmc.deplete import SI_CELI_Integrator
>>> SI_CELI_Integrator(op, dt, power, stages).integrate()
The stages parameter is optional, and defaults to 10 to
be consistent with the previous default for si_celi.
The SI_CELI_Integrator inherits from the new abstract base class
SI_Integrator. There are a few differences in how the SI-based
methods perform the integration.
- The initial, t=0.0, i=0, no restart transport solution is scaled
by the number of stages.
- The SI methods also do not perform a new transport solution at
each successive iteration [t>0, i>0]. Instead, the reaction
rates are pulled from the last stage of the previous step.
- There is no final transport solution once all the depletion
steps have been taken. The final reaction rates are saved as
those from the last stage of the last depletion step.
The si_celi function has been removed from documentation and testing,
and replaced with the SI_CELI_Integrator.
This allows the propagation of the uncertainty through
the SIE iterations, and alows the expressions for updating
k to be preserved. The OperatorResult.k was previous stored
as a tuple of two floats. The interface into the depletion_results
file is not changed, as the Results.save method, which writes the
OperatorResult data, breaks the ufloat into k and uncertainties.
Documentation has been updated on the OperatorResult.
The function openmc.deplete.epc_rk4 has been removed
in favor of openmc.deplete.EPC_RK4_Integrator. The scheme
can be used with::
>>> from openmc.deplete import EPC_RK4_Integrator
>>> EPC_RK4_Integrator(op, dt, power).integrate()
epc_rk4 has been removed from the documentation, and the
EPC_RK4_Integrator class has been added to the depletion
API documentation
The function openmc.deplete.cf4 has been removed in favor
of openmc.deplete.CF4Integrator. The CF4 integration scheme
can be peformed with
>>> from openmc.deplete import CF4Integrator
>>> CF4Integrator(operator, time, power).integrate()
The depletion functions openmc.deplete.celi and
openmc.deplete.leqi hvae been removed in favor of a class-based
approach. The following syntax will replicate the behavior
of the integration schemes:
>>> from openmc.deplete import CELIIntegrator
>>> celi = CELIIntegrator(operator, time, power)
>>> celi.integrate()
The expression can be reduced to a single line:
>>> LEQIIntegrator(operator, time, power).integrate()
The depletion function openmc.deplete.predictor has been removed
in favor of a class-based approach. The following syntax will
replicate the behavior of the predictor integration scheme:
>>> from openmc.deplete import PredictorIntegrator
>>> predictor = PredictorIntegrator(operator, time, power)
>>> predictor.integrate()`
The expression can be reduced to a single line:
>>> PredictorIntegrator(operator, time, power).integrate()
