armi.plugins module

Plugins allow various built-in or external functionality to be brought into the ARMI ecosystem.

This module defines the hooks that may be defined within plugins. Plugins are ultimately incorporated into a armi.pluginManager.ArmiPluginManager, which live inside of a armi.apps.App object.

The ArmiPluginManager is derived from the PluginManager class provided by the pluggy package, which provides a registry of known plugins. Rather than create one directly, we use the armi.plugins.getNewPluginManager() function, which handles some of the setup for us.

From a high-altitude perspective, the plugins provide numerous “hooks”, which allow for ARMI to be extended in various ways. Some of these extensions are subtle and play a part in how certain ARMI components are initialized or defined. As such, it is necessary to register most plugins before some parts of ARMI are imported or exercised in a meaningful way. These requirements are in flux, and will ultimately constitute part of the specification of the ARMI plugin architecture. For now, to be safe, plugins should be registered as soon as possible.

After forming the PluginManager, the plugin hooks can be accessed through the hook attribute. E.g.:

>>> armi.getPluginManagerOrFail().hook.exposeInterfaces(cs=cs)

Don’t forget to use the keyword argument form for all arguments to hooks; pluggy requires them to enforce hook specifications.

The armi.apps.App class serves as the primary storage location of the PluginManager, and also provides some methods to get data out of the plugins more ergonomically than through the hooks themselves.

Some things you may want to bring in via a plugin includes:

• armi.settings and their validators

• armi.reactor.components for custom geometry

• armi.reactor.flags for custom reactor components

• armi.interfaces to define new calculation sequences and interactions with new codes

• armi.reactor.parameters to represent new physical state on the reactor

• armi.materials for custom materials

• Elements of the armi.gui

• armi.operators for adding new operations on reactor models

• armi.cli for adding new operations on input files

Warning

The plugin system was developed to support improved collaboration. It is new and should be considered under development. The API is subject to change as the version of the ARMI framework approaches 1.0.

Notes

Due to the nature of some of these components, there are a couple of restrictions on the order in which things can be imported (lest we endeavor to redesign them considerably). Examples:

• Parameters: All parameter definitions must be present before any ArmiObject objects are instantiated. This is mostly by choice, but also makes the most sense, because the ParameterCollection s are instance attributes of an ArmiObject, which in turn use Parameter objects as class attributes. We should know what class attributes we have before making instances.

• Blueprints: Since blueprints should be extendable with new sections, we must also be able to provide new class attributes to extend their behavior. This is because blueprints use the yamlize package, which uses class attributes to define much of the class’s behavior through metaclassing. Therefore, we need to be able to import all plugins before importing blueprints.

Plugins are currently stateless. They do not have __init__() methods, and when they are registered with the PluginMagager, the PluginManager gets the Plugin’s class object rather than an instance of that class. Also notice that all of the hooks are @staticmethods. As a result, they can be called directly off of the class object, and only have access to the state passed into them to perform their function. This is a deliberate design choice to keep the plugin system simple and to preclude a large class of potential bugs. At some point it may make sense to revisit this.

While the Plugin API is the main place for ARMI framework customization, there are several other areas where ARMI may be extended or customized. These typically pre-dated the Plugin-based architecture, and as the need arise may be migrated to here.

• Component types: Component types are registered dynamically through some metaclass magic, found in armi.reactor.components.component.ComponentType and armi.reactor.composites.CompositeModelType. Simply defining a new Component subclass should register it with the appropriate ARMI systems. While this is convenient, it does lead to potential issues, as the behavior of ARMI becomes sensitive to module import order and the like; the containing module needs to be imported before the registration occurs, which can be surprising.

• Interface input files: Interfaces used to be discovered dynamically, rather than explicitly as they are now in the armi.plugins.ArmiPlugin.exposeInterfaces() plugin hook. Essentially they functioned as ersatz plugins. One of the ways that they would customize ARMI behavior is through the armi.physics.interface.Interface.specifyInputs() static method, which is still used to determine inter-Case dependencies and support cloning and hashing Case inputs. Going forward, this approach will likely be deprecated in favor of a plugin hook.

• Fuel handler logic: The armi.physics.fuelCycle.fuelHandlers.FuelHandlerInterface supports customization through the dynamic loading of fuel handler logic modules, based on user settings. This also predated the plugin infrastructure, and may one day be replaced with plugin-based fuel handler logic.

class armi.plugins.ArmiPlugin

Bases: object

An ArmiPlugin exposes a collection of hooks that allow users to add a variety of things to their ARMI application: Interfaces, parameters, settings, flags, and much more.

static exposeInterfaces(cs) → List

Function for exposing interface(s) to other code.

Returns:

Tuples containing:

• The insertion order to use when building an interface stack,

• an implementation of the Interface class

• a dictionary of kwargs to pass to an Operator when adding an instance of the interface class

If no Interfaces should be active given the passed case settings, this should return an empty list.

Return type:

list

static defineParameters() → Dict

Define additional parameters for the reactor data model.

Returns:

Keys should be subclasses of ArmiObject, values being a ParameterDefinitionCollection should be added to the key’s parameter definitions.

Return type:

dict

Example

>>> pluginBlockParams = parameters.ParameterDefinitionCollection()
>>> with pluginBlockParams.createBuilder() as pb:
...     pb.defParam("plugBlkP1", ...)
...     # ...
...
>>> pluginAssemParams = parameters.ParameterDefinitionCollection()
>>> with pluginAssemParams.createBuilder() as pb:
...     pb.defParam("plugAsmP1", ...)
...     # ...
...
>>> return {
...     blocks.Block: pluginBlockParams,
...     assemblies.Assembly: pluginAssemParams
... }

static afterConstructionOfAssemblies(assemblies, cs) → None

Function to call after a set of assemblies are constructed.

This hook can be used to:

• Verify that all assemblies satisfy constraints imposed by active interfaces and plugins

• Apply modifications to Assemblies based on modeling options and active interfaces

Implementers may alter the state of the passed Assembly objects.

Return type:

None

static onProcessCoreLoading(core, cs, dbLoad) → None

Function to call whenever a Core object is newly built.

This is usually used to set initial parameter values from inputs, either after constructing a Core from Blueprints, or after loading it from a database.

static defineFlags() → Dict[str, Union[int, auto]]

Add new flags to the reactor data model, and the simulation.

See also

armi.reactor.flags

Example

>>> def defineFlags():
...     return {
...         "FANCY": armi.utils.flags.auto()
...     }

static defineBlockTypes() → List

Function for providing novel Block types from a plugin.

This should return a list of tuples containing (compType, blockType), where blockType is a new Block subclass to register, and compType is the corresponding Component type that should activate it. For instance a HexBlock would be created when the largest component is a Hexagon:

:returns: [(Hexagon, HexBlock)]
:rtype: list

static defineAssemblyTypes() → List

Function for providing novel Assembly types from a plugin.

This should return a list of tuples containing (blockType, assemType), where assemType is a new Assembly subclass to register, and blockType is the corresponding Block subclass that, if present in the assembly, should trigger it to be of the corresponding assemType.

Warning

The utility of subclassing Assembly is suspect, and may soon cease to be supported. In practice, Assembly subclasses provide very little functionality beyond that on the base class, and even that functionality can probably be better suited elsewhere. Moving this code around would let us eliminate the specialized Assembly subclasses altogether. In such a case, this API will be removed from the framework.

Example

[

(HexBlock, HexAssembly), (CartesianBlock, CartesianAssembly), (ThRZBlock, ThRZAssembly),

]

Returns:

List of new Block&Assembly types

Return type:

list

static defineBlueprintsSections() → List

Return new sections for the blueprints input method.

This hook allows plugins to extend the blueprints functionality with their own sections.

Returns:

(name, section, resolutionMethod) tuples, where:

• name : The name of the attribute to add to the Blueprints class; this should be a valid Python identifier.

• section : An instance of yaml.Attribute defining the data that is described by the Blueprints section.

• resolutionMethod : A callable that takes a Blueprints object and case settings as arguments. This will be called like an unbound instance method on the passed Blueprints object to initialize the state of the new Blueprints section.

Return type:

list

Notes

Most of the sections that a plugin would want to add may be better served as settings, rather than blueprints sections. These sections were added to the blueprints mainly because the schema is more flexible, allowing namespaces and hierarchical collections of settings. Perhaps in the near future it would make sense to enhance the settings system to support these features, moving the blueprints extensions out into settings. This is discussed in more detail in T1671.

static defineEntryPoints() → List

Return new entry points for the ARMI CLI.

This hook allows plugins to provide their own ARMI entry points, which each serve as a command in the command-line interface.

Returns:

class objects which derive from the base EntryPoint class.

Return type:

list

static defineSettings() → List

Define configuration settings for this plugin.

Returns:

A list of Settings, Options, or Defaults to be registered.

Return type:

list

See also

armi.physics.neutronics.NeutronicsPlugin.defineSettings, armi.settings.setting.Setting, armi.settings.setting.Option, armi.settings.setting.Default

static defineSettingsValidators(inspector) → List

Define the high-level settings input validators by adding them to an inspector.

Parameters:

inspector (armi.operators.settingsValidation.Inspector instance) – The inspector to add queries to. See note below, this is not ideal.

Notes

These are higher-level than the input-level SCHEMA defined in defineSettings() and are intended to be used for more complex cross-plugin info.

We’d prefer to not manipulate objects passed in directly, but rather have the inspection happen in a measureable hook. This would help find misbehaving plugins.

See also

armi.operators.settingsValidation.Inspector

Runs the queries

Returns:

Query objects to attach

Return type:

list

static defineCaseDependencies(case, suite)

Function for defining case dependencies.

Some Cases depend on the results of other Cases in the same CaseSuite. Which dependencies exist, and how they are discovered depends entirely on the type of analysis and active interfaces, etc. This function allows a plugin to inspect settings and declare dependencies between the passed case and any other cases in the passed suite.

Parameters:

• case (Case) – The specific case for which we want to find dependencies.

• suite (CaseSuite) – A CaseSuite object to which the Case and other potential dependencies belong.

Returns:

dependencies – This should return a set containing Case objects that are considered dependencies of the passed case. They should be members of the passed suite.

Return type:

set of Cases

static defineGuiWidgets() → List

Define which settings should go in the GUI.

Rather than making widgets here, this simply returns metadata as a nested dictionary saying which tab to put which settings on, and a little bit about how to group them.

Returns:

widgetData – Each dict is nested. First level contains the tab name (e.g. ‘Global Flux’). Second level contains a box name. Third level contains help and a list of setting names

Return type:

list of dict

See also

armi.gui.submitter.layout.abstractTab.AbstractTab.addSectionsFromPlugin

uses data structure

Example

>>> widgets = {
...     'Global Flux': {
...         'MCNP Solver Settings': {
...             'help': "Help message"
...             'settings': [
...                 "mcnpAddTallies",
...                 "useSrctp",
...             ]
...         }
...     }
... }

static getOperatorClassFromRunType(runType: str)

Return an Operator subclass if the runType is recognized by this plugin.

static defineParameterRenames() → Dict

Return a mapping from old parameter names to new parameter names.

Occasionally, it may become necessary to alter the name of an existing parameter. This can lead to frustration when attempting to load from old database files that use the previous name. This hook allows a plugin to define mappings from the old name to the new name, allowing the old database to be read in and translated to the new parameter name.

The following rules are followed when applying these renames:

• When state is loaded from a database, if the parameter name in the database file is found in the rename dictionary, it will be mapped to that renamed parameter.

• If the renamed parameter is found in the renames, then it will be mapped again to new parameter name. This process is repeated until there are no more renames left. This allows for parameters to be renamed multiple times, and for a database from several generations prior to still be readable, so long as the history of renames is intact.

• If at the end of the above process, the parameter name is not a defined parameter for the appropriate ArmiObject type, an exception is raised.

• If any of the renames keys match any currently-defined parameters, an exception is raised.

• If any of the renames collide with another plugin’s renames, an exception is raised.

Returns:

renames – Keys should be an old parameter name, where the corresponding values are the new parameter name.

Return type:

dict

Example

The following would allow databases with values for either superOldParam or oldParam to be read into currentParam:

return {"superOldParam": "oldParam",
        "oldParam": "currentParam"}

static mpiActionRequiresReset(cmd) → bool

Flag indicating when a reactor reset is required.

Commands are sent through operators either as strings (old) or as MpiActions (newer). After some are sent, the reactor must be reset. This hook says when to reset. The reset operation is a (arguably suboptimal) response to some memory issues in very large and long-running cases.

Parameters:

cmd (str or MpiAction) – The ARMI mpi command being sent

Return type:

bool

See also

armi.operators.operatorMPI.OperatorMPI.workerOperate

Handles these flags

static getReportContents(r, cs, report, stage, blueprint) → None

To generate a report.

For more information, see Reports in ARMI.

Parameters:

• r (Reactor) –

• cs (Settings) –

• report (ReportContent) – Report object to add contents to

• stage (ReportStage) – begin/standard/or end (stage of the report for when inserting BOL vs. EOL content)

• blueprint (Blueprint, optional) – for a reactor (if None, only partial contents created)

static defineSystemBuilders() → Dict[str, Callable[[str], Composite]]

Convert a user-string from the systems section into a valid composite builder.

Parameters:

name (str) – Name of the system type defined by the user, e.g., "core"

Returns:

Dictionary that maps a grid type from the input file (e.g., "core") to a function responsible for building a grid of that type, e.g.,

{
    "core": armi.reactor.reactors.Core,
    "sfp": armi.reactor.assemblyLists.SpentFuelPool,
}

Return type:

dict

Notes

The default ReactorPlugin defines a "core" lookup and a "sfp" lookup, triggered to run after all other hooks have been run.

class armi.plugins.UserPlugin(*args, **kwargs)

Bases: ArmiPlugin

A variation on the ArmiPlugin meant to be created at runtime, from the userPlugins setting.

This is obviously a more limited use-case than the usual ArmiPlugin, as those are meant to be defined at import time, instead of run time. As such, this class has some built-in tooling to limit how these run-time plugins are used. They are meant to be more limited.

Notes

The usual ArmiPlugin is much more flexible, if the UserPlugin does not support what you want to do, just use an ArmiPlugin.

static defineParameters()

Prevents defining additional parameters.

Warning

This is not overridable.

Notes

It is a designed limitation of user plugins that they not define parameters. Parameters are defined when the App() is read in, which is LONG before the settings file has been read. So the parameters are defined before we discover the user plugin. If this is a feature you need, just use an ArmiPlugin.

static defineParameterRenames()

Prevents parameter renames.

Warning

This is not overridable.

Notes

It is a designed limitation of user plugins that they not generate parameter renames, Parameters are defined when the App() is read in, which is LONG before the settings file has been read. So the parameters are defined before we discover the user plugin. If this is a feature you need, just use a normal Plugin.

static defineSettings()

Prevents new settings.

Warning

This is not overridable.

Notes

It is a designed limitation of user plugins that they not define new settings, so that they are able to be added to the plugin stack during run time.

static defineSettingsValidators(inspector)

Prevents new settings validators.

Warning

This is not overridable.

Notes

It is a designed limitation of user plugins that they not define new settings, so that they are able to be added to the plugin stack during run time.

armi.plugins.getNewPluginManager() → ArmiPluginManager

Return a new plugin manager with all of the hookspecs pre-registered.

armi.plugins.collectInterfaceDescriptions(mod, cs)

Adapt old-style describeInterfaces to the new plugin interface.

Old describeInterfaces implementations would return an interface class and kwargs for adding to an operator. Now we expect an ORDER as well. This takes a module and case settings and staples the module’s ORDER attribute to the tuple and checks to make sure that a None is replaced by an empty list.

exception armi.plugins.PluginError

Bases: RuntimeError

Special exception class for use when a plugin appears to be non-conformant.

These should always come from some form of programmer error, and indicates conditions such as:

• A plugin improperly implementing a hook, when possible to detect.

• A collision between components provided by plugins (e.g. two plugins providing the same Blueprints section)