The Chain.form_matrix method looks for information and
fission yields for all isotopes with a fission reaction.
However, the AveragedFissionYieldHelper and FissionYieldCutoffHelper
are not guaranteed to return yields to all isotopes with
fission reactions. Instead, the union on two sets of yields
are returned:
1) yields from isotopes with a single set of fission yields
2) weighted yields computed for isotopes with both multiple sets of
fission yields **and** non-zero densities.
This later item can cause some isotopes that the Chain anticipates
having fission yields, since they have a fission reaction, to not
exist in the yields library. An isotope with multiple sets of
yields but that is not physically present in the problem will not
have reaction rates and also not have fission yields computed
by these helpers. This will cause a KeyError during Chain.form_matrix
when fission yields for these isotopes are requested.
This commit changes the return type from weighted_yields on
ConstantFissionYieldHelper, AveragedFissionYieldHelper, and
FissionYieldCutoffHelper to be defaultdict(dict). This resolves
the above issue by returning an "empty" set of yields for isotopes
that potentially *should* have fission yields, but have zero density
across the problem, and therefore do not have tallied reaction
rates nor fission yields.
Documentation for the changes to these classes have been updated
The fission heating data generated with IncidentNeutron.from_njoy
does not have the same energy grid as other reactions. Previously,
the energy grid was maintained and the non-fission heating was generated
by evaluating total heating at each point in the fission heating grid
and taking total_xs(fission_h.x) - fission_h.y
This led to the crash in #1340 where openmc expected cross
sections to use the same grid, or at least same number of grid
points when computing the total cross section. While fission heating
is not included in the total cross section [since 71825fb35],
a consistent energy grid is helpful.
Both fission heating and non-fission heating now use the energy
grid from the total heating.
Fission heating should not contribute to total cross section,
and marking the reaction as redundant ensures this. MT=318 for
fission heating is already included in the redundant reactions
to keep when exported to HDF5
Related to #1340
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.
Passing ace to make_ace is not supported. Use acer instead.
The acer argument now signals if the acer njoy module should
be run and where to save the output file. xsdir defaults to
None now, rather than "xsdir". This change allows the xsdir
file to be written to the same directory as acer, or a user
supplied location potentially separate from ace file.
openmc.deplete.cram.deplete now pre-generates a map object
that produces depletion matrices given the chain, rates,
and matrix_func. The internal cram wrapper function has
been removed, as the full inputs to CRAM48 are now known,
in zipped and mapped objects.
Some basic timing comparisons indicate that this approach
is at least as fast, if not marginally faster, for a
quarter PWR assembly and an SFR assembly.
Neutron heating logic has been pulled out from the main
score_general_ce function into a single helper function
score_neutron_heating. This function returns a double that is
the neutron heating, using analog, collision, or track-length
estimators, incorporating survival biasing, and the possiblity
of scoring across all nuclides in a given material.
The functionality is identical to the original implementation,
just condensed into two functions to reduce repeated code. The second
helper function digs through neutron data to obtain and interpolate
kerma coefficients for a given nuclide and reaction.
