Thermal Hydraulics System Design Description
This template follows INL template TEM-140, "IT System Design Description."
This document serves as an addendum to Framework System Design Description and captures information for Software Design Description (SDD) specific to the Thermal Hydraulics application.
Introduction
Frameworks are a software development construct aiming to simplify the creation of specific classes of applications through abstraction of low-level details. The main object of creating a framework is to provide an interface to application developers that saves time and provides advanced capabilities not attainable otherwise. The MOOSE, mission is just that: provide a framework for engineers and scientists to build state-of-the-art, computationally scalable finite element based simulation tools.
MOOSE was conceived with one major objective: to be as easy and straightforward to use by scientists and engineers as possible. MOOSE is meant to be approachable by non-computational scientists who have systems of PDEs they need to solve. Every single aspect of MOOSE was driven by this singular principle from the build system to the API to the software development cycle. At every turn, decisions were made to enable this class of users to be successful with the framework. The pursuit of this goal has led to many of the unique features of MOOSE:
A streamlined build system
An API aimed at extensible
Straightforward APIs providing sensible default information
Integrated, automatic, and rigorous testing
Rapid, continuous integration development cycle
Codified, rigorous path for contributing
Applications are modular and composable
Each of these characteristics is meant to build trust in the framework by those attempting to use it. For instance, the build system is the first thing potential framework users come into contact with when they download a new software framework. Onerous dependency issues, complicated, hard to follow instructions or build failure can all result in a user passing on the platform. Ultimately, the decision to utilize a framework comes down to whether or not you trust the code in the framework and those developing it to be able to support your desired use-case. No matter the technical capabilities of a framework, without trust users will look elsewhere. This is especially true of those not trained in software development or computational science.
Developing trust in a framework goes beyond utilizing "best practices" for the code developed, it is equally important that the framework itself is built upon tools that are trusted. For this reason, MOOSE relies on a well-established code base of libMesh and PETSc. The libMesh library provides foundational capability for the finite element method and provides interfaces to leading-edge numerical solution packages such as PETSc.
With these principles in mind, an open source, massively parallel, finite element, multiphysics framework has been conceived. MOOSE is an on-going project started in 2008 aimed toward a common platform for creation of new multiphysics tools. This document provides design details pertinent to application developers as well as framework developers.
Use Cases
The MOOSE Framework is targeted at two main groups of actors: Developers and Users. Developers are the main use case. These are typically students and professionals trained in science and engineering fields with some level of experience with coding but typically very little formal software development training. The other user group is Users. Those who intend to use an application built upon the framework without writing any computer code themselves. Instead they may modify or create input files for driving a simulation, run the application, and analyze the results. All interactions through MOOSE are primarily through the command-line interface and through a customizable block-based input file.
System Purpose
The Software Design Description provided here is description of each object in the system. The pluggable architecture of the framework makes MOOSE and MOOSE-based applications straightforward to develop as each piece of end-user (developer) code that goes into the system follows a well-defined interface for the underlying systems that those object plug into. These descriptions are provided through developer-supplied "markdown" files that are required for all new objects that are developed as part of the framework, modules and derivative applications. More information about the design documentation can be found in Documenting MOOSE.
System Scope
The purpose of this software is to provide several libraries that can be used to build an application based upon the framework. Additionally, several utilities are provided for assisting developers and users in end-to-end FEM analysis. A brief overview of the major components are listed here:
Component | Description |
---|---|
framework library | The base system from which all MOOSE-based applications are created |
module libraries | Optional "physics" libraries that may be used in an application to provide capability |
build system | The system responsible for creating applications for a series of libraries and applications |
test harness | The extendable testing system for finding, scheduling, running, and reporting regression tests |
"peacock" | The graphical user interface (GUI) for building input files, executing applications, and displaying results |
MooseDocs | The extendable markdown system for MOOSE providing common documentation and requirements enforcement |
"stork" | The script and templates for generating a new MOOSE-based application ready for building and testing |
examples | A set of complete applications demonstrating the use of MOOSE's pluggable systems |
tutorials | Step by step guides to building up an application using MOOSE's pluggable systems |
unit | An application for unit testing individual classes or methods of C++ code |
Dependencies and Limitations
The MOOSE platform has several dependencies on other software packages and has scope that is constantly evolving based upon funding, resources, priorities, and lab direction. However, the software is open-source and many features and even bugs can be offloaded to developers with appropriate levels of knowledge and direction from the main design team. The primary list of software dependencies is listed below. This list is not meant to be exhaustive. Individual operating systems may require specific packages to be installed prior to using MOOSE, which can be found on the Install MOOSE pages.
Software Dependency | Description |
---|---|
libMesh | Finite Element Library and I/O routines |
PETSc | Solver Package |
hypre | Multigrid Preconditioner |
MPI | A distributed parallel processing library (MPICH) |

Figure 1: A diagram of the MOOSE code platform.
References
Definitions and Acronyms
This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.
Definitions
- Pull (Merge) Request: A proposed change to the software (e.g. usually a code change, but may also include documentation, requirements, design, and/or testing). - Baseline: A specification or product (e.g., project plan, maintenance and operations (M&O) plan, requirements, or design) that has been formally reviewed and agreed upon, that thereafter serves as the basis for use and further development, and that can be changed only by using an approved change control process (NQA-1, 2009). - Validation: Confirmation, through the provision of objective evidence (e.g., acceptance test), that the requirements for a specific intended use or application have been fulfilled (24765:2010(E), 2010). - 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 |
---|---|
API | Application Programming Interface |
DOE-NE | Department of Energy, Nuclear Energy |
FE | finite element |
FEM | Finite Element Method |
GUI | graphical user interface |
HIT | Hierarchical Input Text |
HPC | High Performance Computing |
I/O | Input/Output |
INL | Idaho National Laboratory |
MOOSE | Multiphysics Object Oriented Simulation Environment |
MPI | Message Passing Interface |
PDEs | partial differential equations |
SDD | Software Design Description |
Design Stakeholders and Concerns
Design Stakeholders
Stakeholders for MOOSE include several of the funding sources including Department of Energy, Nuclear Energy (DOE-NE) and the INL. However, Since MOOSE is an open-source project, several universities, companies, and foreign governments have an interest in the development and maintenance of the MOOSE project.
Stakeholder Design Concerns
Concerns from many of the stakeholders are similar. These concerns include correctness, stability, and performance. The mitigation plan for each of these can be addressed. For correctness, MOOSE development requires either regression or unit testing for all new code added to the repository. The project contains several comparisons against analytical solutions where possible and also other verification methods such as MMS. For stability, MOOSE maintains multiple branches to incorporate several layers of testing both internally and for dependent applications. Finally, performance tests are also performed as part of the the normal testing suite to monitor code change impacts to performance.
System Design
The MOOSE framework itself is composed of a wide range of pluggable systems. Each system is generally composed of a single or small set of C++ objects intended to be specialized by a Developer to solve a specific problem. To accomplish this design goal, MOOSE uses several modern object-oriented design patterns. The primary overarching pattern is the "Factory Pattern". Users needing to extend MOOSE may inherit from one of MOOSE's systems to providing an implementation meeting his or her needs. The design of each of these systems is documented on the mooseframework.org wiki in the Tutorial section. Additionally, up-to-date documentation extracted from the source is maintained on the the mooseframework.org documentation site after every successful merge to MOOSE's stable branch. After these objects are created, the can be registered with the framework and used immediately in a MOOSE input file.
System Structure
The MOOSE framework architecture consists of a core and several pluggable systems. The core of MOOSE consists of a number of key objects responsible for setting up and managing the user-defined objects of a finite element simulation. This core set of objects has limited extendability and exist for every simulation configuration that the framework is capable of running.
Adaptivity
Adaptivity/Indicators
Adaptivity/Markers
AuxKernels
AuxKernels/MatVecRealGradAuxKernel
AuxKernels/MaterialVectorAuxKernel
AuxKernels/MaterialVectorGradAuxKernel
AuxScalarKernels
AuxVariables
AuxVariables/MultiAuxVariables
BCs
BCs/CavityPressure
BCs/CoupledPressure
BCs/InclinedNoDisplacementBC
BCs/Periodic
BCs/Pressure
Bounds
Closures
Components
Constraints
Contact
ControlLogic
Controls
CoupledHeatTransfers
Covariance
DGKernels
Dampers
Debug
Debug/MaterialDerivativeTest
DeprecatedBlock
DiracKernels
Distributions
DomainIntegral
Executioner
Executioner/Adaptivity
Executioner/Predictor
Executioner/Quadrature
Executioner/TimeIntegrator
Executioner/TimeStepper
Executors
FVBCs
FVInterfaceKernels
FVKernels
FluidPropertiesInterrogator
Functions
GeochemicalModelInterrogator
GlobalParams
GrayDiffuseRadiation
HeatStructureMaterials
ICs
ICs/PolycrystalICs
ICs/PolycrystalICs/BicrystalBoundingBoxIC
ICs/PolycrystalICs/BicrystalCircleGrainIC
ICs/PolycrystalICs/PolycrystalColoringIC
ICs/PolycrystalICs/PolycrystalRandomIC
ICs/PolycrystalICs/PolycrystalVoronoiVoidIC
ICs/PolycrystalICs/Tricrystal2CircleGrainsIC
InterfaceKernels
Kernels
Kernels/CHPFCRFFSplitKernel
Kernels/DynamicTensorMechanics
Kernels/HHPFCRFFSplitKernel
Kernels/PFCRFFKernel
Kernels/PolycrystalElasticDrivingForce
Kernels/PolycrystalKernel
Kernels/PolycrystalStoredEnergy
Kernels/PoroMechanics
Kernels/RigidBodyMultiKernel
Kernels/TensorMechanics
Materials
Mesh
Mesh/Partitioner
Modules
Modules/CompressibleNavierStokes
Modules/FluidProperties
Modules/HeatConduction
Modules/HeatConduction/ThermalContact
Modules/HeatConduction/ThermalContact/BC
Modules/IncompressibleNavierStokes
Modules/NavierStokesFV
Modules/Peridynamics
Modules/Peridynamics/Mechanics
Modules/Peridynamics/Mechanics/GeneralizedPlaneStrain
Modules/Peridynamics/Mechanics/Master
Modules/PhaseField
Modules/PhaseField/Conserved
Modules/PhaseField/DisplacementGradients
Modules/PhaseField/EulerAngles2RGB
Modules/PhaseField/GrainGrowth
Modules/PhaseField/GrandPotential
Modules/PhaseField/Nonconserved
Modules/PorousFlow
Modules/PorousFlow/BCs
Modules/TensorMechanics
Modules/TensorMechanics/CohesiveZoneMaster
Modules/TensorMechanics/DynamicMaster
Modules/TensorMechanics/GeneralizedPlaneStrain
Modules/TensorMechanics/GlobalStrain
Modules/TensorMechanics/LineElementMaster
Modules/TensorMechanics/Master
Modules/TensorMechanics/MaterialVectorBodyForce
MortarGapHeatTransfer
MultiApps
NodalKernels
NodalNormals
Outputs
PorousFlowBasicTHM
PorousFlowFullySaturated
PorousFlowUnsaturated
Postprocessors
Preconditioning
Problem
RayBCs
RayKernels
ReactionNetwork
ReactionNetwork/AqueousEquilibriumReactions
ReactionNetwork/SolidKineticReactions
Reporters
Samplers
ScalarKernels
SpatialReactionSolver
StochasticTools
Surrogates
ThermalContact
TimeDependentReactionSolver
TimeIndependentReactionSolver
Trainers
Transfers
UserObjects
Variables
Variables/CHPFCRFFSplitVariables
Variables/HHPFCRFFSplitVariables
Variables/PFCRFFVariables
Variables/PolycrystalVariables
VectorPostprocessors
XFEM
The MooseApp is the top-level object used to hold all of the other objects in a simulation. In a normal simulation a single MooseApp object is created and "run()". This object uses it's Factory objects to build user defined objects which are stored in a series of Warehouse objects and executed. The Finite Element data is stored in the Systems and Assembly object while the domain information (the Mesh) is stored in the Mesh object. A series of threaded loops are used to run parallel calculations on the objects created and stored within the warehouses.
MOOSE's pluggable systems are documented on the mooseframework.org wiki. Each of these systems has set of defined polymorphic interfaces and are designed to accomplish a specific task within the simulation. The design of these systems is fluid and is managed through agile methods and ticket request system on the Github.org website.
Data Design and Control
At a high level, the system is designed to process Hierarchical Input Text (HIT) input files to construct several objects that will constitute an FE simulation. Some of the objects in the simulation may in turn load other file-based resources to complete the simulation. Examples include meshes or data files. The system will then assemble systems of equations and solve them using the libraries of the Code Platform. The system can then output the solution in one or more supported output formats commonly used for visualization.
Human-Machine Interface Design
MOOSE is a command-line driven program. All interaction with MOOSE and MOOSE-based codes is ultimately done through the command line. This is typical for HPC applications that use the MPI interface for running on super computing clusters. Optional GUIs may be used to assist in creating input files and launching executables on the command line.
System Design Interface
All external system interaction is performed either through file Input/Output (I/O) or through local Application Programming Interface (API) calls. Neither the framework, nor the modules are designed to interact with any external system directly through remote procedure calls. Any code to code coupling performed using the framework are done directly through API calls either in a static binary or after loading shared libraries.
Security Structure
The framework does not require any elevated privileges to operate and does not run any stateful services, daemons or other network programs. Distributed runs rely on the MPI library.
Requirements Cross-Reference
- thermal_hydraulics: ConvectiveHeatFlux1PhaseAux
- 15.2.1The system shall compute convective heat flux between fluid and wall temperature for 1-phase flow
Specification(s): test
Design: ConvectiveHeatFlux1PhaseAux
Issue(s): #60
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: ComponentGroup
- 15.3.1The system shall allow nesting components into groups in input files
Specification(s): test
Design: ComponentGroup
Issue(s): #94
Collection(s): FUNCTIONAL
Type(s): RunApp
- thermal_hydraulics: FreeBoundary
- 15.5.3The system shall report an error if the FreeBoundary component is used.
Specification(s): free_boundary
Design: FreeBoundary
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: GateValve
- 15.5.4The system shall report an error if the GateValve component is used.
Specification(s): gate_valve
Design: GateValve
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: SolidWall
- 15.5.5The system shall report an error if the SolidWall component is used.
Specification(s): solid_wall
Design: SolidWall
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: JunctionOneToOne
- 15.5.6The system shall report an error if the JunctionOneToOne component is used.
Specification(s): junction_one_to_one
Design: JunctionOneToOne
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: HeatGeneration
- 15.5.7The system shall report an error if the HeatGeneration component is used.
Specification(s): heat_generation
Design: HeatGeneration
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: HeatSourceVolumetric
- 15.5.8The system shall report an error if the HeatSourceVolumetric component is used.
Specification(s): heat_source_volumetric
Design: HeatSourceVolumetric
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: PrescribedReactorPower
- 15.5.9The system shall report an error if the PrescribedReactorPower component is used.
Specification(s): prescribed_reactor_power
Design: PrescribedReactorPower
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: HeatStructure2DCoupler
- 15.5.46The system shall be able to couple two 2D cylindrical heat structures.
Specification(s): cylindrical
Design: HeatStructure2DCoupler
Issue(s): #19851
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.47The system shall be able to couple two 2D plate heat structures.
Specification(s): plate
Design: HeatStructure2DCoupler
Issue(s): #19851
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 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.
Specification(s): error_reporting/missing_boundary, error_reporting/type_mismatch, error_reporting/invalid_hs_type, error_reporting/mesh_mismatch, error_reporting/distributed_mesh
Design: HeatStructure2DCoupler
Issue(s): #19851
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: HeatTransferFromHeatStructure3D1Phase
- 15.5.96The system shall conserve energy when using HeatTransferFromHeatStructure3D1Phase.
Specification(s): phy:conservation
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.97The system shall allow to connect multiple flow channels to a single boundary in HeatTransferFromHeatStructure3D1Phase.
Specification(s): phy:conservation_ss
Design: HeatTransferFromHeatStructure3D1Phase
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.98The system shall allow to connect flow channels that have negative orientation to a HeatTransferFromHeatStructure3D1Phase component.
Specification(s): phy:conservation_inv
Design: HeatTransferFromHeatStructure3D1Phase
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.99The system shall throw an error if a flow channel connected to a HeatTransferFromHeatStructure3D1Phase component is not a FlowChannel1Phase.
Specification(s): err:not_a_pipe
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 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.
Specification(s): err:fch_orientation
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.101The system shall throw an error if the heat structure connected to a HeatTransferFromHeatStructure3D1Phase component is not a HeatStructureFromFile3D component.
Specification(s): err:not_3d_hs
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.102The system shall throw an error if the heat structure boundary connected to a HeatTransferFromHeatStructure3D1Phase component doesn't exist.
Specification(s): err:non_existent_boundary
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.103The system shall throw an error if the flow channels connected to a HeatTransferFromHeatStructure3D1Phase component are not aligned with the same axis.
Specification(s): err:differently_aligned_channels
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 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.
Specification(s): err:different_n_elems
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.105The system shall throw an error if the flow channels connected to a HeatTransferFromHeatStructure3D1Phase component don't have the same length.
Specification(s): err:different_lengths
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.106The system shall correctly compute Jacobians for HeatTransferFromHeatStructure3D1Phase.
Specification(s): jac
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #19831
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 15.10.14The system shall be able to produce an exodus file for setting initial conditions in heat transfer from 3D heat structures
Specification(s): steady_state
Design: HeatTransferFromHeatStructure3D1Phase
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.15The system shall be able to use an exodus file for setting initial conditions in heat transfer from 3D heat structures
Specification(s): test
Design: HeatTransferFromHeatStructure3D1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: Pump1Phase
- 15.5.165The system shall allow for controlling the pump head
Specification(s): clg:head
Design: Pump1Phase
Issue(s): #684
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.166The system shall allow for controlling the pump head
Specification(s): jacobian
Design: Pump1Phase
Issue(s): #684
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- thermal_hydraulics: ShaftConnectedCompressor1Phase
- 15.5.168The system shall conserve mass and energy when using ShaftConnectedCompressor1Phase.
Specification(s): phy:mass_energy_conservation
Design: ShaftConnectedCompressor1Phase
Issue(s): #19863
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.169The system shall be able to model a compressor with ShaftConnectedCompressor1Phase.
Specification(s): phy:loop
Design: ShaftConnectedCompressor1Phase
Issue(s): #19863
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.170The system shall allow ShaftConnectedCompressor1Phase to run with a zero shaft speed.
Specification(s): runs_with_zero_shaft_speed
Design: ShaftConnectedCompressor1Phase
Collection(s): FUNCTIONAL
Type(s): RunApp
- 15.5.171The system shall correctly compute Jacobians for ShaftConnectedCompressor1Phase.
Specification(s): jac:test
Design: ShaftConnectedCompressor1Phase
Issue(s): #19863
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 15.5.172The system shall throw an error if ShaftConnectedCompressor1Phase is not connected to a shaft component.
Specification(s): err:not_connected_to_shaft
Design: ShaftConnectedCompressor1Phase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: ShaftConnectedMotor
- 15.5.173The system shall throw an error if the initial shaft speed is not provided and the application is not restarting.
Specification(s): err:no_initial_speed
Design: ShaftConnectedMotor
Issue(s): #19833
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.174The system shall throw an error if ShaftConnectedMotor is not connected to a shaft component.
Specification(s): err:not_connected_to_shaft
Design: ShaftConnectedMotor
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.5.175The system shall be able to model a motor connected to a shaft.
Specification(s): restart_part1
Design: ShaftConnectedMotor
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.176The system shall be able to execute a restart a simulation involving a shaft-connected motor.
Specification(s): restart_part2
Design: ShaftConnectedMotor
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.177The system shall allow the torque of a shaft-connected motor to be controlled.
Specification(s): clg_test_torque
Design: ShaftConnectedMotor
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.178The system shall allow the inertia of a shaft-connected motor to be controlled.
Specification(s): clg_test_inertia
Design: ShaftConnectedMotor
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: ShaftConnectedPump1Phase
- 15.5.179The system shall conserve mass and energy when using ShaftConnectedPump1Phase.
Specification(s): phy:mass_energy_conservation
Design: ShaftConnectedPump1Phase
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.180The system shall be able to model a pump with ShaftConnectedPump1Phase.
Specification(s): phy:loop
Design: ShaftConnectedPump1Phase
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.181The system shall be able to model a pump coastdown with ShaftConnectedPump1Phase.
Specification(s): phy:coastdown
Design: ShaftConnectedPump1Phase
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.182The system shall correctly compute Jacobians for ShaftConnectedPump1Phase.
Specification(s): jacobian
Design: ShaftConnectedPump1Phase
Issue(s): #19833
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 15.5.183The system shall throw an error if ShaftConnectedPump1Phase is not connected to a shaft component.
Specification(s): err:not_connected_to_shaft
Design: ShaftConnectedPump1Phase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: ShaftConnectedTurbine1Phase
- 15.5.185The system shall conserve mass and energy when using ShaftConnectedTurbine1Phase.
Specification(s): phy:mass_energy_conservation
Design: ShaftConnectedTurbine1Phase
Issue(s): #19876
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.5.186The system shall be able to model a turbine with ShaftConnectedTurbine1Phase.
Specification(s): phy:loop
Design: ShaftConnectedTurbine1Phase
Issue(s): #19876
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.187The system shall be able to model a turbine startup with ShaftConnectedTurbine1Phase.
Specification(s): phy:startup
Design: ShaftConnectedTurbine1Phase
Issue(s): #19876
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.5.188The system shall correctly compute Jacobians for ShaftConnectedTurbine1Phase.
Specification(s): jac:test
Design: ShaftConnectedTurbine1Phase
Issue(s): #19876
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 15.5.189The system shall throw an error if ShaftConnectedTurbine1Phase is not connected to a shaft component.
Specification(s): err:not_connected_to_shaft
Design: ShaftConnectedTurbine1Phase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: SupersonicInlet
- 15.5.196The system shall report an error if the SupersonicInlet component is used.
Specification(s): not_implemented
Design: SupersonicInlet
Issue(s): #20383
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: ParsedFunctionControl
- 15.6.7The system shall provide a control that evaluates a parsed function
Specification(s): test
Design: ParsedFunctionControl
Issue(s): #93
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: UnitTripControl
- 15.6.17The system shall provide a unit trip component that report true if the trip condition was met and false otherwise.
Specification(s): no_latch
Design: UnitTripControl
Issue(s): #619
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.6.18The system shall provide a unit trip component that stays in tripped state after the trip happened.
Specification(s): latch
Design: UnitTripControl
Issue(s): #619
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.6.19The system shall report an error when an unit trip condition does not evaluate as boolean value.
Specification(s): err:not_boolean
Design: UnitTripControl
Issue(s): #619
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: FlowChannel1Phase
- 15.10.5The system shall be able to produce an exodus file for setting initial conditions in flow channels
Specification(s): steady_state
Design: FlowChannel1Phase
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.6The system shall be able to use an exodus file for setting initial conditions in flow channels
Specification(s): test
Design: FlowChannel1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 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.
Specification(s): all/explicit, all/implicit
Design: FlowChannel1Phase
Issue(s): #5
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: ScalarSolutionInitialCondition
- 15.10.6The system shall be able to use an exodus file for setting initial conditions in flow channels
Specification(s): test
Design: FlowChannel1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.7The system shall report an error when a block is non found in the restart ExodusII file
Specification(s): non_existent_block
Design: ScalarSolutionInitialCondition
Issue(s): #20526
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.10.9The system shall be able to use an exodus file for setting initial conditions in heat structures
Specification(s): test
Design: Heat StructuresScalarSolutionInitialCondition
Issue(s): #20465
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.11The system shall be able to use an exodus file for setting initial conditions in 3D heat structures
Specification(s): test
Design: HeatStructureFromFile3DScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.13The system shall be able to use an exodus file for setting initial conditions in volume junctions
Specification(s): test
Design: HeatTransferFromHeatStructure1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.15The system shall be able to use an exodus file for setting initial conditions in heat transfer from 3D heat structures
Specification(s): test
Design: HeatTransferFromHeatStructure3D1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: Heat Structures
- 15.10.8The system shall be able to produce an exodus file for setting initial conditions in heat structures
Specification(s): steady_state
Design: Heat Structures
Issue(s): #20465
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.9The system shall be able to use an exodus file for setting initial conditions in heat structures
Specification(s): test
Design: Heat StructuresScalarSolutionInitialCondition
Issue(s): #20465
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: HeatStructureFromFile3D
- 15.10.10The system shall be able to produce an exodus file for setting initial conditions in 3D heat structures
Specification(s): steady_state
Design: HeatStructureFromFile3D
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.11The system shall be able to use an exodus file for setting initial conditions in 3D heat structures
Specification(s): test
Design: HeatStructureFromFile3DScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: HeatTransferFromHeatStructure1Phase
- 15.10.12The system shall be able to produce an exodus file for setting initial conditions in volume junctions
Specification(s): steady_state
Design: HeatTransferFromHeatStructure1Phase
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.13The system shall be able to use an exodus file for setting initial conditions in volume junctions
Specification(s): test
Design: HeatTransferFromHeatStructure1PhaseScalarSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: Shaft
- 15.10.16The system shall be able to produce an exodus file for setting initial conditions in shaft
Specification(s): steady_state
Design: Shaft
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.17The system shall be able to use an exodus file for setting initial conditions in shaft
Specification(s): test
Design: ShaftSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: SolutionInitialCondition
- 15.10.17The system shall be able to use an exodus file for setting initial conditions in shaft
Specification(s): test
Design: ShaftSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.10.19The system shall be able to use an exodus file for setting initial conditions in volume junctions
Specification(s): test
Design: Flow JunctionsSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: Flow Junctions
- 15.10.18The system shall be able to produce an exodus file for setting initial conditions in volume junctions
Specification(s): steady_state
Design: Flow Junctions
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 15.10.19The system shall be able to use an exodus file for setting initial conditions in volume junctions
Specification(s): test
Design: Flow JunctionsSolutionInitialCondition
Issue(s): #20553
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: THMCreateMeshAction
- 15.10.26The system shall uniform refine mesh when specifid on the command line
Specification(s): test
Design: THMCreateMeshAction
Issue(s): #226
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: RZSymmetry
- 15.12.3The system should report an error when users set subdomain-restricted RZ-symmtrical THM-specific objects on RZ-subdomains.
Specification(s): err:rz_domain
Design: RZSymmetry
Issue(s): #215
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 15.12.5The system should error out when users set boundary-restricted RZ-symmtrical THM-specific objects on RZ-subdomains.
Specification(s): err:rz_domain
Design: RZSymmetry
Issue(s): #215
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- thermal_hydraulics: ShaftConnectedComponentPostprocessor
- 15.12.16The system shall provide a post-processor to retrieve the torque and moment of inertia from a shaft-connected component.
Specification(s): test
Design: ShaftConnectedComponentPostprocessor
Issue(s): #20196
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: SpecificImpulse1Phase
- 15.12.18The system shall compute specific impulse from conditions on a boundary
Specification(s): Isp_1ph
Design: SpecificImpulse1Phase
Issue(s): #189
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: Brayton Cycle
- 15.13.3The system shall be able to model an open Brayton cycle
- for a few time steps, and
- for a long duration.
Specification(s): open/light, open/heavy
Design: Brayton Cycle
Issue(s): #20196
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.13.4The system shall be able to model a closed Brayton cycle
- for a few time steps, and
- for a long duration.
Specification(s): closed/light, closed/heavy
Design: Brayton Cycle
Issue(s): #20196
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- thermal_hydraulics: LayeredFlowAreaChange
- 15.15.3The system shall allow computing changes in channel flow areas from deformation.
Specification(s): layered_area_change
Design: LayeredFlowAreaChange
Collection(s): FUNCTIONAL
Type(s): Exodiff
- thermal_hydraulics: Sampler1DReal
- 15.17.1The system shall provide a vector post-processor to sample regular material properties in one or more blocks.
Specification(s): non_ad
Design: Sampler1DReal
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 15.17.2The system shall provide a vector post-processor to sample AD material properties in one or more blocks.
Specification(s): ad
Design: Sampler1DReal
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 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.
Specification(s): error_on_nonexistent_matprop
Design: Sampler1DReal
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException