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 incoporated into a PluginManager, which live inside of a armi.apps.App object.

The PluginManager is a 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.

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.

class armi.plugins.ArmiPlugin

Bases: object

An ArmiPlugin provides a namespace to collect hook implementations provided by a single “plugin”. This API is incomplete, unstable, and expected to change dramatically!

static exposeInterfaces(cs)

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

Function for defining additional parameters.

Returns

Keys should be subclasses of ArmiObject, values being a ParameterDefinitionCollection should be added to the key’s perameter 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)

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 opetions and active interfaces

Implementers may alter the state of the passed Assembly objects.

Returns

Return type

None

static onProcessCoreLoading(core, cs)

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, armi.utils.flags.auto]]

Function to provide new Flags definitions.

This allows a plugin to provide novel values for the Flags system. Implementations should return a dictionary mapping flag names to their desired values. In most cases, no specific value is needed, in which case armi.utils.flags.auto should be used.

See also

armi.reactor.flags()

Example

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

static defineBlockTypes()

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:

return [(Hexagon, HexBlock)]

static defineAssemblyTypes()

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.

static defineBlueprintsSections()

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

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

Define configuration settings for this plugin.

This hook allows plugins to provide their own configuration settings.

Returns

Setting objects associated with this plugin

Return type

list

static defineSettingsValidators(inspector)

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 Case``s 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()

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.

armi.plugins.getNewPluginManager() → pluggy.manager.PluginManager

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)