When trying to process Pa233 from ENDF/B-VIII.0, which has a threshold fission
reaction, I discovered that calculating heating numbers crashed because we were
trying to do arithmetic on arrays of different sizes. Re-evaluting the fission
cross section on the proper energy grid does the trick here.
New member functions openmc::Tally.set_writable and get_writable
act on the writable attribute. These are used in the external
API with openmc_tally_set_writable and openmc_tally_get_writable
functions.
Cleaned up some other writeable -> writable typos as well
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
Tallies created by internal depletion helpers are marked
as internal using the openmc.lib.Tally.writeable property.
This is done to resolve issue #1327 where statepoint files could
grow to be quite large after tallying reaction rates across many
burnable materials for all nuclides of interest.
A check is added in the depletion regression test to ensure that
no additional tallies are loaded to the StatePoint.
Add two functions to capi.h:
openmc_tally_set_writeable and openmc_tally_get_writeable
which are exposed to the Python API through the
openmc.lib.Tally.writeable property. These functions are very
similar to the set/get active counterparts as both act on a boolean
Tally attribute
A new unit test test_tally_writeable has been added that toggles
the writeable state of a tally. It is important to note that the
writeable state must be reset, otherwise tallies in subsequent
tests will be skewed. This is because the test_tally_writeable
function requires the capi_simulation_init fixture and the tallies
are shared by those functions that use the capi_run fixture
When reading in tally data from a statepoint file, a check
is performed on the "internal" attribute of the tally group.
If the attribute doesn't exist (previous statepoint files), then
it is assumed that the tally is writeable / not internal. Otherwise,
the internal attribute is read from the dataset.
If the tally is determined to be internal, the value of
tally.writeable_ is set to false and no tally data
is read
If a tally is marked as not writeable, a tally group
will still be added to the statepoint file. However,
no filter, score, nuclide, or results data will be written to
this tally group. A new attribute is introduced to this tally
group "internal" that is an integer flag: 0 if the tally
is not internal (i.e. is writeable) and 1 if the tally is
internal (i.e. is not writeable).
The internal attribute has been added to the statepoint
io format in the documentation.
Other changes: use
```
const auto& tally : model::tallies
tally->X
```
to iterate over tallies during the writing process
CRAM16 and CRAM48 are now aliases for __call__ methods
on two new classes: openmc.deplete.cram.Cram16Solver
and Cram48Solver. These are two concrete subclasses of
openmc.deplete.abc.IPFCramSolver and
openmc.deplete.abc.DepSystemSolver abstract classes.
The primary benefit of the class based approach is that the
16th and 48th order have nearly identical implementations. The only
differences are the alpha, theta, and alpha_0 coefficients used.
This allows both the Cram16Solver and Cram48Solver to have unique
sets of coefficient vectors, while relying on the IPFSolver base
class implementation.
The implementation of IPF CRAM has been cleaned up. The NxN identity
matrix is not re-created each iteration. Given the alpha and
theta attributes on the IPFCramSolver instances, one can
iterate through the orders using a zip command. By forcing concrete
classes to declared alpha and theta vectors, the need to re-declare
the vectors at each entrance into CRAM48 is also removed.
Using these classes, a 10% speedup is observed depleting up to 500
materials on a single MPI process. The function-based approach
took 62s, while the new classes required 52s.
Potential over-depletion using the fission-q
energy deposition mode and some remedies.
Repeated burnable materials are depleted as a single material
unless diff_burnable_mats=True is given to the Operator
Boolean flag that indicates if a tally should be written to
output files. This has no effect on tally scoring, but instead
will be used to skip writing Tally data for those not marked
as writeable.
Related to #1327 as the depletion interface will use this flag
to reduce time spent writing reaction rate tallies and also
reducing the size of the final statepoint files
