The size of the Operator.reaction_rates does not change through
depletion, but the number of tallied nuclides for reaction
rates may or may not. The DirectReactionRateHelper returns
reaction rates according to the number of nuclides tallied,
a potential subset of all nuclides designated as burnable
by the Operator. This causes IndexErrors if a nuclide is not
tallied at a later step.
Example: 10 nuclides [0-9] are originally tracked by the Operator
and tallied by DirectReactionRateHelper. The Operator.reaction_rates
array will be of shape (n_mat, 10, n_react). Initially, the
DirectReactionRateHelper returns an array of size (10, n_react)
for each material. Then, if nuclide 5 is not in the list of nuclides
passed to the DirectReactionRateHelper at the next step, [decayed to
zero], DirectReactionRateHelper will return an array (9, n_react) and
try to pass tally data for nuclide 9 into row 9 of the reaction rate
array, causing an IndexError.
This commit instructs requires two integers, n_nucs and n_react, to be
passed to the initialization of any ReactionRateHelper, allocating
a single array for storing material-reaction rates. The method
get_material_rates uses this directly and does not re-allocate storage
if len(nuc_index) has changed [like if nuclide 9 has dropped out].
Users can now pass dilute_initial as an input
argument into the Operator, and directly set
Operator.dilute_initial. Documentation was updated to
include units on the initial default concentration, which
is 1000 atoms per cubic centimeter. The user is allowed
to set this value to zero.
Notes have been added to ResultsList.get_atoms
and get_reaction_rate methods, indicating why there may
be non-zero values when pulling data for isotopes not
initially present.
A similar note was added to the depletion_results.h5
io format file.
Closes#1288
Accessing cell/material names through accessor. Returning a const reference from `name()` accessor in both cases.
Co-Authored-By: Paul Romano <paul.k.romano@gmail.com>
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
All of the integrators pull the previous concentration and
operator results from a restart file in the same way, but vary
in how subsequent steps are handled. The predictor saves data
here, while the SIE-based methods scale and reset the particles
used. To this end, the _get_bos_data function has been broken into
two methods: one for calling the operator and one for pulling from
a restart file.
EnergyHelper (was FissionEnergyHelper) has a new
``update`` method that replaces get_energy. This method
is no longer abstract and defaults to not performing any actions.
This works in conjunction with a new private ``_energy`` atribute
and ``reset`` method to streamline the energy normalization procedure.
For the current concrete ChainFissionHelper class, the reset method
sets _energy to zero, while the update method updates the energy
with the dot product fission_rates X fission_q_vector.
The total energy produced is made accessible, but not publically
writable with an energy property. After cycling through all
local materials on an operator, the total system energy is computed
by
energy = comm.allreduce(self._energy_helper.energy)
For a concrete class where the system energy is computed via tallies
and not with Q-values, the update methods could continue to do
nothing. The total system energy could be stored either in the
reset method or returned directly from the energy attribute/property.
