SubChannel System Requirements Specification

This template follows INL template TEM-135, "IT System Requirements Specification".

Introduction

System Purpose

The purpose of the Subchannel Module (SCM) is to equip the MOOSE family of codes with a modern, fast and efficient subchannel solver. As a MOOSE module, SCM seamlessly couples with other MOOSE modules and applications, providing intermediate fidelity thermal-hydraulic solutions in a multiphysics context.

System Scope

The scope of SCM is the single-phase modeling, of ducted subchannel sub-assemblies, with bare pins in a square arrangement enclosed in a square duct, or wire-wrapped/bare pins, in a triangular arrangement enclosed in a hexagonal duct. In the first case, the coolant is water, in the second case it can be various liquid metals (Lead,Lead-Bismuth Eutectic, Sodium, Sodium–Potassium) or water.

System Overview

System Context

The SubChannel module is command-line driven. Like MOOSE, this is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all 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. The SubChannel module does not maintain any back-end database or interact with any system daemons. It is an executable, which may be launched from the command line and writes out various result files as it runs.

Figure 1: Usage of the SubChannel module and other MOOSE-based applications.

System Functions

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

User Characteristics

Like MOOSE, there are three kinds of users working on the SubChannel module:

  • SubChannel module Developers: These are the core developers of the SubChannel module. They are responsible for following and enforcing the software development standards of the module, as well as designing, implementing, and maintaining the software.

  • Developers: A scientist or engineer that uses the SubChannel module alongside MOOSE to build their own application. This user will typically have a background in modeling or simulation techniques (and perhaps numerical analysis) but may only have a limited skillset when it comes to code development using the C++ language. This is the primary focus group of the module. In many cases, these developers will be encouraged to contribute module-appropriate code back to the SubChannel module, or to MOOSE itself.

  • Analysts: These are users that will run the code and perform 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 SubChannel module is developed using MOOSE and can itself be based on various MOOSE modules, as such the SRS for the SubChannel module is dependent upon the files listed at the beginning of this document. Any further assumptions or dependencies are outlined in the remainder of this section.

SCM is not a finite element code. It connects to the MOOSE framework through the external problem functionality, utilizing the framework's mesh-building capabilities to project its solution onto a compatible MOOSE mesh. The solution is computed using the PETSc library of objects and solvers. Any physics-based or mathematics-based assumptions in code simulations and code objects are detailed in their respective documentation pages.

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[BibTeX]
  2. ASME NQA-1. ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications. first edition, August 31 2009.[BibTeX]

Definitions and Acronyms

This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.

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

AcronymDescription
INLIdaho National Laboratory
LGPLGNU Lesser General Public License
MOOSEMultiphysics Object Oriented Simulation Environment
NQA-1Nuclear Quality Assurance Level 1
POSIXPortable Operating System Interface
SRSSoftware Requirement Specification

System Requirements

In general, the following is required for MOOSE-based development:

A POSIX compliant Unix-like operating system. This includes any modern Linux-based operating system (e.g., Ubuntu, Fedora, Rocky, etc.), or a Macintosh machine running either of the last two MacOS releases.

HardwareInformation
CPU Architecturex86_64, ARM (Apple Silicon)
Memory8 GB (16 GBs for debug compilation)
Disk Space30GB

LibrariesVersion / Information
GCC9.0.0 - 12.2.1
LLVM/Clang10.0.1 - 19
Intel (ICC/ICX)Not supported at this time
Python3.10 - 3.13
Python Packagespackaging pyaml jinja2

Functional Requirements

  • subchannel: Auxkernels
  • 20.1.1The system shall apply inlet boundary massflow conditions for a blocked/partially blocked inlet
  • 20.1.2The system shall apply inlet boundary massflow conditions
  • 20.1.3The system shall calculate linear heat rate on fuel pin surface
  • 20.1.4The system shall calculate a uniform massflow rate inlet boundary
  • subchannel: Ics
  • 20.2.1The system will calculate the geometric parameters for FCTF
  • 20.2.2The system shall calculate the flow area and wetted perimeter for a MARVEL-type microreactor core modeled in SCM
  • 20.2.3The system will apply initial massflow rate
  • 20.2.4The system will calculate the subchannel flow area for quadrilateral assemblies
  • 20.2.5The system will calculate the linear heat rate on subchannels/fuel-pins in a quadrilateral lattice
  • 20.2.6The system will calculate the wetted perimeter of subchannels in a quadrilateral lattice
  • 20.2.7The system will calculate the subchannel flow area for triangular assemblies
  • 20.2.8The system will calculate the linear heat rate on subchannels/fuel-pins in a triangular lattice
  • 20.2.9The system will calculate the linear heat rate on subchannels/fuel-pins in a triangular lattice, but with an axial power profile
  • 20.2.10The system will calculate the wetted perimeter of subchannels in a triangular lattice
  • subchannel: Mesh
  • 20.3.1The system will create a detailed mesh of the inter-wrapper for quadrilateral assemblies
  • 20.3.2The system will create a detailed mesh of the fuel pins for quadrilateral assemblies
  • 20.3.3The system will create a detailed mesh of the subchannels for quadrilateral assemblies (3x3)
  • 20.3.4The system will create a detailed mesh of the subchannels for quadrilateral assemblies (1x2)
  • 20.3.5The system will create a detailed mesh of the subchannels for quadrilateral assemblies (1x3)
  • 20.3.6The system will create a detailed mesh of the subchannels for quadrilateral assemblies (3x1)
  • 20.3.7The system will create a detailed mesh of the fuel pins for triangular assemblies
  • 20.3.8The system will create a detailed mesh of the subchannels in triangular assemblies
  • 20.3.9The system will create a mesh of the inter-wrapper for quadrilateral assemblies
  • 20.3.10The system will create a mesh of the subchannels for quadrilateral assemblies
  • 20.3.11The system shall check the minimum number of subchannels
  • 20.3.12The system will create a mesh of the fuel pins for quadrilateral assemblies
  • 20.3.13The system will create a mesh of the inter-wrapper for triangualar assemblies
  • 20.3.14The system will create a hexagonal duct mesh and a pin mesh for triangular assemblies
  • 20.3.15The system will create a hexagonal duct mesh for triangular assemblies
  • 20.3.16The system will create a subchannel mesh for triangular assemblies
  • subchannel: Multiapp
  • 20.4.1The system shall be able to solve a subchannel problem as a child application.
  • subchannel: Outputs
  • 20.5.1The system will print a variable on a plane in a quadrilateral assembly
  • subchannel: Postprocessors
  • 20.6.1The system will print a variable on a specific subchannel and height in quadrilateral assemblies
  • 20.6.2The system will test the user provided height
  • 20.6.3The system will print a variable on a specific subchannel and height in triangular assemblies
  • subchannel: Problems
  • 20.7.1The system will examine the tri subchannel solver for lead bismuth eutetic coolant
  • 20.7.2The system will examine the tri subchannel solver for lead coolant
  • 20.7.3The system will examine the subchannel solver for the EBR-II case
  • 20.7.4The system will examine the subchannel explicit solver for a 19pin liquid sodium cooled assembly
  • 20.7.5The system will examine the subchannel implicit solver for a 19pin liquid sodium cooled assembly
  • 20.7.6The system will examine the subchannel monolithic solver for a 19pin liquid sodium cooled assembly
  • 20.7.7The system will examine the subchannel full monolithic solver for a 19pin liquid sodium cooled assembly
  • 20.7.8The system will examine the coupling using SCM as main app
  • 20.7.9The system will examine the explicit interwrapper solver for quadrilateral assemblies
  • 20.7.10The system will examine the monolithic interwrapper solver for quadrilateral assemblies
  • 20.7.11The system will examine the monolitich staggered grid interwrapper solver for quadrilateral assemblies
  • 20.7.12The system will examine the explicit interwrapper solver for triangular assemblies
  • 20.7.13The system will examine the explicit interwrapper solver for triangular assemblies and side bypass
  • 20.7.14The system will examine the implicit interwrapper solver for triangular assemblies
  • 20.7.15The system will examine the monolithic interwrapper solver for triangular assemblies
  • 20.7.16The system will examine the monolithic staggered grif interwrapper solver for triangular assemblies
  • 20.7.17The system shall be able to solve a PSBT-type case with the subchannel solver using an explicit algorithm.
  • 20.7.18The system shall be able to solve a PSBT-type case with the subchannel solver using the non-default friction/mixing model.
  • 20.7.19The system shall be able to solve a PSBT-type case with the subchannel solver using an explicit algorithm and a staggered pressure formulation.
  • 20.7.20The system shall be able to solve a PSBT-type case with the subchannel solver using an implicit algorithm.
  • 20.7.21The system shall be able to solve a PSBT-type case with the subchannel solver using a monolithic algorithm.
  • 20.7.22The system shall be able to solve a PSBT-type case with the subchannel solver using a full-monolithic algorithm.
  • 20.7.23The system shall be able to solve a PSBT-type case with the subchannel solver using a full-monolithic algorithm and a staggered pressure formulation.
  • subchannel: Restart
  • 20.8.1The system shall be able to restart after a steady state solution
  • 20.8.2The system shall be able to restart after a transient solution
  • subchannel: Transfers
  • 20.9.1The system shall be able to transger the subchannel/pin solution onto a detailed mesh
  • 20.9.2The system shall be able to transger the interwrapper solution onto a detailed mesh

Usability Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

Performance Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

System Interfaces

No requirements of this type exist for this application, beyond those of its dependencies.

System Operations

Human System Integration Requirements

The SubChannel module is command line driven and conforms to all standard terminal behaviors. Specific human system interaction accommodations shall be a function of the end-user's terminal. MOOSE (and therefore the SubChannel module) does support optional coloring within the terminal's ability to display color, which may be disabled.

Maintainability

  • The latest working version (defined as the version that passes all tests in the current regression test suite) shall be publicly available at all times through the repository host provider.

  • Flaws identified in the system shall be reported and tracked in a ticket or issue based system. The technical lead will determine the severity and priority of all reported issues and assign resources at their discretion to resolve identified issues.

  • The software maintainers will entertain all proposed changes to the system in a timely manner (within two business days).

  • The core software in its entirety will be made available under the terms of a designated software license. These license terms are outlined in the LICENSE file alongside the SubChannel module source code. As a MOOSE physics module, the license for the SubChannel module is identical to that of the framework - that is, the LGPL version 2.1 license.

Reliability

The regression test suite will cover at least 87% of all lines of code within the SubChannel module at all times. Known regressions will be recorded and tracked (see Maintainability) to an independent and satisfactory resolution.

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:

Command Line FlagDescription of mode
-i <input_file>Normal execution mode
--split-mesh <splits>Read the mesh block splitting the mesh into two or more pieces for use in a subsequent run
--use-split(implies -i flag) Execute the simulation but use pre-split mesh files instead of the mesh from the input file
--yamlOutput all object descriptions and available parameters in YAML format
--jsonOutput all object descriptions and available parameters in JSON format
--syntaxOutput all registered syntax
--registryOutput all known objects and actions
--registry-hitOutput all known objects and actions in HIT format
--mesh-only (implies -i flag)Run only the mesh related tasks and output the final mesh that would be used for the simulation
--start-in-debugger <debugger>Start the simulation attached to the supplied debugger
commentnote

The list of system-modes may not be extensive as the system is designed to be extendable to end-user applications. The complete list of command line options for applications can be obtained by running the executable with zero arguments. See the command line usage.

Physical Characteristics

The SubChannel module is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the SubChannel module.

Environmental Conditions

Not Applicable

System Security

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

Information Management

The core framework and all modules in their entirety will be made publicly available on an appropriate repository hosting site. Day-to-day backups and security services will be provided by the hosting service. More information about MOOSE backups of the public repository on INL-hosted services can be found on the following page: GitHub Backups

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. The SubChannel module development team follows the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

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

Verification

The regression test suite will employ several verification tests using comparison against known analytical solutions, the method of manufactured solutions, and convergence rate analysis.