Heat Conduction 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 Heat Conduction application.

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 Jacobian-Free Newton-Krylov (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 Heat Conduction application is developed using MOOSE and is based on various modules, as such the SRS for Heat Conduction is dependent upon the files listed at the beginning of this document.

References

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

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

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.

@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"
}

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

heat_conduction: Nafems
5.1.1
The system shall compute the transient heat conduction solution for the NAFEMS T3 benchmark problem using a coarse mesh and
1. HEX8 elements
2. HEX20 elements
3. HEX27 elements
4. EDGE2 elements
5. EDGE3 elements
6. QUAD4 elements
7. QUAD8 elements
8. QUAD9 elements
5.1.2
The system shall compute the transient heat conduction solution for the NAFEMS T3 benchmark problem using a fine mesh and
1. HEX8 mesh
2. HEX20 mesh
3. HEX27 mesh
4. EDGE2 mesh
5. EDGE3 mesh
6. QUAD4 mesh
7. QUAD8 mesh
8. QUAD9 mesh

heat_conduction: Ad Convective Heat Flux
5.2.1
The system shall provide a convective flux boundary condition which uses material properties as heat transfer coefficients and far-field temperature values using AD
1. and match hand calculations for flux through a boundary.
2. and approach a constant far-field temperature value over time as heat flux decreases.
3. and couple a temperature dependent far-field temperature and heat transfer coefficient.

heat_conduction: Ad Heat Conduction
5.3.1AD heat conduction and the Jacobian shall be beautiful

heat_conduction: Code Verification
5.4.1The MOOSE solutions shall converge to the analytic solutions with an expected order of accuracy (two for linear, three for quadratic) where a standard set of heat conduction problems is used for code verification.

heat_conduction: Conjugate Heat Transfer
5.5.1The system shall correctly model convection heat transfer across internal sidesets aka conjugate heat transfer.

heat_conduction: Convective Flux Function
5.6.1The system shall allow prescribing a convective flux boundary condition using a constant heat transfer coefficient.
5.6.2The system shall allow prescribing a convective flux boundary condition using a heat transfer coefficient that is a function of position and time.
5.6.3The system shall allow prescribing a convective flux boundary condition using a heat transfer coefficient that is a function of temperature.

heat_conduction: Convective Heat Flux
5.7.1
The system shall provide a convective flux boundary condition which uses material properties as heat transfer coefficients and far-field temperature values
1. and match hand calculations for flux through a boundary.
2. and approach a constant far-field temperature value over time as heat flux decreases.
3. and couple a temperature dependent far-field temperature and heat transfer coefficient.

heat_conduction: Function Ellipsoid Heat Source
5.8.1The system shall produce a moving heat source where its path is function dependent

heat_conduction: Fvbcs
5.9.1The system shall be able to solve a heat conduction problem with boundary conditions representing radiation to an infinite cylinder.
5.9.2
The system shall be able to solve a heat conduction problem with diffusion/conduction/radiation combined thermal resistance boundary conditions
1. using regular material properties.
2. using regular material properties in RZ geometry.
3. using functor material properties.
4. using functor material properties in RZ geometry.

heat_conduction: Gap Heat Transfer Balance
5.10.1Energy balance must be fulfilled for the heat transfer of concentric spheres involving radiation, when the gap distance is not negligible with respect to the body main dimensions.
5.10.2Energy balance must be fulfilled for the heat transfer of concentric cylinders involving radiation in two-dimensions, when the gap distance is not negligible with respect to the body main dimensions.
5.10.3Energy balance must be fulfilled for the heat transfer of concentric cylinders involving radiation in two-dimensions with axisymmetry, when the gap distance is not negligible with respect to the body main dimensions.

heat_conduction: Gap Heat Transfer Htonly
5.11.1Thermal contact shall solve plate heat transfer for a constant conductivity gap in 3D
5.11.2Thermal contact shall solve plate heat transfer for a constant conductivity gap in 3D using the Modules/HeatConduction/Thermal contact syntax
5.11.3Thermal contact shall solve plate heat transfer for a constant conductivity gap in 3D at each iteration
5.11.4Thermal contact shall solve cylindrical and plate heat transfer for a constant conductivity gap in 2D axisymmetric coordinates
5.11.5Thermal contact shall solve cylindrical heat transfer for a constant conductivity gap in 2D axisymmetric coordinates where the axial axis is along the x-direction
5.11.6Thermal contact shall solve spherical heat transfer for a constant conductivity gap in 1D spherically symmetric coordinates
5.11.7Thermal contact shall solve cylindrical heat transfer for a constant conductivity gap in 3D
5.11.8Thermal contact shall solve cylindrical heat transfer for a constant conductivity gap in the x-y plane
5.11.9Thermal contact shall solve spherical heat transfer for a constant conductivity gap in 3D
5.11.10Thermal contact shall solve spherical heat transfer for a constant conductivity gap in 2D axisymmetric coordinates
5.11.11Thermal contact shall solve cylindrical heat transfer for a constant conductivity gap in the x-z plane
5.11.12Thermal contact shall solve cylindrical heat transfer for a constant conductivity gap in the y-z plane
5.11.13Thermal contact shall solve plate heat transfer for a constant conductivity gap in the x-y plane
5.11.14Thermal contact shall solve plate heat transfer for a constant conductivity gap in the x-z plane
5.11.15Thermal contact shall solve plate heat transfer for a constant conductivity gap in the y-z plane

heat_conduction: Gap Heat Transfer Mortar
5.12.1We shall be able to produce the expected result for a gap conductance test case using the mortar method.
5.12.2We shall be able to produce the expected result for a gap conductance test case using the mortar method using the modular gap flux system.
5.12.3We shall be able to produce the expected result for a combined gap conductance and radiative heat transfer test case using the mortar method using the modular gap flux system
5.12.4We shall be able to run the mortar method on a displaced mesh, supplying the displacements with constant** auxiliary variables
5.12.5We shall be able to produce the expected result for a gap conductance test case using the mortar method using the modular gap flux system with a displaced mesh.
5.12.6The system shall accurately calculate axisymmetric coordinates on mortar finite element segments
5.12.7We shall be able to generate node-to-segment numerical results for radiation through plates and use it as a reference for mortar-based constraints.
5.12.8We shall be able to generate mortar numerical results for radiation through plates that are close to those generated by the node-to-segment formulation.
5.12.9We shall be able to generate node-to-segment numerical results for conduction through plates and use it as a reference for mortar-based constraints.
5.12.10We shall be able to generate mortar numerical results for conduction through plates that are close to those generated by the node-to-segment formulation.
5.12.11We shall be able to generate node-to-segment numerical results for conduction and radiation through cylinders and use it as a reference for mortar-based constraints.
5.12.12We shall be able to generate mortar numerical results for conduction and radiationthrough cylinders that are close to those generated by the node-to-segment formulation.
5.12.13We shall be able to generate node-to-segment numerical results for conduction and radiation through cylinders with axisymmetry and use it as a reference for mortar-based constraints.
5.12.14We shall be able to generate mortar numerical results for conduction and radiationthrough cylinders with axisymmetry that are close to those generated by the node-to-segment formulation.
5.12.15We shall be able to generate node-to-segment numerical results for conduction and radiation through concentric spheres with axisymmetry and use it as a reference for mortar-based constraints.
5.12.16We shall be able to generate mortar numerical results for conduction and radiation through concentric spheres with axisymmetry that are close to those generated by the node-to-segment formulation.
5.12.17We shall be able to generate mortar numerical results for conduction and radiation in two dimensions. This test is used as a reference for computing separate gap physics, i.e. for the use of multiple heat flux Lagrange multipliers
5.12.18We shall be able to reproduce heat transfer mortar results when the gap physics (i.e. radiation and conduction) are separated in two constraint classes with independent Lagrange multipliers
5.12.19We shall be able to generate a meaningful error message if the user does not define the sphere origin when a spherical geometry has been chosen.
5.12.20We shall be able to generate a meaningful error message if the user does not define the cylinder points when a cylindrical geometry has been chosen.
5.12.21We shall be able to generate mortar numerical results for conduction through plates that are close to those generated by the node-to-segment formulation and using the function feature to enrich the evolution of the gap conductance.
5.12.22We shall be able to generate node-to-segment numerical results for conduction and radiation between two blocks in 3D and use it as a reference for mortar-based constraints.
5.12.23We shall be able to generate node-to-segment numerical results for conduction and radiation between two blocks in 3D using HEX20 elements and use it as a reference for mortar-based constraints.
5.12.24We shall be able to generate mortar numerical results for conduction and radiation between two blocks in 3D and match reasonably well with the node-to-segment approach with a refined mesh.
5.12.25We shall be able to generate mortar numerical results for conduction and radiation between two blocks in 3D using HEX20 elements and match reasonably well with the node-to-segment approach with a refined mesh.
5.12.26We shall be able to generate node-to-segment numerical results using thermal contact that resolves spherical heat transfer for a constant conductivity gap in 3D using HEX20 elements
5.12.27We shall be able to generate mortar numerical results using thermal contact that resolves spherical heat transfer for a constant conductivity gap in 3D using HEX20 elements and match reasonably well with the node-to-segment approach with a refined mesh.
5.12.28
We shall be able to compute the thermal contact across a closed gap as a function of contact pressure,
1. and the material thermal conductivities and hardness values consistent with an analytical solution for the temperatures at the interface.

heat_conduction: Gap Heat Transfer Mortar Action
5.13.1We shall be able to leverage mortar constraint and user objects to describe gap heat transfer physics by spelling out those objects in the input file.
5.13.2We shall be able to leverage mortar constraints and user objects to describe gap heat transfer physics by using the mortar thermal action in MOOSE.
5.13.3We shall be able to leverage mortar constraints and user objects to describe gap heat transfer physics by using the mortar thermal action in MOOSE and describe the gap conductance with a function of temperature.
5.13.4We shall be able to leverage mortar constraints and user objects to describe gap heat transfer physics by using the mortar thermal action in MOOSE when the lower-dimensional domains have already been appended to the mesh.
5.13.5We shall be able to leverage mortar constraints and user objects to describe gap heat transfer physics by using the mortar thermal action in MOOSE when the user objects are manually built by the user in the input file.
5.13.6We shall be able to inform the user that he or she provided physics parameters for two ways of building gap heat transfer options and error out, to avoid having misleading input files.

heat_conduction: Gap Heat Transfer Radiation
5.14.1The system shall be able to compute heat flux across a gap using the ThermalContact methods

heat_conduction: Generate Radiation Patch
5.15.1The system shall be able to divide a sideset into patches for more accurate radiative transfer modeling.
5.15.2The system shall be able to use linear partitioner for subdividing sidesets into patches.
5.15.3The system shall be able to use centroid partitioner for subdividing sidesets into patches.
5.15.4The system shall error when centroid partitioner is used but centroid_partitioner_direction is not provided.
5.15.5The system shall be able to use a uniform grid for subdividing sidesets into patches.
5.15.6The system shall be able to use a uniform grid for subdividing 1D sidesets into patches.
5.15.7The system shall be able to adjust the number of patches of partitions that end up empty.

heat_conduction: Gray Lambert Radiator
5.16.1The system shall check consistency of boundary and emissivity entries.
5.16.2The system shall check consistency of boundary and view factor entries.
5.16.3The system shall check consistency of fixed_boundary_temperatures and fixed_temperature_boundary entries.
5.16.4The system shall check consistency of boundary and fixed_temperature_boundary entries.
5.16.5The system shall check consistency of boundary and adiabatic_boundary entries.
5.16.6The system shall check consistency of the view_factors entry shape.
5.16.7The system shall check consistency of the view_factors entry norm.
5.16.8The system shall compute radiative transfer between gray Lambert surfaces.
5.16.9The system shall allow coupling radiative transfer between gray Lambert surfaces to solving heat conduction.
5.16.10The system shall allow reconstructing the spatial distribution of the emission component on a radiation boundary via the T4 law.
5.16.11The system shall compute radiative transfer between gray Lambert surfaces when the view factors are provided by a userobject.
5.16.12The system shall compute radiative transfer between gray Lambert surfaces in 3D when the view factors are provided by a userobject.

heat_conduction: Heat Conduction
5.17.1The system shall compute the heat transfer across small gaps for supported FEM orders and quadratures (QUAD4).
5.17.2The system shall compute the heat transfer across small gaps for supported FEM orders and quadratures (QUAD8)
5.17.3The system shall compute the heat transfer across small gaps for supported FEM orders and quadratures (QUAD9)
5.17.4The system shall compute the heat transfer across small gaps for non-matching meshes.
5.17.5The system shall compute the heat transfer across small gaps for second order FEM bases.
5.17.6The system shall compute the heat transfer across small gaps for moving interfaces.
5.17.7The system shall compute the heat transfer across small gaps with a specified gap conductivity.
5.17.8The system shall throw an error if the gap conductance model is used with uniform mesh refinement
5.17.9The system shall support thermal contact with linear 3d hexahedral elements
5.17.10The system shall support thermal contact with second-order 3d hexahedral elements
5.17.11The system shall support thermal contact with 3d hexahedral elements where the surfaces move relative to one another
5.17.12The system shall provide convective heat flux boundary condition where far-field temperature and convective heat transfer coefficient are given as constant variables
5.17.13The system shall provide convective heat flux boundary condition where far-field temperature and convective heat transfer coefficient are given as spatially varying variables
5.17.14The system shall provide convective heat flux boundary condition for multi-phase fluids where far-field temperatures and convective heat transfer coefficients are given as spatially varying variables
5.17.15The system shall report an error if the number of alpha components does not match the number of T_infinity components.
5.17.16The system shall report an error if the number of htc components does not match the number of T_infinity components.
5.17.17The system shall enable scaling of the total heat flux of the convective heat flux boundary condition
5.17.18Optionally a constant attenuation shall be applied to compute the gap conductance below a gap length threshold.
5.17.19Optionally a linear Taylor expansion of the inverse gap length shall be applied as the attenuation to compute the gap conductance below a gap length threshold.

heat_conduction: Heat Conduction Ortho
5.18.1The system shall allow the use of an anisotropic heat conduction material set by postprocessors.

heat_conduction: Heat Conduction Patch
5.19.1The system shall compute a tri-linear temperature field
5.19.2The system shall compute a bi-linear temperature field for an axisymmetric problem with quad8 elements
5.19.3The system shall compute a bi-linear temperature field for an axisymmetric problem
5.19.4The system shall compute a tri-linear temperature field with hex20 elements
5.19.5The system shall compute a tri-linear temperature field with hex20 elements using an anisotropic thermal conductivity model with isotropic thermal conductivities supplied

heat_conduction: Heat Source Bar
5.20.1The system shall reproduce an analytical solution of a heat source in a 1D ceramic bar.
5.20.2The system shall reproduce an analytical solution of a heat source in a 1D ceramic bar using AD kernels.
5.20.3The system shall produce correct Jacobians for the AD heat conduction and heat source kernel objects.

heat_conduction: Homogenization
5.21.1The system shall compute homogenized thermal conductivity using the asymptotic expansion homogenization approach

heat_conduction: Joule Heating
5.22.1The system shall compute Joule heating
5.22.2The system shall compute Joule heating using automatic differentiation
5.22.3The system shall compute a perfect jacobian for Joule heating using automatic differentiation

heat_conduction: Meshed Gap Thermal Contact
5.23.1The ThermalContact system shall enforce heat transfer across a meshed gap in a 2D plane geometry.
5.23.2The ThermalContact system shall correctly enforce heat transfer across a meshed gap in a 2D plane geometry using a prescribed constant conductance.
5.23.3The ThermalContact system shall correctly enforce heat transfer across a meshed gap in a 2D plane geometry using a prescribed constant conductance with the quadrature option
5.23.4The ThermalContact system shall enforce heat transfer across a meshed circular annulus in a 2D plane geometry.

heat_conduction: Multiple Contact Pairs
5.24.1Heat transfer module action shall allow for providing multiple contact pairs.

heat_conduction: Multiple Radiation Cavities
5.25.1The system shall support the the modeling of radiative heat transfer with multiple radiation cavities.

heat_conduction: Parallel Element Pps Test
5.26.1The system shall computed an integrated value on elements in parallel

heat_conduction: Postprocessors
5.27.1The system shall compute total heat flux from heat transfer coefficient and temperature difference
5.27.2The system shall compute total heat flux from heat transfer coefficient and temperature difference for AD variables

heat_conduction: Radiation Transfer Action
5.28.1The system shall provide an action to set up radiative heat transfer problems using the net radiation method for cavities with unobstructed, planar faces.
5.28.2The system shall provide an action to set up radiative heat transfer problems using the net radiation method and allow computing view factors using raytracing.
5.28.3The system shall allow the specification of boundary names and ids in the modeling of radiative heat transfer.
5.28.4The system shall ensure that results between manually created radiative transfer inputs and inputs that use the radiation transfer action are identical.
5.28.5The system shall provide an action to set up radiative heat transfer problems where sidesets participating in the radiative exchange are external faces of the domain, with view factors computed by simple quadrature rules for cavities with unobstructed, planar faces.
5.28.6The system shall provide an action to set up radiative heat transfer problems where sidesets participating in the radiative exchange are external faces of the domain, with view factors computed by ray tracing.

heat_conduction: Radiation Transfer Symmetry
5.29.1
The system shall support the modeling of radiative heat transfer with symmetry boundary conditions by
1. unfolding the problem at the symmetry boundary and
2. by using a symmetry boundary condition.

heat_conduction: Radiative Bcs
5.30.1The system shall be able to model radiative transfer from a cylindrical surface as a boundary condition.
5.30.2The system shall be able to model radiative transfer from a cylindrical surface as boundary condition with automated differentiation.
5.30.3The system shall be able to model radiative transfer from a cylindrical surface as boundary condition with automated differentiation and provide exact Jacobian.
5.30.4The system shall be able to model radiative heat transfer using a user-specified emissivity function.
5.30.5The system shall be able to model radiative heat transfer using a user-specified emissivity function with automated differentiation.
5.30.6The system shall be able to model radiative heat transfer using a user-specified emissivity function with automated differentiation and provide exact Jacobian.

heat_conduction: Recover
5.31.1The system shall run a simulation with heat conduction, a heat source, thermal contact, and boundary conditions.
5.31.2The system shall run a short simulation with heat conduction, a heat source, thermal contact, and boundary conditions.
5.31.3The system shall be able to recover from a short simulation and reproduce a the full time scale simulation with heat conduction, a heat source, thermal contact, and boundary conditions.
5.31.4The system shall run a simulation with heat conduction, a heat source, thermal contact, and boundary conditions with automatic differentiation.
5.31.5The system shall run a short simulation with heat conduction, a heat source, thermal contact, and boundary conditions with automatic differentiation.
5.31.6The system shall be able to recover from a short simulation and reproduce a the full time scale simulation with heat conduction, a heat source, thermal contact, and boundary conditions with automatic differentiation.

heat_conduction: Semiconductor Linear Conductivity
5.32.1The system shall compute conductivity of semiconductors according to the Steinhart-Hart equation

heat_conduction: Sideset Heat Transfer
5.33.1
The system shall solve the side set heat transfer model with:
1. discontinuous finite elements,
2. bulk gap temperature as an auxiliary variable,
3. temperature dependent gap conductivity, and
4. block restricted continuous finite element variables.
5.33.2The system shall throw an error if the specified boundary does not exist when using the DGDiffusion DGKernel.

heat_conduction: Transient Heat
5.34.1The system shall compute the time derivative term of the heat equation

heat_conduction: Truss Heat Conduction
5.35.1
The system shall model heat transfer in a bar and a strip made of two materials in series having differing thermal properties and provide equivalent solutions.
1. using 1D truss elements.
2. using 2D continuum elements in a 2D medium.
5.35.2
The system shall model heat transfer in a bar/strip embedded in a medium having differing thermal properties from the bar/strip, and provide equivalent solutions.
1. using 2D continuum elements for the bar contiguously meshed with a 2D medium.
2. using 1D truss elements embedded in a 2D medium and connected using constraints.
3. using 3D continuum elements for the bar contiguously meshed with a 3D medium.
4. using 1D truss elements embedded in a 3D medium and connected using constraints.
5.35.3The system shall generate comparison plots of the thermal solutions for a bar embedded in a continuum represented various ways.

heat_conduction: Verify Against Analytical
5.36.1Heat conduction shall match the answer from an analytical solution in 1D
5.36.2Heat conduction from an AD kernel shall get the same answer as a traditional kernel in 1D
5.36.3AD heat conduction and the Jacobian shall be beautiful in 1D
5.36.4Heat conduction shall match the answer from an analytical solution in 2D
5.36.5Heat conduction from an AD kernel shall get the same answer as a traditional kernel in 2D
5.36.6AD heat conduction and the Jacobian shall be beautiful in 2D

heat_conduction: View Factors
5.37.1The system shall compute view factors for unobstructed, planar surfaces without normalization.
5.37.2The system shall compute view factors for cavities with obstruction using ray tracing.
5.37.3The system shall compute view factors for unobstructed, planar surfaces in two-dimensional meshes using simple quadrature rules.
5.37.4The system shall compute view factors for unobstructed, planar surfaces in two-dimensional meshes using ray tracing.
5.37.5The system shall compute view factors for unobstructed, planar surfaces in three-dimensional meshes using simple quadrature rules.
5.37.6The system shall compute view factors for unobstructed, planar surfaces in three-dimensional meshes using ray tracing.

heat_conduction: View Factors Symmetry
5.38.1The system shall support ensure that symmetry boundary conditions provide exactly the same answer as unfolding the problem about its axis of symmetry.
5.38.2The system shall support symmetry boundary conditions for view factor calculations.

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

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.

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 Nuclear Quality Assurance Level 1 (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.

Introduction
System Overview
References
Definitions and Acronyms
System Requirements
Verification