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)

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 :py:class:`~armi.cases.suite.CaseSuite`s.

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) – 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)

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)

Get a parent case based on a setting value and a pattern.

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.

• is a convenient way for a plugin to express a dependency. It uses the (This) –

• functionality to pull the directory and case name out of a (match.groupdict) –

• setting value an regular expression. (specific) –

_getPotentialDependencies(dirName, title)

Get a parent case based on a directory and case title.

property title

The case title.

property dbName

The case output database name.

property directory

The working directory of the case.

__eq__(that)

Compares two cases to determine if they are equivalent by looking at the title and directory.

Notes

No other attributes except those stated above are used for the comparison; the above stated attributes can be considered the “primary key” for a Case object and identify it as being unique. Both of these comparisons are simple string comparisons, so a reference and an absolute path to the same case would be considered different.

setUpTaskDependence()

Set the task dependence based on the dependencies.

This accounts for whether or not the dependency is enabled.

Note

This is a leftover from before the release of the ARMI framework. The API of the proprietary cluster communication library is being used here. This should either be moved out into the cluster plugin, or the library should be made available.

run()

Run an ARMI case.

This initializes an Operator, a Reactor and invokes Operator.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?).

initializeOperator(r=None)

Creates and returns an Operator.

_initBurnChain()

Apply the burn chain setting to the nucDir.

Notes

This is admittedly an odd place for this but the burn chain info must be applied sometime after user-input has been loaded (for custom burn chains) but not long after (because nucDir is framework-level and expected to be up-to-date by lots of modules).

checkInputs()

Checks ARMI inputs for consistency.

Returns

True if the inputs are all good, False otherwise

Return type

bool

summarizeDesign(generateFullCoreMap=True, showBlockAxialMesh=True)

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

buildCommand(python='python')

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)

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

Raises

RuntimeError – If the source and destination are the same

compare(that, exclusion: Optional[Sequence[str]] = None, weights=None, tolerance=0.01, timestepMatchup=None, output='') → int

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)

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)

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, str]

Copy sets of files that are considered “input” from each active interface.

This enables developers to add new inputs in a plugin-dependent/ modular way.

In parameter sweeps, these often have a sourceDir associated with them that is different from the cs.inputDirectory.

Parameters

• cs (CaseSettings) – 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

Notes

This may seem a bit overly complex, but a lot of the behavior is important. Relative paths are copied into the target directory, which in some cases requires updating the setting that pointed to the file in the first place. This is necessary to avoid case dependencies in relavive locations above the input directory, which can lead to issues when cloneing case suites. 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.