armi.context module

Module containing global constants that reflect the executing context of ARMI.

This contains information about the circumstatces under which an ARMI application is running. Things like the MPI environment, executing user, etc. live here. These are re-exported by the armi package, but live here so that import loops won’t lead to as many issues.

class armi.context.Mode(value)[source]

Bases: Enum

Mode represents different run modes possible in ARMI.

The modes can be Batch, Interactive, or GUI. In different modes, there are different types of interactions possible.

Mode is generally auto-detected based on your terminal. It can also be set in various CLI entry points, which are the implementations of armi.cli.entryPoint.EntryPoint. Lastly, each entry point has a --batch command line argument that can force Batch mode.

BATCH = 1
INTERACTIVE = 2
GUI = 4
classmethod setMode(mode)[source]

Set the run mode of the current ARMI case.

armi.context.activateLocalFastPath() None[source]

Specify a local temp directory to be the fast path.

FAST_PATH is often a local hard drive on a cluster node. It’s a high-performance scratch space. Different processors on the same node should have different fast paths. Some old code may MPI_RANK-dependent folders/filenames as well, but this is no longer necessary.

Warning

This path will be obliterated when the job ends so be careful.

Note also that this path is set at import time, so if a series of unit tests come through that instantiate one operator after the other, the path will already exist the second time. The directory is created in the Operator constructor.

armi.context.getFastPath() str[source]

Callable to get the current FAST_PATH.

Notes

It’s too dangerous to use FAST_PATH directly as it can change between import and runtime. For example, a module that does from armi.context import FAST_PATH is disconnected from the official FAST_PATH controlled by this module.

armi.context.cleanTempDirs(olderThanDays=None)[source]

Clean up temporary files after a run.

The Windows HPC system sends a SIGBREAK signal when the user cancels a job, which is NOT handled by atexit. Notably SIGBREAK doesn’t exist off Windows. For the SIGBREAK signal to work with a Microsoft HPC, the TaskCancelGracePeriod option must be configured to be non-zero. This sets the period between SIGBREAK and SIGTERM/SIGINT. To do cleanups in this case, we must use the signal module. Actually, even then it does not work because MS mpiexec does not pass signals through.

Parameters:

olderThanDays (int, optional) – If provided, deletes other ARMI directories if they are older than the requested time.

armi.context.cleanAllArmiTempDirs(olderThanDays: int) None[source]

Delete all ARMI-related files from other unrelated runs after olderThanDays days (in case this failed on earlier runs).

Warning

This will break any concurrent runs that are still running.

This is a useful utility in HPC environments when some runs crash sometimes.

armi.context.disconnectAllHdfDBs() None[source]

Forcibly disconnect all instances of HdfDB objects.

Notes

This is a hack to help ARMI exit gracefully when the garbage collector and h5py have issues destroying objects. After lots of investigation, the root cause for why this was having issues was never identified. It appears that when several HDF5 files are open in the same run (e.g. when calling armi.init() multiple times from a post-processing script), when these h5py File objects were closed, the garbage collector would raise an exception related to the repr’ing the object. We get around this by using the garbage collector to manually disconnect all open HdfDB objects.