Facility Management

The facility loading application is used to update the location and material properties of named assemblies tracked by the system. Typical use cases are:

  • Initiate the facility inventory at a particular point in time using material properties calculated from a previous version of OSCAR, or from another source.

  • Add new fuel batches.

  • Specify the core loading for a particular cycle.

  • Specify movement of tracked assemblies at a particular point in time.

Note

The core loading saved here will be available to all applications which set the model.inventory_manager.load_time parameter. The system will look for the closest actual loading prior to this date from the facility archive, and use it to populate the core. Thus, once a loading is specified, it need not be repeated in any of your time bound scripts.

Creating an input module

The manager utility can be used to create a basic template input module. It is used as follows:

$ oscar5 MY_REACTOR.manager facility_loading <module name> [options]

where <module name> is the name of your input script (without any extensions), and must adhere to python module naming requirements. The following options are available:

--time <str>

Real (calender) date and time at which the facility change should be implemented. Must be an ISO compatible date and time string (see datetime).

--configuration <str>

Name of configuration whose model should be used as basis for this project. Should be the name (without any extensions) of an existing module in your configuration package.

--description <str>

Short description of the input.

For example, the following will create the batch_41 module in the facility_loading package, using the cold configuration module:

$ oscar5 MY_REACTOR.manager facility_loading batch_41 --time '10-10-2011 00:37:20' --config-file cold --description 'Load fresh assemblies for batch 41'

Application parameters

The following lists all the parameters available for this application mode:

time

: datetime

!

Real (calender) date and time at which facility changes will be saved.

model

: ModelBuilder

 = NA

The underlying heterogeneous model. If you imported an existing model from configurations, you can simply pass it to this parameter.

Attention

For facility movements, the model’s facility_manager must be set. If new assemblies are added, the model’s inventory_manager.inventory must also be available.

Adding assembly batches

New fuel assemblies are added in batches, with one assembly type per batch. A batch is added using the following call:

parameters.add_batch(loader, importer=None)
Parameters:

  • loader (loader) – Assembly type.

  • importer – Object used to set burnable materials for this batch. See Importers. If no not specified, the assemblies will be added as built.

Returns:

A batch object, which is used to add assembly names.

For example:

from ..model import assemblies

batch = parameters.add_batch(assemblies.MY_REACTOR_assembly_type_1)

Named assemblies are added using one of the following:

batch.add(*names, **kwargs)

Adds a specified list of assemblies.

Parameters:

  • names (str) – Comma separated list of assembly names.

  • kwargs – Optional keyword arguments that will be passed to the importer. These depends on the importer used, and is described below in Importers.

batch.add_all(source, pattern, **kwargs)

Adds all assemblies from a specified source.

Parameters:

  • source (directory or labeledgrid) – Source from which assembly names should be extracted. Either an existing directory or map with assembly names.

  • pattern (str) – Pattern used to filter assembly names. If source is a directory, this should be a typical file mask, e.g. ‘EF*.HIST’. Otherwise, it should be a valid regex expression, e.g ‘EF.*’.

  • kwargs – Optional keyword arguments that will be passed to the importer. These depends on the importer used, and is described below in Importers.

Multiple fuel batches can be added. When the input module is executed, the system will, for each batch:

  1. Create an assembly instance using the specified loader for each name added to the batch.

  2. If an importer is specified, it will be used to construct the material mesh for the assembly instances. Any additional keyword arguments will be passed to the importer.

  3. Each assembly instance will be saved to the inventory at time.

Specify a facility loading

The facility manager application also models the movement of assemblies between facilities. A particular set of movements are initiated with the following call:

parameters.create_loading(time=None, tag=None, blank=False)

Create a loading instance.

Parameters:

  • time (datetime) – Real (calender) date and time at which the loading should be saved. If None, the value of time is used.

  • tag – Tag used to identify the loading. See Saving the load configuration.

  • blank (bool) – Force the creation of a clean loading. If the flag is False, the loading of the previous step in the archive will be used to initiate this loading.

Returns:

A loading parameter set, which is used to load the core and move assemblies.

For example, the following is used to specify the actual core loading at time:

loading = parameters.create_loading(tag=tags.actual)

Core loading

The object returned by create_loading has the following parameters that facilitates loading of the core:

core_load_map

: labeledgrid

 = NA

Specify the core load map. Entries in this map are usually strings (assembly names) or empty placeholder tokens, but assembly instances are also allowed. String entries should point to names that are available in the inventory.

Note

Unless the blank flag was passed to create_loading, or there are no saved loadings at previous time steps, the core_load_map will be initiated with the load map at the point closest to it in the loading archive.

Attention

When assigning a grid to this parameter, and the existing load map (e.g from a previous time step) is not empty, only the entries that are not placeholders will be used to update the map.

For example, suppose the load map was initiated as:

loading.core_load_map = \
[[  -,     '1',     '2'],
  'A',  'E-11', 'F-12' ]]

Then setting,

 loading.core_load_map = \
[[  -,     '1',     '2'],
  'A',       _,  'G-12' ]]

the resulting load map will be

[[  -,     '1',     '2'],
  'A',  'E-11', 'G-12' ]]
core_rotation_map

: labeledgrid

 = NA

Specify the rotation of loaded assemblies in the core. Entries in this map are usually integers (giving the rotation in counter clockwise rotation in degrees) or empty placeholder tokens for positions that should not be rotated.

assembly_facility_load_map

: labeledgrid

 = NA

Used to specify the loading for intra-assembly facilities. Entries in these map are usually strings (assembly names) or empty placeholder tokens, but assembly instances are also allowed. String entries should point to rig names that are available in the inventory.

A map for each facility is specified by calling this parameter with the facility name. For example:

loading.assembly_facility_load_map['my_facility_name'] = \
   [[  -,     '1',     '2'],
     'A',       _,  'R-12' ]]

Facility movements

Under construction!

Saving the load configuration

The system allows for multiple configurations to be saved. Actual (which means the loading was used in the plant) are specified using tags.actual. General Test configurations are created using:

tags.candidate(name, description=None)
Parameters:

  • name (str) – Name used to identify the candidate loading.

  • description (str) – Description of the loading.

When a tag is passed to create_loading, this will be the tag used when saving the configuration. The save tag can also be specified using:

loading.save(tag, time=None)
Parameters:

  • tag – Tag used to save the core and facility loading.

  • time – Time at which loading should be saved. If not specified, the top level time parameter is used.

Importers

These objects are used to customize the material meshes for assemblies added to the inventory. The system provides a number of predefined importers (described below), as well as a framework for defining custom importers.

Fresh importer

This is the simplest importer, and is only used to customize fresh material meshes. An instance is created using,

importer = FreshImporter()

and has the following parameters which customize the material exposure mesh:

bundle

: list or tag

 = all_together

Specify how primitives should be bundled together for depletion purposes. By default, all primitives will be depleted together (that is, in one bundle). See Customizing the depletion mesh for more information.

segments

: list

Specify the radial sub-divisions for each bundle. Must be a list of length equal to the number of bundles. If not specified, no radial subdivision will be performed. See Customizing the depletion mesh for more information.

axial_layers

: integer or list

Specify the axial material exposure mesh. If an integer, the active height of the assembly will be subdivided into this many equal sizes. Otherwise, the specified list is used to deduce segment sizes (from bottom to top). See Customizing the depletion mesh for more information.

burnable

: bool

 = True

Flag all exposure materials as burnable or not.

The above parameters only apply to the main (usually fuel) burnable bundle. To customize the depletion mesh for other bundles, use:

burn_bundles = NA

Customize the depletion mesh for other burn bundles. The mesh for any valid bundle_tag can be customized. For example:

importers.burn_bundles[assembly.burn_bundle.absorber].burnable = False

will switch off depletion for the materials in the absorber bundle of the assembly. Any of the above parameters (e.g. bundles, segments, axial_segments) can be set.

Attention

The depletion mesh customization only affects the material activation in the heterogeneous calculational line. Exposures for the homogeneous line were fixed during the cOMPoSe step.

Given axial exposures

Under construction!

Given axial depletion

Under construction!

From previous OSCAR versions

Under construction!

Command line invocation

The load script is executed on the command line using the following signature:

$ oscar5 MY_REACTOR.facility_loading [options] <mode> [mode options]

with the following root options:

--log-level <str>

Set the application log level. Options are WARNING, INFO or DEBUG. The default level is WARNING.

The available modes are:

Run Mode

Description

visualization

Visualize the underlying model.

execute

Write the facility state. This is the default mode.

Execution mode

Saves all assembly batches to the inventory, and saves all specified loadings to the facility archive. This mode accepts the following flags:

--force

Overwrites any existing assembly history files.

--skip-nodal-inventory

Do not write MGRAC history files.

Note

In order to write MGRAC hisitory files, the model must have a nodal configuration specified.