Reactor System Requirements Specification

System Purpose

The MOOSE is a tool for solving complex coupled Multiphysics equations using the finite element method. MOOSE uses an object-oriented design to abstract data structure management, parallelism, threading and compiling while providing an easy to use interface targeted at engineers that may not have a lot of software development experience. MOOSE will require extreme scalability and flexibility when compared to other FEM frameworks. For instance, MOOSE needs the ability to run extremely complex material models, or even third-party applications within a parallel simulation without sacrificing parallelism. This capability is in contrast to what is often seen in commercial packages, where custom material models can limit the parallel scalability, forcing serial runs in the most severe cases. When comparing high-end capabilities, many MOOSE competitors target modest-sized clusters with just a few thousand processing cores. MOOSE, however, will be required to routinely executed on much larger clusters with scalability to clusters available in the top 500 systems (top500.org). MOOSE will also be targeted at smaller systems such as high-end laptop computers.

The design goal of MOOSE is to give developers ultimate control over their physical models and applications. Designing new models or solving completely new classes of problems will be accomplished by writing standard C++ source code within the framework's class hierarchy. Scientists and engineers will be free to implement completely new algorithms using pieces of the framework where possible, and extending the framework's capabilities where it makes sense to do so. Commercial applications do not have this capability, and instead opt for either a more rigid parameter system or a limited application-specific metalanguage.

System Scope

MOOSE's scope is to provide a set of interfaces for building FEM simulations. Abstractions to all underlying libraries are provided.

Solving coupled problems where competing physical phenomena impact one and other in a significant nonlinear fashion represents a serious challenge to several solution strategies. Small perturbations in strongly-coupled parameters often have very large adverse effects on convergence behavior. These adverse effects are compounded as additional physics are added to a model. To overcome these challenges, MOOSE employs three distinct yet compatible systems for solving these types of problems.

First, an advanced numerical technique called the JFNK method is employed to solve the most fully-coupled physics in an accurate, consistent way. An example of this would be the effect of temperature on the expansion or contraction of a material. While the JFNK numerical method is very effective at solving fully-coupled equations, it can also be computationally expensive. Plus, not all physical phenomena in a given model are truly coupled to one another. For instance, in a reactor, the speed of the coolant flow may not have any direct effect on the complex chemical reactions taking place inside the fuel rods. We call such models "loosely-coupled". A robust, scalable system must strike the proper balance between the various modeling strategies to avoid performing unnecessary computations or incorrectly predicting behavior in situations such as these.

MOOSE's Multiapp system will allow modelers to group physics into logical categories where MOOSE can solve some groups fully-coupled and others loosely-coupled. The Multiapp system goes even further by also supporting a "tightly-coupled" strategy, which falls somewhere between the "fully-coupled" and "loosely-coupled" approaches. Several sets of physics can then be linked together into logical hierarchies using any one of these coupling strategies, allowing for several potential solution strategies. For instance, a complex nuclear reactor model might consist of several tightly-coupled systems of fully-coupled equations.

Finally, MOOSE's Transfers system ties all of the physics groups contained within the Multiapp system together and allows for full control over the flow of information among the various groups. This capability bridges physical phenomena from several different complementary scales simultaneously. When these three MOOSE systems are combined, myriad coupling combinations are possible. In all cases, the MOOSE framework handles the parallel communication, input, output and execution of the underlying simulation. By handling these computer science tasks, the MOOSE framework keeps modelers focused on doing research.

MOOSE innovates by building advanced simulation capabilities on top of the very best available software technologies in a way that makes them widely accessible for innovative research. MOOSE is equally capable of solving small models on common laptops and the very biggest FEM models ever attempted—all without any major changes to configuration or source code. Since its inception, the MOOSE project has focused on both developer and computational efficiency. Improved developer efficiency is achieved by leveraging existing algorithms and technologies from several leading open-source packages. Additionally, MOOSE uses several complementary parallel technologies (both the distributed-memory message passing paradigm and shared-memory thread-based approaches are used) to lay an efficient computational foundation for development. Using existing open technologies in this manner helps the developers reduce the scope of the project and keeps the size of the MOOSE code base maintainable. This approach provides users with state-of-the-art finite element and solver technology as a basis for the advanced coupling and solution strategies mentioned previously.

MOOSE's developers work openly with other package developers to make sure that cutting-edge technologies are available through MOOSE, providing researchers with competitive research opportunities. MOOSE maintains a set of objects that hide parallel interfaces while exposing advanced spatial and temporal coupling algorithms in the framework. This accessible approach places developmental technology into the hands of scientists and engineers, which can speed the pace of scientific discovery.

System Context

MOOSE is a command-line driven application. This is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all of the usage of the software is through any standard terminal program generally available on all supported operating systems. Similarly, for the purpose of interacting through the software, there is only a single user, "the user", which interacts with the software through the command-line. MOOSE does not maintain any back-end database or interact with any system daemons. It is a executable, which may be launched from the command line and writes out various result files as it runs.

Figure 1: Usage of MOOSE and MOOSE-based applications.

System Functions

Since MOOSE is a command-line driven application, all functionality provided in the framework is operated through the use of standard UNIX command line flags and the extendable MOOSE input file. The framework is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.

User Characteristics

• Framework Developers: These are the core developers of the framework. They will be responsible for following and enforcing the appropriate software development standards. They will be responsible for designing, implementing and maintaining the software.

• Developers: A Scientist or Engineer that utilizes the framework to build his or her own application. This user will typically have a background in modeling and simulation techniques and/or numerical analysis but may only have a limited skill-set when it comes to object-oriented coding and the C++ language. This is our primary focus group. In many cases these developers will be encouraged to give their code back to the framework maintainers.

• Analysts: These are users that will run the code and perform various analysis on the simulations they perform. These users may interact with developers of the system requesting new features and reporting bugs found and will typically make heavy use of the input file format.

Assumptions and Dependencies

The Reactor application is developed using MOOSE and is based on various modules, as such the SRS for Reactor is dependent upon the files listed at the beginning of this document.

Definitions

- Verification: (1) The process of: evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (2) Formal proof of program correctness (e.g., requirements, design, implementation reviews, system tests) (24765:2010(E), 2010).

Acronyms

Functional Requirements

• reactor: Functions
• 12.1.1The system shall include a function that describes the rotation of multiple control drums
  1. using control_drum_id.
  2. without using control_drum_id.
• 12.1.2The function that describes control drums shall throw an error
  1. if start_angles and angular_speeds have different lengths.
  2. if angle_ranges and angular_speeds have different lengths.
  3. if input control drum parameters are not compatible with MeshMetaData.
  4. if rotation_end_time is smaller than rotation_start_time.

• reactor: Meshgenerators
• 12.2.1The system shall generate a 3D square assembly mesh from 2 pin types
• 12.2.2The system shall generate a 3D hexagonal assembly mesh with duct regions with assigned IDs
• 12.2.3The system should modify the azimuthal blocks
  1. (without the external block) based on the given angle range.
  2. (with the external block) based on the given angle range.
  3. (based on block names) based on the given angle range.
• 12.2.4The system shall throw an error
  1. if old_blocks given as block ids and new_block_ids have different sizes.
  2. if old_blocks given as block names and new_block_ids have different sizes.
  3. if new_block_names and new_block_ids have different sizes.
  4. if old_blocks contains blocks that do not exist in the input mesh.
  5. if the circular region is overlapped with background region after radius correction.
  6. if the mesh is too corase for the absorber.
• 12.2.5The system shall include the ability to assign coarse element IDs based on a coarse mesh for elements of a fine mesh.
• 12.2.6The system shall include the ability to assign extra element IDs based on the subdomain ID of a coarse mesh for elements of a fine mesh.
• 12.2.7The system shall include the ability to assign extra element IDs based on an extra element ID of a coarse mesh for elements of a fine mesh.
• 12.2.8The system shall return an error if
  1. the coarse mesh extra element id used for assigning does not exist
  2. the input mesh is not nested in the coarse mesh in CoarseMeshExtraElementIDGenerator
  3. the fine mesh lies beyond the extent of the coarse mesh
  4. any node of the fine mesh lies beyond the extent of the coarse mesh
• 12.2.9The system shall generate a full 3D square core mesh with 3 pin types and 2 assembly types
• 12.2.10The system shall generate a 3D square core mesh with empty lattice positions
• 12.2.11The system shall generate a 3D hexagonal core mesh with empty lattice positions
• 12.2.12The system shall include the ability to copy an element ID to other element IDs.
• 12.2.13The system shall return an error if the requested source element ID does not exist on the mesh.
• 12.2.14The system shall generate a hexagon mesh that adapts one boundary of the mesh saved in the exodus file.
• 12.2.15The system shall generate a non-adaptive hexagon mesh when inputs and sides_to_adapt are not provided.
• 12.2.16The system shall throw an error if sides_to_adapt and inputs have different sizes.
• 12.2.17The system shall stitch hexagon meshes to form a large mesh with hexagon boundary.
• 12.2.18The system shall stitch hexagon meshes to form a large mesh without extra boundary.
• 12.2.19The system shall stitch hexagon meshes twice to form a larger mesh.
• 12.2.20The system shall stitch hexagon meshes twice to form a larger mesh with a control drum.
• 12.2.21The system shall throw a reasonable error when generating patterned hexagon mesh if one of the input meshes has a flat side facing up.
• 12.2.22The system shall throw an error if the input meshes contain different block ids that share the same block name.
• 12.2.23The system shall throw an error if the layer number of pattern is not odd.
• 12.2.24The system shall throw an error if the layer number of pattern is zero or unity.
• 12.2.25The system shall throw an error if the pattern does not represent a hexagonal pattern.
• 12.2.26The system shall throw an error if the pattern includes input mesh indices that exceed number of elements of inputs.
• 12.2.27The system shall throw an error if background_block_id and duct_block_ids are not provided simultaneously if the mesh has ducts.
• 12.2.28The system shall throw an error if background_block_name and duct_block_names are not provided simultaneously if the mesh has ducts.
• 12.2.29The system shall throw an error if length of duct_block_ids is not consistent with number of ducts.
• 12.2.30The system shall throw an error if length of duct_block_names is not consistent with number of ducts.
• 12.2.31The system shall throw an error if background_block_name or background_block_id are provided when pattern_boundary is none.
• 12.2.32The system shall throw an error if no hexagon size is provided when pattern_boundary is hexagon.
• 12.2.33The system shall throw an error if not all the meshes provided in inputs are used in pattern.
• 12.2.34The system shall throw an error if no pitch meta data can be obtained from the input mesh.
• 12.2.35The system shall throw an error if no pattern pitch meta data can be obtained from the input mesh.
• 12.2.36The system shall throw an error if input meshes have different pattern pitch meta data.
• 12.2.37The system shall generate a hexagonal assembly mesh then modify the peripheral region to facilitate further stitching.
• 12.2.38The system shall generate a hexagonal assembly mesh with modified peripheral region and retain the specified reporting id.
• 12.2.39The system shall generate a hexagonal assembly mesh with modified peripheral region and assign new values to the specified reporting id.
• 12.2.40The system shall generate hexagonal assembly meshes with peripheral regions modified in order to stitch them together to form a core mesh.
• 12.2.41The system shall throw an error if the size of specificed reporting id values does not match size of specified reporting id names.
• 12.2.42The system shall throw an error if the specified reporting id to be modified does not exist on the input mesh.
• 12.2.43The system shall throw an error if the input mesh to the hexagonal mesh boundary modifier is generated by an incompatible mesh generator.
• 12.2.44The system shall add a peripheral ring to to the input mesh without preserving volumes due to polygonization.
• 12.2.45The system shall be able to add a peripheral ring to the input mesh and preserve volumes even with polygonization.
• 12.2.46The system shall be able to add a peripheral ring with radial biasing to the input mesh and preserve volumes even with polygonization.
• 12.2.47The system shall be able to add a peripheral ring with boundary layers to the input mesh and preserve volumes even with polygonization.
• 12.2.48The system shall throw an error if the specified inner and outer boundary layers are overlapped.
• 12.2.49The system shall throw an error if a non-2D mesh is given as the input mesh.
• 12.2.50The system shall throw an error if the given boundary of the input mesh has two or more segments.
• 12.2.51The system shall throw an error if the given boundary of the input mesh is an open curve.
• 12.2.52The system shall throw an error if the consecutive nodes of the given boundary of the input mesh do not change monotonically.
• 12.2.53The system shall throw an error if the given peripheral ring radius is not enough to cover the input mesh.
• 12.2.54The system shall throw an error if the given external boundary is actually an internal boundary of the input mesh.
• 12.2.55The system shall generate a triangulation without any Steiner points, given an inner boundary name.
• 12.2.56The system shall generate a triangulation without any Steiner points, given an inner boundary id.
• 12.2.57The system shall generate a triangulation with Steiner points.
• 12.2.58The system shall throw an error if extra_circle_radii and extra_circle_num_segments are not compatible.
• 12.2.59The system shall throw an error if both inner_boundary_name and inner_boundary_id are both provided.
• 12.2.60The system shall throw an error if neither inner_boundary_name and inner_boundary_id are provided.
• 12.2.61The system shall throw an error if inner_boundary_name is not defined on the input mesh.
• 12.2.62The system shall throw an error if inner_boundary_id is not defined on the input mesh.
• 12.2.63The system shall generate a 2D square pin mesh with fuel, gap, clad, background regions
• 12.2.64The system shall generate a 3D square pin mesh with ring and background region and tri center elements
• 12.2.65The system shall throw an error when trying to generate a pin mesh with more than 1 radial region and tri center elements
• 12.2.66The system shall generate a 2D hexagonal pin mesh with 2 radial regions
• 12.2.67The system shall generate a 3D hexagonal pin mesh with radial, background, and duct regions
• 12.2.68The system shall generate a hexagon mesh without rings and ducts.
• 12.2.69The system shall generate a hexagon mesh without rings and ducts with one of its flat side facing up.
• 12.2.70The system shall generate a hexagon mesh with only one radial layer of elements without rings and ducts.
• 12.2.71The system shall generate a hexagon mesh with rings.
• 12.2.72The system shall generate a hexagon mesh with ducts.
• 12.2.73The system shall generate a hexagon mesh with rings and ducts.
• 12.2.74The system shall generate a radially biased hexagon mesh with rings and ducts.
• 12.2.75The system shall generate a hexagon mesh with rings and ducts including boundary layers.
• 12.2.76The system shall generate a hexagon mesh with rings, ducts and quad central elements.
• 12.2.77The system shall generate a hexagon mesh with rings, ducts and quad central elements with custom center quad factor.
• 12.2.78The system shall throw an error if
  1. num_sectors_per_side and quad_center_elements are not compatible.
  2. interface_boundary_names has an incorrect length.
  3. background_block_ids has more than one element when the mesh has ring(s).
  4. background_block_names has more than one element when the mesh has ring(s).
  5. background_block_ids has a length other than zero or two when the mesh does not have rings and background_intervals does not equal one.
  6. background_block_names has a length other than zero or two when the mesh does not have rings and background_intervals does not equal one.
  7. multiple block ids share a single block name.
  8. size of num_sectors_per_side is not num_sides.
  9. num_sectors_per_side elements are not all even.
  10. ring_radii and ring_intervals have different sizes.
  11. ring_radii and ring_radial_biases have different sizes.
  12. ring_block_ids size is not consistent with number of rings in the mesh.
  13. ring_block_names size is not consistent with number of rings in the mesh.
  14. ring_radii is not strictly ascending.
  15. rings are bigger than the polygon.
  16. duct_sizes and duct_intervals have different sizes.
  17. duct_sizes and duct_radial_biases have different sizes.
  18. duct_block_ids size is not consistent with the number of ducts in the mesh.
  19. duct_block_names size is not consistent with the number of ducts in the mesh.
  20. duct_sizes is not strictly ascending.
  21. duct_sizes is non-positive or is low enough to be overlapped with rings.
  22. duct_sizes is bigger than the polygon.
  23. boundary layers in background region of a hexagonal cell are overlapped.
  24. inner and outer ring boundary layer parameters have inconsistent size.
  25. ring's inner boundary layer has zero interval but non-zero thickness.
  26. ring's inner boundary layer has nonzero intervals but zero thickness.
  27. ring's outer boundary layer has zero interval but non-zero thickness.
  28. ring's outer boundary layer has nonzero intervals but zero thickness.
  29. ring's boundary layers are thicker than the ring itself.
  30. inner and outer duct boundary layer parameters have inconsistent size.
  31. duct's inner boundary layer has zero interval but non-zero thickness.
  32. duct's inner boundary layer has nonzero intervals but zero thickness.
  33. duct's outer boundary layer has zero interval but non-zero thickness.
  34. duct's outer boundary layer has nonzero intervals but zero thickness.
  35. duct's boundary layers are thicker than the ring itself.
  36. center_quad_factor is provided for triangular center elements.
• 12.2.79The system shall support the generation of reporting IDs for Cartesian assemblies assigned
  1. in sequential order for each components in the lattice
  2. based on the ID of the input pattern tiles
  3. based on user-defined mapping
• 12.2.80The system shall support the generation of assembly and pin reporting IDs for Cartesian cores
  1. with regular square core boundary
  2. with zagged core boundary formed by removal of certain assemblies on periphery
• 12.2.81The system shall support the generation of depletion IDs for a 2D reactor core
• 12.2.82The system shall support the generation of plane depletion IDs for 2D reactor cores with skipped materials
• 12.2.83The system shall support the generation of reporting IDs for hexagonal assemblies assigned
  1. in sequential order for each components in the lattice
  2. based on the ID of the input pattern tiles
  3. based on user-defined mapping
• 12.2.84The system shall support the generation of reporting IDs for hexagonal cores
• 12.2.85The system shall support the generation of reporting IDs for hexagonal cores with removal of certain assemblies on periphery
• 12.2.86The system shall include the ability to create a simple hexagon mesh
  1. with TRI elements
  2. with QUAD elements
• 12.2.87The system shall include the ability to assign element IDs based on mesh subdomain IDs or names.
• 12.2.88The system shall return an error if
  1. the subdomain vector to use for assigning extra element IDs is empty
  2. a subdomain is listed more than once when assigning extra element IDs
  3. the subdomain ids and the extra element id names arent vectors of the same size
  4. the subdomain ids and the extra element ids to set arent vectors of the same size
  5. the default extra element IDs arent specified for each extra element id
• 12.2.89The system shall be able to generate a tri-pin hexagonal assembly mesh.
• 12.2.90The system shall be able to generate a tri-pin assembly mesh by specifying the apothem size.
• 12.2.91The system shall generate a tri-pin assembly mesh with three identical pins.
• 12.2.92The system shall be able to generate a dummy core mesh containing a tri-pin assembly.
• 12.2.93The system shall throw an error if the number of rings radii specified does not match either one or the number of pins
• 12.2.94The system shall throw an error if the largest ring specified exceeds the assembly boundary.
• 12.2.95The system shall throw an error if the parameter specifying the radial intervals of ring regions does not have appropriate size.
• 12.2.96The system shall throw an error if the parameter specifying the block ids of ring regions does not have appropriate size.
• 12.2.97The system shall throw an error if the parameter specifying the radial intervals of ring regions is inconsistent with the parameter specifying the sizes of ring regions.
• 12.2.98The system shall throw an error if the parameter specifying the block ids of ring regions is inconsistent with the parameter specifying the sizes of ring regions (case 1).
• 12.2.99The system shall throw an error if the parameter specifying the block ids of ring regions is inconsistent with the parameter specifying the sizes of ring regions (case 2).
• 12.2.100The system shall throw an error if the parameter specifying the block names of ring regions is inconsistent with the parameter specifying the sizes of ring regions (case 1).
• 12.2.101The system shall throw an error if the parameter specifying the block names of ring regions is inconsistent with the parameter specifying the sizes of ring regions (case 2).
• 12.2.102The system shall throw an error if the parameter specifying the block names of ring regions is inconsistent with the parameter specifying the block ids of ring regions.
• 12.2.103The system shall throw an error if the size of the parameter specifying the block ids of background region is not one when all the three sections have rings.
• 12.2.104The system shall throw an error if the size of the parameter specifying the block names of background region is not one when all the three sections have rings.
• 12.2.105The system shall throw an error if the size of the parameter specifying the block ids of background region is not two when ring-free section exists.
• 12.2.106The system shall throw an error if the size of the parameter specifying the block names of background region is not two when ring-free section exists.
• 12.2.107The system shall throw an error if the size of the parameter specifying the block ids of background region is not one when all the sections are ring-free and background_intervals is 1.
• 12.2.108The system shall throw an error if the size of the parameter specifying the block names of background region is not one when all the sections are ring-free and background_intervals is 1.
• 12.2.109The system shall throw an error if extra element integer values of the pins are provided without specifying extra element integer names.
• 12.2.110The system shall throw an error if extra element integer values specified do not have the correct size.
• 12.2.111The system shall throw an error if the offset of the ring region center moves the center of the ring out of the hexagon assembly region.

Usability Requirements

Performace Requirements

System Interfaces

System Operations

System Modes and States

MOOSE applications normally run in normal execution mode when an input file is supplied. However there are a few other modes that can be triggered with various command line flags as indicated here:

Phyisical Characteristics

MOOSE is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running a MOOSE-based application.

Environmental Conditions

Not Applicable

System Security

MOOSE based applications have no requirements or special needs related to system-security. The framework is designed to run completely in user-space with no elevated privileges required nor recommended.

Information Management

The core framework in its entirety will be made publicly available on an appropriate repository hosting site. Backups and security services will be provided by the hosting service.

Polices and Regulations

MOOSE-based applications must comply with all export control restrictions.

System Life Cycle Sustainment

MOOSE-based development follows various agile methods. The system is continuously built and deployed in a piecemeal fashion since objects within the system are more or less independent. Every new object requires a test, which in turn requires an associated requirement and design description. Some MOOSE-based development teams follow the Nuclear Quality Assurance Level 1 (NQA-1) standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing MOOSE source code. However, some MOOSE-based applications maybe be export controlled in which case all export control restrictions must be adhered to when packaging and shipping media.