Thermal Hydraulics 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 Thermal Hydraulics application.
- Framework System Requirements Specification
- Fluid Properties System Requirements Specification
- Heat Conduction System Requirements Specification
- Navier Stokes System Requirements Specification
- Misc System Requirements Specification
- Ray Tracing System Requirements Specification
- Reconstructed Discontinuous Galerkin System Requirements Specification
Introduction
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 Overview
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 Thermal Hydraulics application is developed using MOOSE and is based on various modules, as such the SRS for Thermal Hydraulics is dependent upon the files listed at the beginning of this document.
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 |
---|---|
FEM | Finite Element Method |
INL | Idaho National Laboratory |
JFNK | Jacobian-Free Newton-Krylov |
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
- A Portable Operating System Interface (POSIX) compliant Unix including the two most recent versions of MacOS and most current versions of Linux. - 4 GB of RAM for optimized compilation (8 GB for debug compilation), 2 GB per core execution - 100 GB disk space - C++17 compatible compiler (GCC, Clang) - Python 3.7+ - Git
Functional Requirements
- thermal_hydraulics: Actions
- 15.1.1
- thermal_hydraulics: Auxkernels
- 15.2.1The system shall compute convective heat flux between fluid and wall temperature for 1-phase flow
- 15.2.2
- 15.2.3
- 15.2.4
- 15.2.5
- 15.2.6
- 15.2.7
- thermal_hydraulics: Base
- 15.3.1The system shall allow nesting components into groups in input files
- 15.3.2
- 15.3.3
- thermal_hydraulics: Closures
- 15.4.1
- 15.4.2
- 15.4.3
- 15.4.4
- thermal_hydraulics: Components
- 15.5.1
- 15.5.2
- 15.5.3The system shall report an error if the FreeBoundary component is used.
- 15.5.4The system shall report an error if the GateValve component is used.
- 15.5.5The system shall report an error if the SolidWall component is used.
- 15.5.6The system shall report an error if the JunctionOneToOne component is used.
- 15.5.7The system shall report an error if the HeatGeneration component is used.
- 15.5.8The system shall report an error if the HeatSourceVolumetric component is used.
- 15.5.9The system shall report an error if the PrescribedReactorPower component is used.
- 15.5.10
- 15.5.11
- 15.5.12
- 15.5.13
- 15.5.14
- 15.5.15
- 15.5.16
- 15.5.17
- 15.5.18
- 15.5.19
- 15.5.20
- 15.5.21
- 15.5.22
- 15.5.23
- 15.5.24
- 15.5.25
- 15.5.26
- 15.5.27
- 15.5.28
- 15.5.29
- 15.5.30
- 15.5.31The system shall provide the heat source shape when power density is supplied
- 15.5.32
- 15.5.33
- 15.5.34
- 15.5.35The system shall provide the heat source shape for a cylindrical heat structure when power component and power shape function are supplied
- 15.5.36The system shall provide the heat source shape for a plate heat structure when power component and power shape function are supplied
- 15.5.37
- 15.5.38
- 15.5.39
- 15.5.40
- 15.5.41
- 15.5.42
- 15.5.43
- 15.5.44
- 15.5.45
- 15.5.46The system shall be able to couple two 2D cylindrical heat structures.
- 15.5.47The system shall be able to couple two 2D plate heat structures.
- 15.5.48The system shall report an error for HeatStructure2DCoupler when
- the provided heat structure boundary does not exist.
- the types of the coupled heat structures do not match.
- the types of either coupled heat structure is invalid.
- the boundary meshes are not coincident.
- the parallel mesh type is distributed.
- 15.5.49
- 15.5.50
- 15.5.51
- 15.5.52
- 15.5.53
- 15.5.54
- 15.5.55
- 15.5.56
- 15.5.57
- 15.5.58
- 15.5.59
- 15.5.60
- 15.5.61
- 15.5.62
- 15.5.63
- 15.5.64
- 15.5.65
- 15.5.66
- 15.5.67
- 15.5.68
- 15.5.69
- 15.5.70
- 15.5.71
- 15.5.72
- 15.5.73
- 15.5.74
- 15.5.75
- 15.5.76
- 15.5.77
- 15.5.78
- 15.5.79
- 15.5.80
- 15.5.81
- 15.5.82
- 15.5.83
- 15.5.84
- 15.5.85
- 15.5.86
- 15.5.87
- 15.5.88
- 15.5.89
- 15.5.90
- 15.5.91
- 15.5.92
- 15.5.93
- 15.5.94
- 15.5.95
- 15.5.96The system shall conserve energy when using HeatTransferFromHeatStructure3D1Phase.
- 15.5.97The system shall allow to connect multiple flow channels to a single boundary in HeatTransferFromHeatStructure3D1Phase.
- 15.5.98The system shall allow to connect flow channels that have negative orientation to a HeatTransferFromHeatStructure3D1Phase component.
- 15.5.99The system shall throw an error if a flow channel connected to a HeatTransferFromHeatStructure3D1Phase component is not a FlowChannel1Phase.
- 15.5.100The system shall throw an error if a flow channel connected to a HeatTransferFromHeatStructure3D1Phase component is not aligned with the x-, y-, or z- axis.
- 15.5.101The system shall throw an error if the heat structure connected to a HeatTransferFromHeatStructure3D1Phase component is not a HeatStructureFromFile3D component.
- 15.5.102The system shall throw an error if the heat structure boundary connected to a HeatTransferFromHeatStructure3D1Phase component doesn't exist.
- 15.5.103The system shall throw an error if the flow channels connected to a HeatTransferFromHeatStructure3D1Phase component are not aligned with the same axis.
- 15.5.104The system shall throw an error if the flow channels connected to a HeatTransferFromHeatStructure3D1Phase component don't have the same lnumber of elements.
- 15.5.105The system shall throw an error if the flow channels connected to a HeatTransferFromHeatStructure3D1Phase component don't have the same length.
- 15.5.106The system shall correctly compute Jacobians for HeatTransferFromHeatStructure3D1Phase.
- 15.5.107
- 15.5.108
- 15.5.109
- 15.5.110
- 15.5.111
- 15.5.112
- 15.5.113
- 15.5.114
- 15.5.115
- 15.5.116
- 15.5.117
- 15.5.118
- 15.5.119
- 15.5.120
- 15.5.121
- 15.5.122
- 15.5.123
- 15.5.124
- 15.5.125
- 15.5.126
- 15.5.127
- 15.5.128
- 15.5.129
- 15.5.130
- 15.5.131
- 15.5.132
- 15.5.133
- 15.5.134
- 15.5.135
- 15.5.136
- 15.5.137
- 15.5.138
- 15.5.139
- 15.5.140
- 15.5.141
- 15.5.142
- 15.5.143
- 15.5.144
- 15.5.145
- 15.5.146
- 15.5.147
- 15.5.148
- 15.5.149
- 15.5.150
- 15.5.151
- 15.5.152
- 15.5.153
- 15.5.154
- 15.5.155
- 15.5.156
- 15.5.157
- 15.5.158
- 15.5.159
- 15.5.160
- 15.5.161
- 15.5.162
- 15.5.163
- 15.5.164
- 15.5.165The system shall allow for controlling the pump head
- 15.5.166The system shall allow for controlling the pump head
- 15.5.167
- 15.5.168The system shall conserve mass and energy when using ShaftConnectedCompressor1Phase.
- 15.5.169The system shall be able to model a compressor with ShaftConnectedCompressor1Phase.
- 15.5.170The system shall allow ShaftConnectedCompressor1Phase to run with a zero shaft speed.
- 15.5.171The system shall correctly compute Jacobians for ShaftConnectedCompressor1Phase.
- 15.5.172The system shall throw an error if ShaftConnectedCompressor1Phase is not connected to a shaft component.
- 15.5.173The system shall throw an error if the initial shaft speed is not provided and the application is not restarting.
- 15.5.174The system shall throw an error if ShaftConnectedMotor is not connected to a shaft component.
- 15.5.175The system shall be able to model a motor connected to a shaft.
- 15.5.176The system shall be able to execute a restart a simulation involving a shaft-connected motor.
- 15.5.177The system shall allow the torque of a shaft-connected motor to be controlled.
- 15.5.178The system shall allow the inertia of a shaft-connected motor to be controlled.
- 15.5.179The system shall conserve mass and energy when using ShaftConnectedPump1Phase.
- 15.5.180The system shall be able to model a pump with ShaftConnectedPump1Phase.
- 15.5.181The system shall be able to model a pump coastdown with ShaftConnectedPump1Phase.
- 15.5.182The system shall correctly compute Jacobians for ShaftConnectedPump1Phase.
- 15.5.183The system shall throw an error if ShaftConnectedPump1Phase is not connected to a shaft component.
- 15.5.184
- 15.5.185The system shall conserve mass and energy when using ShaftConnectedTurbine1Phase.
- 15.5.186The system shall be able to model a turbine with ShaftConnectedTurbine1Phase.
- 15.5.187The system shall be able to model a turbine startup with ShaftConnectedTurbine1Phase.
- 15.5.188The system shall correctly compute Jacobians for ShaftConnectedTurbine1Phase.
- 15.5.189The system shall throw an error if ShaftConnectedTurbine1Phase is not connected to a shaft component.
- 15.5.190
- 15.5.191
- 15.5.192
- 15.5.193
- 15.5.194
- 15.5.195
- 15.5.196The system shall report an error if the SupersonicInlet component is used.
- 15.5.197
- 15.5.198
- 15.5.199
- 15.5.200
- 15.5.201
- 15.5.202
- 15.5.203
- 15.5.204
- 15.5.205
- 15.5.206
- 15.5.207
- 15.5.208
- 15.5.209
- 15.5.210
- thermal_hydraulics: Controls
- 15.6.1
- 15.6.2
- 15.6.3
- 15.6.4
- 15.6.5
- 15.6.6
- 15.6.7The system shall provide a control that evaluates a parsed function
- 15.6.8
- 15.6.9
- 15.6.10
- 15.6.11
- 15.6.12
- 15.6.13
- 15.6.14
- 15.6.15
- 15.6.16
- 15.6.17The system shall provide a unit trip component that report true if the trip condition was met and false otherwise.
- 15.6.18The system shall provide a unit trip component that stays in tripped state after the trip happened.
- 15.6.19The system shall report an error when an unit trip condition does not evaluate as boolean value.
- thermal_hydraulics: Functions
- 15.7.1
- 15.7.2
- 15.7.3
- 15.7.4
- 15.7.5
- 15.7.6
- 15.7.7
- 15.7.8
- thermal_hydraulics: Jacobians
- 15.8.1
- 15.8.2
- 15.8.3
- 15.8.4
- 15.8.5
- 15.8.6
- 15.8.7
- 15.8.8
- 15.8.9
- 15.8.10
- 15.8.11
- 15.8.12
- 15.8.13
- 15.8.14
- 15.8.15
- 15.8.16
- 15.8.17
- 15.8.18
- 15.8.19
- 15.8.20
- 15.8.21
- 15.8.22
- 15.8.23
- 15.8.24
- 15.8.25
- 15.8.26
- 15.8.27
- 15.8.28
- 15.8.29
- 15.8.30
- 15.8.31
- 15.8.32
- 15.8.33
- 15.8.34
- 15.8.35
- 15.8.36
- 15.8.37
- thermal_hydraulics: Materials
- 15.9.1
- 15.9.2
- 15.9.3
- 15.9.4
- 15.9.5
- 15.9.6
- 15.9.7
- 15.9.8
- 15.9.9
- 15.9.10
- 15.9.11
- 15.9.12
- 15.9.13
- 15.9.14
- 15.9.15
- 15.9.16
- 15.9.17
- 15.9.18
- 15.9.19
- 15.9.20
- 15.9.21
- 15.9.22
- 15.9.23
- thermal_hydraulics: Misc
- 15.10.1
- 15.10.2
- 15.10.3
- 15.10.4
- 15.10.5The system shall be able to produce an exodus file for setting initial conditions in flow channels
- 15.10.6The system shall be able to use an exodus file for setting initial conditions in flow channels
- 15.10.7The system shall report an error when a block is non found in the restart ExodusII file
- 15.10.8The system shall be able to produce an exodus file for setting initial conditions in heat structures
- 15.10.9The system shall be able to use an exodus file for setting initial conditions in heat structures
- 15.10.10The system shall be able to produce an exodus file for setting initial conditions in 3D heat structures
- 15.10.11The system shall be able to use an exodus file for setting initial conditions in 3D heat structures
- 15.10.12The system shall be able to produce an exodus file for setting initial conditions in volume junctions
- 15.10.13The system shall be able to use an exodus file for setting initial conditions in volume junctions
- 15.10.14The system shall be able to produce an exodus file for setting initial conditions in heat transfer from 3D heat structures
- 15.10.15The system shall be able to use an exodus file for setting initial conditions in heat transfer from 3D heat structures
- 15.10.16The system shall be able to produce an exodus file for setting initial conditions in shaft
- 15.10.17The system shall be able to use an exodus file for setting initial conditions in shaft
- 15.10.18The system shall be able to produce an exodus file for setting initial conditions in volume junctions
- 15.10.19The system shall be able to use an exodus file for setting initial conditions in volume junctions
- 15.10.20
- 15.10.21
- 15.10.22
- 15.10.23
- 15.10.24
- 15.10.25
- 15.10.26The system shall uniform refine mesh when specifid on the command line
- thermal_hydraulics: Output
- 15.11.1
- 15.11.2
- thermal_hydraulics: Postprocessors
- 15.12.1
- 15.12.2
- 15.12.3The system should report an error when users set subdomain-restricted RZ-symmtrical THM-specific objects on RZ-subdomains.
- 15.12.4
- 15.12.5The system should error out when users set boundary-restricted RZ-symmtrical THM-specific objects on RZ-subdomains.
- 15.12.6
- 15.12.7
- 15.12.8
- 15.12.9
- 15.12.10
- 15.12.11
- 15.12.12
- 15.12.13
- 15.12.14
- 15.12.15
- 15.12.16The system shall provide a post-processor to retrieve the torque and moment of inertia from a shaft-connected component.
- 15.12.17
- 15.12.18The system shall compute specific impulse from conditions on a boundary
- thermal_hydraulics: Problems
- 15.13.1
- 15.13.2
- 15.13.3The system shall be able to model an open Brayton cycle
- for a few time steps, and
- for a long duration.
- 15.13.4The system shall be able to model a closed Brayton cycle
- for a few time steps, and
- for a long duration.
- 15.13.5
- 15.13.6
- 15.13.7The system shall produce an accurate solution to the Lax shock tube benchmark problem
- using an explicit temporal discretization, and
- using an implicit temporal discretization.
- 15.13.8
- 15.13.9
- 15.13.10
- 15.13.11
- 15.13.12
- 15.13.13
- 15.13.14
- 15.13.15
- 15.13.16
- 15.13.17
- 15.13.18
- 15.13.19
- thermal_hydraulics: Scalarkernels
- 15.14.1
- 15.14.2
- thermal_hydraulics: Userobjects
- 15.15.1
- 15.15.2
- 15.15.3The system shall allow computing changes in channel flow areas from deformation.
- thermal_hydraulics: Utils
- 15.16.1
- 15.16.2
- 15.16.3
- 15.16.4
- 15.16.5
- 15.16.6
- thermal_hydraulics: Vectorpostprocessors
- 15.17.1The system shall provide a vector post-processor to sample regular material properties in one or more blocks.
- 15.17.2The system shall provide a vector post-processor to sample AD material properties in one or more blocks.
- 15.17.3The system shall report an error if a non-existent material property is requested for the block material property sampler vector post-processor.
- 15.17.4
Usability Requirements
Performace Requirements
System Interfaces
System Operations
Human System Integration Requirements
MOOSE is a command line driven application which conforms to all standard terminal behaviors. Specific human system interaction accommodations shall be a function of the end-user's terminal. MOOSE does support optional coloring within the terminal's ability to display color, which may be disabled.
Maintainablity
- 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 his or her 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 framework in its entirety will be made publicly available under the GNU Lesser General Public License (LGPL) version 2.0 license.
Reliability
The regression test suite will cover at least 80% of all lines of code at all times. Known regressions will be recorded and tracked (see Maintainablity) 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 | (inplies -i flag) Execute the 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.
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 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.
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.