armi.reactor.blueprints package

Blueprints describe the geometric and composition details of the objects in the reactor (e.g. fuel assemblies, control rods, etc.).

Inputs captured within this blueprints module pertain to major design criteria like custom material properties or basic structures like the assemblies in use.

This is essentially a wrapper for a yaml loader. The given yaml file is expected to rigidly adhere to given key:value pairings.

See the blueprints documentation for more details.

The file structure is expectation is:

nuclide flags:
    AM241: {burn: true, xs: true}
    ...

custom isotopics: {} # optional


blocks:
    name:
        component name:
            component dimensions
    ...

assemblies:
    name:
        specifier: ABC
        blocks: [...]
        height: [...]
        axial mesh points: [...]
        xs types: [...]

        # optional
        myMaterialModification1: [...]
        myMaterialModification2: [...]

        # optionally extra settings (note this is probably going to be a removed feature)
        #    hotChannelFactors: TWRPclad

Examples

>>> design = blueprints.Blueprints.load(self.yamlString)
>>> print(design.gridDesigns)

Notes

The blueprints system was built to enable round trip translations between text representations of input and objects in the code.

armi.reactor.blueprints.loadFromCs(cs, roundTrip=False)[source]

Function to load Blueprints based on supplied CaseSettings.

class armi.reactor.blueprints.Blueprints[source]

Bases: yamlize.objects.Object

Base Blueprintsobject representing all the subsections in the input file.

Implementation: ARMI represents a user-specified reactor by providing a "Blueprint" YAML interface. IMPL_REACTOR_0 ../_images/arrow-right-circle.svg
links outgoing: REQ_REACTOR
constructAssem(cs, name=None, specifier=None)[source]

Construct a new assembly instance from the assembly designs in this Blueprints object.

Parameters

  • cs (CaseSettings object) – Used to apply various modeling options when constructing an assembly.

  • name (str (optional, and should be exclusive with specifier)) – Name of the assembly to construct. This should match the key that was used to define the assembly in the Blueprints YAML file.

  • specifier (str (optional, and should be exclusive with name)) – Identifier of the assembly to construct. This should match the identifier that was used to define the assembly in the Blueprints YAML file.

Raises

ValueError – If neither name nor specifier are passed

Notes

There is some possibility for “compiling” the logic with closures to make constructing an assembly / block / component faster. At this point is is pretty much irrelevant because we are currently just deepcopying already constructed assemblies.

Currently, this method is backward compatible with other code in ARMI and generates the .assemblies attribute (the BOL assemblies). Eventually, this should be removed.

attributes = <yamlize.attribute_collection.AttributeCollection object>
classmethod migrate(inp: TextIO)[source]

Given a stream representation of a blueprints file, migrate it.

Parameters

inp (TextIO) – Input stream to migrate.

classmethod load(stream, roundTrip=False)[source]

This class method is a wrapper around the yamlize.Object.load() method.

The reason for the wrapper is to allow us to default to Cloader. Essentially, the CLoader class is 10x faster, but doesn’t allow for “round trip” (read- write) access to YAMLs; for that we have the RoundTripLoader.

armi.reactor.blueprints.migrate(bp: armi.reactor.blueprints.Blueprints, cs)[source]

Apply migrations to the input structure.

This is a good place to perform migrations that address changes to the system design description (settings, blueprints, geom file). We have access to all three here, so we can even move stuff between files. Namely, this:

  • creates a grid blueprint to represent the core layout from the old geomFile setting, and applies that grid to a core system.

  • moves the radial and azimuthal submesh values from the geomFile to the assembly designs, but only if they are uniform (this is limiting, but could be made more sophisticated in the future, if there is need)

This allows settings-driven core map to still be used for backwards compatibility. At some point once the input stabilizes, we may wish to move this out to the dedicated migration portion of the code, and not perform the migration so implicitly.