Misc System Requirements Specification
This template follows INL template TEM-135, "IT System Requirements Specification".
This document serves as an addendum to Framework System Requirements Specification and captures information for Software Requirement Specification (SRS) specific to the Misc module.
Introduction
System Purpose
The purpose of the MOOSE Misc module is to provide a set of models that support a variety of simulations performed using other MOOSE modules or MOOSE-based applications.
System Scope
The MOOSE Misc module is designed only to provide code modules that support the solution of physics models that are primarily defined by other MOOSE modules and MOOSE-based applications.
The Misc module provides several specializations of MOOSE classes that are used to support calculations performed in a variety of physics calculations. These include Kernel, AuxKernel, Material and Postprocessor classes that computing terms in diffusion equations, compute density, internal volume, and perform other similar functions.
System Overview
System Context
The Misc 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 Misc 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 Misc module and other MOOSE-based applications.
System Functions
Since the Misc 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 Misc 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 Misc module:
Misc module Developers: These are the core developers of the Misc 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 Misc 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 Misc 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 Misc module is developed using MOOSE and can itself be based on various MOOSE modules, as such the SRS for the Misc 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.
The Misc module has no constraints on hardware and software beyond those of the MOOSE framework. The Misc module provides access to a number of code objects that perform various computations. These objects each make their own physics-based assumptions, such as the units of the inputs and outputs. Those assumptions are described in the documentation for those individual objects.
References
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 |
| LGPL | GNU Lesser General Public License |
| 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 Portable Operating System Interface (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 - 12.2.1 |
| LLVM/Clang | 10.0.1 - 19 |
| Intel (ICC/ICX) | Not supported at this time |
| Python | 3.10 - 3.13 |
| Python Packages | packaging pyaml jinja2 |
Functional Requirements
- misc: Ad Arrhenius Material Property
- 9.1.1The system shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation while using the automatic differentiation system.
- 9.1.2The system shall provide perfect derivatives when using ADArrheniusMaterialProperty.
- misc: Arrhenius Material Property
- 9.2.1The system material shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation.
- misc: Coupled Directional Mesh Height Interpolation
- 9.3.1The system shall linearly scale a variable based on the local position relative to the maximum and minimum mesh coordinate in a user-specified direction.
- misc: Dynamic Loading
- 9.4.1The system shall be able to dynamically load a multiapp from a dynamic library.
- 9.4.2The system shall be able to dynamically load a multiapp using the library name, to select a compiling optimization level for example.
- 9.4.3The system shall report an error if the type of application to dynamically load is not included in the dynamic library.
- 9.4.4The system shall throw an error message when the library name is manually supplied but does not supply the right application.
- 9.4.5The system shall throw an error when no path or environment variable is supplied for dynamic loading.
- 9.4.6Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library name inferred from the module or application name.
- 9.4.7Any MOOSE application shall be able to dynamically load a module or application and properly register the provided objects.
- 9.4.8Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library specified.
- 9.4.9Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library name inferred from the module or application name.
- 9.4.10Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library specified.
- 9.4.11Any MOOSE application shall be able to dynamically load a module or application and register only select objects form the module or application.
- 9.4.12Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not among selected objects for registration.
- 9.4.13Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not provided by the module or application.
- 9.4.14The system shall throw an error when trying to dynamically load a module or application that does not exist.
- misc: Fracture Flow
- 9.5.1The system shall be able to simulate convective flow through lower-dimensional fractures embedded in a higher-dimensional solid
- misc: Kernels
- 9.6.1Thermo diffusion shall reproduce an analytical solution
- 9.6.2AD thermo diffusion shall reproduce an analytical solution
- 9.6.3AD thermo diffusion shall work with material properties and the Jacobian shall be beautiful
- misc: Sensor Postprocessor
- 9.7.1The system process a signal and send out a general sensor-mediated signal for transient case.
- 9.7.2The system process a signal and send out a general sensor-mediated signal for steady-state case.
- 9.7.3The system process a signal and send out a thermocouple sensor-mediated signal for transient case.
- 9.7.4The system process a signal and send out a thermocouple sensor-mediated signal for steady-state case.
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 Misc 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 Misc 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 Misc module source code. As a MOOSE physics module, the license for the Misc module is identical to that of the framework - that is, the GNU Lesser General Public License (LGPL) version 2.1 license.
Reliability
The regression test suite will cover at least 55% of all lines of code within the Misc 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 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 |
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 Misc module is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the Misc module.
Environmental Conditions
Not Applicable
System Security
MOOSE-based applications such as the Misc 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 Misc 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 Misc module source code. However, some MOOSE-based applications that use the Misc 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.