armi.bookkeeping.db.xtviewDB module¶
The old database implementation, which XTView still knows how to read.
Until XTView is updated to speak the new database format, this will need to be maintained to allow conversions between database formats and visualization.
-
class
armi.bookkeeping.db.xtviewDB.XTViewDatabase(fName, permission)[source]¶ Bases:
objectThe contract interface class for database subclasses
Please be aware that decorated parent class methods lose their decoration when overridden (unless directly invoked).
Lowest level of common attributes between database implementors
- Parameters
permission (tuple of string value and set containing accepted strings) –
-
version= '2'¶
-
__exit__(_type, _value, _traceback)[source]¶ Typically we don’t care why it broke but we want the DB to close
-
__del__()[source]¶ Unreliable trash collection behavior to try to ensure disconnecting works
When possible use the context management __enter__ and __exit__ which are better guarantees.
-
writeToDB(reactor, statePointName=None)[source]¶ Puts self.r in the database.
- Parameters
statePointName (str, optional) – explicit name of the state point to be written. A state point is not necessarily a cycle or time node, it may make the most sense to simply think of it as a label for the current state.
-
writeInputsToDB(cs, csString=None, geomString=None, bpString=None)[source]¶ Write inputs into the database based the CaseSettings.
This is not DRY on purpose. The goal is that any particular Database implementation should be very stable, so we dont want it to be easy to change one Database implementation’s behavior when trying to change another’s.
Notes
This is hard-coded to read the entire file contents into memory and write that directly into the database. We could have the cs/blueprints/geom write to a string, however the ARMI log file contains a hash of each files’ contents. In the future, we will be able to reproduce calculation showing that the inputs are identical.
-
updateFromDB(reactor, dbTimeStep, updateIndividualAssemblyNumbers=True)[source]¶ Reads in the state from the database
Performs necessary schema loads on the data to get it integrated in properly. Meaning several things: * Reads each block param from the DB and sets each block to the
corresponding value
Reads each reactor param from the DB and sets them
Handles some special params like b.p.type, b.p.assemType, and xsTypeNum to actually set the types
Applies the temperatures from the DB to the components in the blocks, updating the thermal expansion, etc.
Sets the number densities of all nXXX-type parameters, updating the component mass fractions
Updates assembly-level parameters like maxpercentBu
Updates block heights and makes sure all assemblies are consistent heights.
- Parameters
reactor (reactor object) – The ARMI reactor to update from current db
dbTimeStep (int) – The timestep (starting at 0) to load from db
updateIndividualAssemblyNumbers (bool, optional) – If True, will update assembly numbers of all assemblies on loading. This in turn affects their name. Turn this off if you are analyzing previous timesteps of a run (such as EOL safety) so you don’t interfere with assemblies that are already in the SFP.
- Raises
ValueError – If the requested time step is not present in the database, or if some parameters cannot be processed correctly
-
property
numberDensityParamNames¶ Return a set containing the number density parameter definition names
-
lookupGeometry()[source]¶ Read the order that block data is stored in BLOBs from the database
- Returns
locationList – List of location strings in the order that block params are packed into BLOBs
- Return type
list
-
property
name¶