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
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.
Provide explicit __all__ lists for files in openmc/deplete
containing classes that should be brought into the "primary"
API. This prevents cluttering the openmc.deplete namespace
caused by the wildcard imports
```
from .nuclide import *
...
```
The abc, cram, and helpers modules are imported simply as
```
from . import abc
from . import cram
from . import helpers
```
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.
If the fission yields are a single entry, then
itertools.repeat is used to apply the fission yields to all
burnable materials. Otherwise, check that the number of
fission yield libraries is equal to the number of materials
to be burned.
Takes a single set of fission yields and passes them as
an additional argument to matrix_func:
>>> A = matrix_func(chain, rates, fission_yields)
Applied to cf4, epc_rk4, celi, and leqi functions.
Assumes that fission yields will not change during a
depletion event. This change is probably overshadowed
by how much the reaction rates may change, but still worth
pointing out.
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
2019-08-07 11:04:37 -05:00
Renamed from openmc/deplete/integrator/cram.py (Browse further)
