Moved from deplete.abc into openmc.deplete.cram. CRAM16 and CRAM48
are aliases to __call__ methods for two instances of
IPFCramSolver: Cram16Solver and Cram48Solver, created using
16th and 48th order coefficients
Slight reformatting of the depletion documentation. The "Primary API"
is presented at the top, including integrators and the Operator.
This section is followed by a "Minimal Example" that demonstrates
how one might instantiate an Operator, and use it for depletion.
The comm communicator is moved into the "Internal Classes and Functions"
section, as the end-user is less likely to interact with this directly.
Lastly, a section on "Abstract Base Classes" is provided and expanded,
documenting the purpose of specific ABCs.
* __call__ methods for Operator documented
* CRAM16 and CRAM48 are closer to the top of the page
* Document deplete and timed_deplete functions
* Abstract integrators documented as part of abc submodule
* Abstract operator helpers documented as part of abc submodule
Introduce a new subclass of EnergyHelper, EnergyScoreHelper,
that computes the system energy using the energy-deposition score.
This energy is fed back to the Operator to normalize reaction rates.
The energy from the tally is only stored on the helper on the
MPI process 0 as to avoid scaling the system energy by the number
of processes. During the Operator unpacking, the energy reported
by each process is reduced, as the previous implementations took
fission reaction rates from the "local materials", e.g. the
materials each process is responsible for depleting.
The tally results are shared across all processes and only
contains a single quantity, the tallied energy deposition across
all materials.
This mode is controlled by passing the "energy_mode" argument passed
to the Operator. The two options are "fission-q" [default and previous
behavior] and "energy-deposition" [new features]. If energy_mode indicates using
the energy deposition score, the user-supplied fission-q dictionary is not used.
(cherry picked from commit d566f3080f)
Computes the effective fission yields for nuclides
with multiple sets of yields by
1) Tallying fission rate and energy-weighted fission rate
2) Determining average energy at which fission events occur
3) Interpolating [lin-lin] between adjacent fission yields based
on this average energy
Uses a second tally with an EnergyFunctionFilter to tally
E * sigma_f * phi.
Added unit tests with the proxy-style class that doesn't use the
C API to generate tallies but tests all other aspects of the
implementation. Tests cover three possible average energies
(below minimum supplied yield energy, above max supplied yield energy,
and between two)
The Operator uses fission_yield_mode="average" to select this helper.
The helper also has a from_operator class method.
This helper performs the following tasks to weight fission yields:
1) Determine a set of "fast" and "thermal" yields
based on a user specified cutoff energy,
2) Tally fission rates above and below the cutoff, and
3) Compute the effective yield by weighting the fast and
thermal yields by the fraction of fast and thermal fissions
for all nuclides in all burnable materials.
The user is allowed to specify the cutoff energy and energies
preferred for the fast and thermal yields. By default, the
cutoff is 112 eV, chosen as it is the logarithmic mean of
0.0253 eV and 500 keV. These two values are the default energies
for thermal and fast yields.
Tests are added to check for failure in constructing this
helper (thermal energy > cutoff, non-real values passed, etc.),
selection of yields given a range of user data, and
a proxy class that emulates a variety of thermal and fast splits
to check the eventual computed yield libraries.
Designed to be subclassed by helpers that aim to compute
effective fission yields with tallied data.
Constructs a tally in all burnable materials, scoring the
fission rate in all nuclides that have non-zero density
(as reported by the Operator) and have multiple sets of yields.
For nuclides with non-zero densities and a single set of
yields, those yields are assumed to be constant across incident
neutron energies.
The unpack method is now abstract, as each subclass should have
its own data layout, some with different energy structures
perhaps?? Maybe some weighting functions?
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.
API used by the Operator:
- generate_tallies
- weighted_yields [abstract]
- update_nuclides_from_operator
- unpack
generate_tallies and unpack are empty methods, provided
so that a consistent API can be found on helpers
with tallies.
Sorts nuclides into two dictionaries: those with a single
set of fission yields, and those with multiple sets.
The former can is exposed through the
constant_yields property, returning a copy of the fission
yield dictionary {parent: {product: yield}}
The Operator now looks for/uses the weighted_yields and
update_nuclides_from_operator methods instead of the old
compute_yields and set_fissionable_nuclides methods
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
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.
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
Addressing comments in review for #1278
- Documentation cleanup
- Better naming convention regarding ReactionRateHelper
results cache
- The power in Operator tally unpacking and normalizing is
no longer converted to eV/s, since the EnergyHelper.energy
property is now returned in J/s/source neutron
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()
The cecm function has been removed from the python api.
In order to use the cecm integration scheme,
the following class based approach is now expected:
>>> from openmc.deplete import CECMIntegrator
>>> cecm = CECMIntegrator(operator, timesteps, power)
>>> cecm.integrate()
if the integrator is not needed, this above expression can be
one-lined with
>>> CECMIntegrator(operator, timesteps, power).integrate()
Unit tests have been updated to no longer use the cecm function,
and cecm has been removed from documentation.
The CECMIntegrator has been added to documentation.
