armi.cases.case module¶
The Case
object is responsible for running, and executing a set of user inputs. Many
entry points redirect into Case
methods, such as clone
, compare
, and run
.
The Case
object provides an abstraction around ARMI inputs to allow for manipulation and
collection of cases.
See also
armi.cases.suite
A collection of Cases
- class armi.cases.case.Case(cs, caseSuite=None, bp=None, geom=None)[source]¶
Bases:
object
An ARMI Case that can be used for suite set up and post-analysis.
A Case is capable of loading inputs, checking that they are valid, and initializing a reactor model. Cases can also compare against other cases and be collected into multiple
armi.cases.suite.CaseSuite
Initialize a Case from user input.
- Parameters
cs (CaseSettings) – CaseSettings for this Case
caseSuite (CaseSuite, optional) – CaseSuite this particular case belongs. Passing this in allows dependency tracking across the other cases (e.g. if one case uses the output of another as input, as happens in in-use testing for reactivity coefficient snapshot testing or more complex analysis sequences).
bp (Blueprints, optional) –
armi.reactor.blueprints.Blueprints
object containing the assembly definitions and other information. If not supplied, it will be loaded from thecs
as needed.geom (SystemLayoutInput, optional) – SystemLayoutInput for this case. If not supplied, it will be loaded from the
cs
as needed.
- property independentVariables¶
Get dictionary of independent variables and their values.
This unpacks independent variables from the cs object’s independentVariables setting the first time it is run. This is used in parameter sweeps.
See also
writeInputs
writes the
independentVariabls
setting
- property bp¶
Blueprint object for this case.
Notes
This property allows lazy loading.
- property geom¶
Geometry object for this Case.
Notes
This property allows lazy loading.
- property dependencies¶
Get a list of parent Case objects.
Notes
This is performed on demand so that if someone changes the underlying Settings, the case will reflect the correct dependencies. As a result, if this is being done iteratively, you may want to cache it somehow (in a dict?).
Ideally, this should not be the responsibility of the Case, but rather the suite!
- addExplicitDependency(case)[source]¶
Register an explicit dependency.
When evaluating the
dependency
property, dynamic dependencies are probed using the current case settings and plugin hooks. Sometimes, it is necessary to impose dependencies that are not expressed through settings and hooks. This method stores another case as an explicit dependency, which will be included with the other, implicitly discovered, dependencies.
- getPotentialParentFromSettingValue(settingValue, filePattern)[source]¶
Get a parent case based on a setting value and a pattern.
This is a convenient way for a plugin to express a dependency. It uses the
match.groupdict
functionality to pull the directory and case name out of a specific setting value an regular expression.- Parameters
settingValue (str) – A particular setting value that might contain a reference to an input that is produced by a dependency.
filePattern (str) – A regular expression for extracting the location and name of the dependency. If the
settingValue
matches the passed pattern, this function will attempt to extract thedirName
andtitle
groups to find the dependency.
- property title¶
The case title.
- property dbName¶
The case output database name.
- property directory¶
The working directory of the case.
- setUpTaskDependence()[source]¶
Set the task dependence based on the
dependencies
.This accounts for whether or not the dependency is enabled.
- run()[source]¶
Run an ARMI case.
This initializes an
Operator
, aReactor
and invokesOperator.operate()
!It also activates supervisory things like code coverage checking, profiling, or tracing, if requested by users during debugging.
Notes
Room for improvement: The coverage, profiling, etc. stuff can probably be moved out of here to a more elegant place (like a context manager?).
- checkInputs()[source]¶
Checks ARMI inputs for consistency.
- Returns
True if the inputs are all good, False otherwise
- Return type
- summarizeDesign()[source]¶
Uses the ReportInterface to create a fancy HTML page describing the design inputs.
- buildCommand(python='python')[source]¶
Build an execution command for running or submitting a job.
- Parameters
python (str, optional) – The path to the python executable to use for executing the case. By default this will be whatever “python” resolves to in the target environment. However when running in more exotic environments (e.g. HPC cluster), it is usually desireable to provide a specific python executable.
- clone(additionalFiles=None, title=None, modifiedSettings=None, writeStyle='short')[source]¶
Clone existing ARMI inputs to current directory with optional settings modifications.
Since each case depends on multiple inputs, this is a safer way to move cases around without having to wonder if you copied all the files appropriately.
- Parameters
additionalFiles (list (optional)) – additional file paths to copy to cloned case
title (str (optional)) – title of new case
modifiedSettings (dict (optional)) – settings to set/modify before creating the cloned case
writeStyle (str (optional)) – Writing style for which settings get written back to the settings files (short, medium, or full).
- Raises
RuntimeError – If the source and destination are the same
- compare(that, exclusion: Optional[Sequence[str]] = None, tolerance=0.01, timestepCompare=None) int [source]¶
Compare the output databases from two run cases. Return number of differences.
This is useful both for in-use testing and engineering analysis.
- writeInputs(sourceDir: Optional[str] = None, writeStyle: Optional[str] = 'short')[source]¶
Write the inputs to disk.
This allows input objects that have been modified in memory (e.g. for a parameter sweep or migration) to be written out as input for a forthcoming case.
- Parameters
sourceDir (str (optional)) – The path to copy inputs from (if different from the cs.path). Needed in SuiteBuilder cases to find the baseline inputs from plugins (e.g. shuffleLogic)
writeStyle (str (optional)) – Writing style for which settings get written back to the settings files (short, medium, or full).
Notes
This will rename the
loadingFile
andgeomFile
to betitle-blueprints + '.yaml'
andtitle + '-geom.yaml'
respectively.See also
independentVariables
parses/reads the independentVariables setting
clone
Similar to this but doesn’t let you write out new/modified geometry or blueprints objects
- armi.cases.case.copyInterfaceInputs(cs, destination: str, sourceDir: Optional[str] = None) Dict[str, Union[str, list]] [source]¶
Ping active interfaces to determine which files are considered “input”. This enables developers to add new inputs in a plugin-dependent/ modular way.
- This function should now be able to handle the updating of:
a single file (relative or absolute)
a list of files (relative or absolute), and
a file entry that has a wildcard processing into multiple files. Glob is used to offer support for wildcards.
If the file paths are absolute, do nothing. The case will be able to find the file.
In case suites or parameter sweeps, these files often have a sourceDir associated with them that is different from the cs.inputDirectory. So, if relative or wildcard, update the file paths to be absolute in the case settings and copy the file to the destination directory.
- Parameters
- Returns
newSettings – A new settings object that contains settings for the keys and values that are either an absolute file path, a list of absolute file paths, or the original file path if absolute paths could not be resolved
- Return type
Notes
Regarding the handling of relative file paths: In the future this could be simplified by adding a concept for a suite root directory, below which it is safe to copy files without needing to update settings that point with a relative path to files that are below it.