armi.bookkeeping.db package

The db package is responsible for reading and writing the state of the reactor to/from disk.

As an ARMI run progresses, this is periodically updated as the primary output file. It can also be an input file for follow-on analysis or restart runs.

This module contains factories for selecting and building DB-related objects.

When updating a db version

The code associated with reading and writing database files may not benefit from Don’t Repeat Yourself (DRY) practices in the same way as other code. Therefore, do not share code between different major versions of the databases. Create a new module if you are creating a new major database version.

Database revision changelog

  • 1: Originally, calculation results were stored in a SQL database.

  • 2: The storage format was changed to HDF5. This required less external infrastructure than SQL. However, the implementation did not store a complete model of a reactor, but a ghost of assembly, block, and reactor parameters that could be applied to an existing reactor model (so long as the dimensions were consistent). This was inconvenient and error prone.

  • 3: The HDF5 format was kept, but the schema was made more flexible to permit storing the entire reactor model. All objects in the ARMI Composite Model are written to the database, and the model can be completely recovered from just the HDF5 file.

    • 3.1: Improved the handling of reading/writing grids.

    • 3.2: Changed the strategy for storing large attributes to using a special string starting with an “@” symbol (e.g., “@/c00n00/attrs/5_linkedDims”). This was done to support copying time node datasets from one file to another without invalidating the references. Support was maintained for reading previous versions, by performing a mergeHistory() and converting to the new naming strategy, but the old version cannot be written.

    • 3.3: Compressed the way locations are stored in the database and allow MultiIndex locations to be read and written.

    • 3.4: Modified the way locations are stored in the database to include complete indices for indices that can be composed from multiple grids. Having complete indices allows for more efficient means of extracting information based on location, without having to compose the full model.

armi.bookkeeping.db.loadOperator(pathToDb, loadCycle, loadNode, statePointName=None, allowMissing=False, handleInvalids=True)[source]

Return an operator given the path to a database.

Parameters:

  • pathToDb (str) – The path of the database to load from.

  • loadCycle (int) – The cycle to load the reactor state from.

  • loadNode (int) – The time node to load the reactor from.

  • statePointName (str) – State point name at the end, E.G. EOC or EOL. Full name would be C0N2EOC, see database.getH5GroupName

  • allowMissing (bool) – Whether to emit a warning, rather than crash if reading a database with undefined parameters. Default False.

  • handleInvalids (bool) – Whether to check for invalid settings. Default True.

See also

armi.operator.Operator.loadState

A method for loading reactor state that is useful if you already have an operator and a reactor object. loadOperator varies in that it supplies these given only a database file. loadState should be used if you are in the middle of an ARMI calculation and need load a different time step.

Notes

The operator will have a reactor attached that is loaded to the specified cycle and node. The operator will not be in the same state that it was at that cycle and node, only the reactor.

Examples

>>> o = db.loadOperator(r"pathToDatabase", 0, 1)
>>> r = o.r
>>> cs = o.cs
>>> r.p.timeNode
1
>>> r.getFPMass()  # Note since it is loaded from step 1 there are fission products.
12345.67

Subpackages

Submodules