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 (Settings) – Settings 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 the cs 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 the dirName and title 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.

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?).

initializeOperator(r=None)[source]

Creates and returns an Operator.

checkInputs()[source]

Checks ARMI inputs for consistency.

Returns:

True if the inputs are all good, False otherwise

Return type:

bool

summarizeDesign()[source]

Uses the ReportInterface to create a fancy HTML page describing the design inputs.

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 and geomFile to be title-blueprints + '.yaml' and title + '-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:

  • cs (Settings) – The source case settings to find input files

  • destination (str) – The target directory to copy input files to

  • sourceDir (str (optional)) – The directory from which to copy files. Defaults to cs.inputDirectory

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:

dict

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.