OpenPronghorn System Requirements Specification

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

note

This document serves as an addendum to Framework System Requirements Specification and captures information for SRS specific to the OpenPronghorn application.

Introduction

System Purpose

error:Missing Template Item: "system-purpose"

Summarize the reason(s) for the system being developed or modified.

The document must include the "system-purpose" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=system-purpose
Include text (in MooseDocs format) regarding the "system-purpose" template item here.
!template-end!

System Scope

error:Missing Template Item: "system-scope"

Delineate the following:

Identify the product(s) to be produced by name (Network Infrastructure, Host DBMS, Report Generator, HPC Server, etc.)
Explain what the product(s) will, and, if necessary, will not do.
Describe the application of the product being specified, including relevant benefits, objectives, and goals.

note

Be consistent with similar statements in higher level specifications (e.g., business requirements specification).

The document must include the "system-scope" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=system-scope
Include text (in MooseDocs format) regarding the "system-scope" template item here.
!template-end!

System Overview

System Context

The OpenPronghorn application 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. OpenPronghorn 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.

Usage of OpenPronghorn and other [!ac](MOOSE)-based applications.

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

System Functions

Since OpenPronghorn 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. OpenPronghorn is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.

User Characteristics

error:Missing Template Item: "user-characteristics"

Identify each type of user/operator/maintainer of the system (by function, location, type of device), the number in each group, and the nature of their use of the system.

The document must include the "user-characteristics" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=user-characteristics
Include text (in MooseDocs format) regarding the "user-characteristics" template item here.
!template-end!

Assumptions and Dependencies

The OpenPronghorn application is developed using MOOSE and is based on various modules, as such the SRS for OpenPronghorn 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.

error:Missing Template Item: "assumptions-and-dependencies"

List each of the factors that affect the requirements and should be taken into consideration for derivation of lower level requirements and design. These factors should include design inputs, design constraints, and installation considerations. Changes to these can affect the requirements in the specification. For example, an assumption may be that a specific operating system will be available on the hardware designated for the product. If, in fact, the operating system is not available, the specification would then have to change accordingly.

The document must include the "assumptions-and-dependencies" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=assumptions-and-dependencies
Include text (in MooseDocs format) regarding the "assumptions-and-dependencies" template item here.
!template-end!

References

ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.

BibTeX

@manual{ISO-systems-software,
    author = "24765:2010(E), ISO/IEC/IEEE",
    title = "Systems and software engineering---Vocabulary",
    edition = "First",
    year = "2010",
    month = "December 15"
}

RIS

TY  - GEN
AU  - 24765:2010(E), ISO/IEC/IEEE
TI  - Systems and software engineering—Vocabulary
PY  - 2010
ER  -

Plain Text

ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.

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

@manual{ASME-NQA-1-2008,
    author = "NQA-1, ASME",
    title = "ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications",
    orginization = "American Socieity of Mechanical Engineers",
    year = "2009",
    month = "August 31",
    edition = "First"
}

RIS

TY  - GEN
AU  - NQA-1, ASME
TI  - ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications
PY  - 2009
ER  -

Plain Text

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.

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

Acronym	Description
INL	Idaho National Laboratory
MOOSE	Multiphysics Object Oriented Simulation Environment
NQA-1	Nuclear Quality Assurance Level 1
POSIX	Portable Operating System Interface
SRS	Software 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.

Hardware	Information
CPU Architecture	x86_64, ARM (Apple Silicon)
Memory	8 GB (16 GBs for debug compilation)
Disk Space	30GB

Libraries	Version / Information
GCC	9.0.0 - 13.3.1
LLVM/Clang	14.0.6 - 19
Intel (ICC/ICX)	Not supported at this time
Python	3.10 - 3.13
Python Packages	packaging pyaml jinja2

Functional Requirements

open_pronghorn: Kepsilon
2.1.1The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant.
2.1.2The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant and YAP correction.
2.1.3The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant and quadratic non-linear model.
2.1.4The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant, quadratic non-linear model, and YAP correction.
2.1.5The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant and cubic non-linear model.
2.1.6The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Standard variant, cubic non-linear model, and YAP correction.
2.1.7The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant.
2.1.8The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant and YAP correction.
2.1.9The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant and quadratic non-linear model.
2.1.10The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant, quadratic non-linear model, and YAP correction.
2.1.11The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant and cubic non-linear model.
2.1.12The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardLowRe variant, cubic non-linear model, and YAP correction.
2.1.13The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant and Wolfstein two-layer flavor.
2.1.14The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant and NorrisReynolds two-layer flavor.
2.1.15The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, Wolfstein two-layer flavor, and YAP correction.
2.1.16The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, NorrisReynolds two-layer flavor, and YAP correction.
2.1.17The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, Wolfstein two-layer flavor, and quadratic non-linear model.
2.1.18The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, Wolfstein two-layer flavor, quadratic non-linear model, and YAP correction.
2.1.19The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, Wolfstein two-layer flavor, and cubic non-linear model.
2.1.20The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using StandardTwoLayer variant, Wolfstein two-layer flavor, cubic non-linear model, and YAP correction.
2.1.21The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant.
2.1.22The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant and YAP correction.
2.1.23The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant and quadratic non-linear model.
2.1.24The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant, quadratic non-linear model, and YAP correction.
2.1.25The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant and cubic non-linear model.
2.1.26The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Realizable variant, cubic non-linear model, and YAP correction.
2.1.27The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant and Wolfstein two-layer flavor.
2.1.28The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant and NorrisReynolds two-layer flavor.
2.1.29The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant and Xu two-layer flavor.
2.1.30The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Wolfstein two-layer flavor, and YAP correction.
2.1.31The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, NorrisReynolds two-layer flavor, and YAP correction.
2.1.32The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Xu two-layer flavor, and YAP correction.
2.1.33The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Wolfstein two-layer flavor, and quadratic non-linear model.
2.1.34The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, NorrisReynolds two-layer flavor, and quadratic non-linear model.
2.1.35The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Xu two-layer flavor, and quadratic non-linear model.
2.1.36The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Wolfstein two-layer flavor, quadratic non-linear model, and YAP correction.
2.1.37The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Xu two-layer flavor, quadratic non-linear model, and YAP correction.
2.1.38The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, Wolfstein two-layer flavor, and cubic non-linear model.
2.1.39The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using RealizableTwoLayer variant, NorrisReynolds two-layer flavor, and cubic non-linear model.
2.1.40The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using Standard variant.
2.1.41The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using Standard variant and Low-Re Gprime correction.
2.1.42The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using StandardLowRe variant.
2.1.43The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using StandardLowRe variant and Low-Re Gprime correction.
2.1.44The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using StandardTwoLayer variant.
2.1.45The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using StandardTwoLayer variant and Low-Re Gprime correction.
2.1.46The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using Realizable variant.
2.1.47The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using Realizable variant and Low-Re Gprime correction.
2.1.48The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using RealizableTwoLayer variant.
2.1.49The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers using RealizableTwoLayer variant and Low-Re Gprime correction.
2.1.50The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with bulk wall treatment.
2.1.51The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with turbulent buoyancy and compressibility corrections.
2.1.52The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel using low-Reynolds number production corrections.
2.1.53The system shall be able to solve turbulent lid-driven cavity flow using the k-epsilon turbulence model and reach converged results with segregated solvers with curvature corrections for production.
2.1.54The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using Newton equilibrium wall treatment.
2.1.55The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using incremental equilibrium wall functions.
2.1.56The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using linearized equilibrium wall functions.
2.1.57The system shall be able to solve fluid flow problems with k-epsilon turbulence model for a standard channel with linear FV discretization, and reach converged results with segregated solvers using non-equilibrium wall functions.

open_pronghorn: Kernels
2.2.1The system shall be able to solve a simple diffusion problem.

open_pronghorn: Wall Distance
2.3.1
The system shall be able to compute the distance from prescribed boundaries in meshes that are
1. replicated and
2. distributed.

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 OpenPronghorn application 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 OpenPronghorn) 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 OpenPronghorn application source code.

Reliability

error:Missing Template Item: "reliability"

Specify the system reliability requirements in quantitative terms, including the conditions under which the reliability requirements are to be met. This may also include the reliability apportionment model to support allocation of reliability values assigned to system functions for their share in achieving desired system reliability.

The document must include the "reliability" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=reliability
Include text (in MooseDocs format) regarding the "reliability" template item here.
!template-end!

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 Flag	Description 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
`--yaml`	Output all object descriptions and available parameters in YAML format
`--json`	Output all object descriptions and available parameters in JSON format
`--syntax`	Output all registered syntax
`--registry`	Output all known objects and actions
`--registry-hit`	Output 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

note

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 OpenPronghorn application is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the OpenPronghorn application.

Environmental Conditions

Not Applicable

System Security

MOOSE-based applications such as OpenPronghorn 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

error:Missing Template Item: "information-management"

Define the requirements for the system's management of information that it receives, generates, or exports. Examples include types and amounts of information the system is required to receive and store, any proprietary or other protections levied on the information the system deals with, and what backup and archiving requirements exist for the information.

The document must include the "information-management" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=information-management
Include text (in MooseDocs format) regarding the "information-management" template item here.
!template-end!

Polices and Regulations

error:Missing Template Item: "policies-and-regulations"

Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements, or constraints imposed by normal business practices. Examples of requirements include multilingual support, labor policies, protection of personnel information, and reports to a regulatory agency.

Specify health and safety criteria, including those basic to the design of the system, with respect to equipment characteristics, methods of operation, and environmental influences such as toxic systems and electromagnetic radiation.

The document must include the "policies-and-regulations" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=policies-and-regulations
Include text (in MooseDocs format) regarding the "policies-and-regulations" template item here.
!template-end!

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

Packaging, Handling, Shipping and Transportation

error:Missing Template Item: "packaging"

Define requirements imposed on the system to ensure that it can be packaged, handled, shipped, and transported within its intended operational context.

The document must include the "packaging" template item, this can be included by adding the following to the markdown file (sqa/open_pronghorn_srs.md):

!template! item key=packaging
Include text (in MooseDocs format) regarding the "packaging" template item here.
!template-end!

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.

Introduction
System Overview
References
Definitions and Acronyms
System Requirements
Verification