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)
The basic structure is borrowed from examples/python/pincell_depletion/
and builds a single pin cell to be depleted. The model building is
expedited, as this assumes the user has read through the
basic user guide on model building. The new openmc.model.pin
function is highlighted, both for building a plain pin
and for subdividing regions for depletion.
The Chain and Operator classes are the focuses of the example,
and the PredictorIntegrator is used to deplete the pin out to
6 months using 30 day depletion steps with 174 W power.
The openmc-make-depletion-chain scripts are introduced as methods
for building initial depletion chains. Use of
openmc.data.DataLibrary.register_file is included, as this allows
the user to not pass the chain_file argument if the depletion chain
is included in OPENMC_CROSS_SECTIONS.
The jupyter notebook is included in the documentation similar
to other examples.
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.
