Misc System Design Description

This template follows INL template TEM-140, "IT System Design Description."

note

This document serves as an addendum to Framework System Design Description and captures information for SDD specific to the Misc module.

Framework System Design Description

Introduction

The MOOSE Misc module provides a set of objects that are used to support a variety of simulations performed using other MOOSE modules or MOOSE-based applications. This module relies on MOOSE for solving the systems of equations that are primarily defined by code outside this module, and simply provides commonly-used code objects that can support those calculations. This document describes the system design of the Misc module.

System Purpose

The Software Design Description provided here is description of each object in the system. The pluggable architecture of the underlying framework of the Misc module 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 Misc module. More information about the design documentation for MOOSE-based applications and like the Misc module can be found in Documenting MOOSE.

System Scope

The MOOSE Misc module is designed only to provide code modules that support the solution of physics models that are primarily defined by other MOOSE modules and MOOSE-based applications.

The Misc module provides several specializations of MOOSE classes that are used to support calculations performed in a variety of physics calculations. These include Kernel, AuxKernel, Material and Postprocessor classes that computing terms in diffusion equations, compute density, internal volume, and perform other similar functions.

Dependencies and Limitations

The MOOSE Misc module inherits the software dependencies of the MOOSE framework, with no additional dependencies.

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
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
SDD	Software Design Description

Design Stakeholders and Concerns

Design Stakeholders

Stakeholders for MOOSE include several of the funding sources including 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, Misc module 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, the Misc module (located within the MOOSE repository) 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 Misc module relies on MOOSE to solve the governing equations for the physics models that it supports. The design of MOOSE is based on the concept of modular code objects that define all of the aspects of the physics model. This module follows this design, providing code objects that define specific aspects of the solutions for its physics that derive from the base classes defined by the MOOSE framework and the modules that it depends on.

System Structure

The MOOSE Misc module relies on the MOOSE framework to provide the core functionality of solving multiphysics problems using the finite element method. The structure of the Misc module is based on defining C++ classes that derive from base classes in the MOOSE framework to provide functionality for solution of a variety of physics problems. By using the interfaces defined in MOOSE for these classes, this module is able to rely on MOOSE to execute these models at the appropriate times during the simulation and use their results in the desired ways.

Data Design and Control

At a high level, the system is designed to process 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

The Misc module is a command-line driven program. All interaction with the Misc module 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 I/O or through local API calls. Neither the Misc module, nor the MOOSE framework, nor the other MOOSE 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 Misc module 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

misc: ArrheniusMaterialProperty
9.1.1The system shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation while using the automatic differentiation system.
Specification(s): exact
Design: ArrheniusMaterialProperty
Issue(s): #22384
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28
9.1.2The system shall provide perfect derivatives when using ADArrheniusMaterialProperty.
Specification(s): exact-jac
Design: ArrheniusMaterialProperty
Issue(s): #22384
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
20
9.2.1The system material shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation.
Specification(s): exact
Design: ArrheniusMaterialProperty
Issue(s): #22384
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28

misc: CoupledDirectionalMeshHeightInterpolation
9.3.1The system shall linearly scale a variable based on the local position relative to the maximum and minimum mesh coordinate in a user-specified direction.
Specification(s): test
Design: CoupledDirectionalMeshHeightInterpolation
Issue(s): #1927
Collection(s): FUNCTIONAL
Type(s): Exodiff
28

misc: MultiApp System
9.4.1The system shall be able to dynamically load a multiapp from a dynamic library.
Specification(s): dynamic_load
Design: MultiApp System
Issue(s): #12266
Collection(s): FUNCTIONAL
Type(s): Exodiff
6
9.4.2The system shall be able to dynamically load a multiapp using the library name, to select a compiling optimization level for example.
Specification(s): dynamic_load_w_name
Design: MultiApp System
Issue(s): #12266
Collection(s): FUNCTIONAL
Type(s): Exodiff
5
9.4.3The system shall report an error if the type of application to dynamically load is not included in the dynamic library.
Specification(s): dynamic_load_error_check
Design: MultiApp System
Issue(s): #12266
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
26
9.4.4The system shall throw an error message when the library name is manually supplied but does not supply the right application.
Specification(s): dynamic_load_bad_libary_name
Design: MultiApp System
Issue(s): #24751
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
22
9.4.5The system shall throw an error when no path or environment variable is supplied for dynamic loading.
Specification(s): dynamic_load_no_path
Design: MultiApp System
Issue(s): #24751
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
22

misc: DynamicObjectRegistrationAction
9.4.6Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library name inferred from the module or application name.
Specification(s): dynamic_object_loading
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FUNCTIONAL
Type(s): Exodiff
25
9.4.7Any MOOSE application shall be able to dynamically load a module or application and properly register the provided objects.
Specification(s): dynamic_object_loading2
Design: DynamicObjectRegistrationAction
Issue(s): #24299
Collection(s): FUNCTIONAL
Type(s): RunApp
25
9.4.8Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library specified.
Specification(s): dynamic_object_loading_w_name
Design: DynamicObjectRegistrationAction
Issue(s): #10911
Collection(s): FUNCTIONAL
Type(s): Exodiff
18
9.4.9Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library name inferred from the module or application name.
Specification(s): dynamic_object_loading_syntax
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FUNCTIONAL
Type(s): Exodiff
25
9.4.10Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library specified.
Specification(s): dynamic_object_loading_syntax_w_name
Design: DynamicObjectRegistrationAction
Issue(s): #10911
Collection(s): FUNCTIONAL
Type(s): Exodiff
21
9.4.11Any MOOSE application shall be able to dynamically load a module or application and register only select objects form the module or application.
Specification(s): dynamic_object_restrict
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FUNCTIONAL
Type(s): Exodiff
25
9.4.12Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not among selected objects for registration.
Specification(s): dynamic_object_restrict_bad
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
22
9.4.13Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not provided by the module or application.
Specification(s): dynamic_object_loading_wrong_app
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
22
9.4.14The system shall throw an error when trying to dynamically load a module or application that does not exist.
Specification(s): dynamic_object_loading_bogus_app
Design: DynamicObjectRegistrationAction
Issue(s): #4712
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
22

misc: Misc Module
9.5.1The system shall be able to simulate convective flow through lower-dimensional fractures embedded in a higher-dimensional solid
Specification(s): test
Design: Misc Module
Issue(s): #13318
Collection(s): FUNCTIONAL
Type(s): Exodiff
28

misc: ThermoDiffusion
9.6.1Thermo diffusion shall reproduce an analytical solution
Specification(s): thermo_diffusion
Design: ThermoDiffusion
Issue(s): #3392
Collection(s): FUNCTIONAL
Type(s): Exodiff
28

misc: ADThermoDiffusion
9.6.2AD thermo diffusion shall reproduce an analytical solution
Specification(s): ad_thermo_diffusion
Design: ADThermoDiffusion
Issue(s): #12633
Collection(s): FUNCTIONAL
Type(s): Exodiff
28
9.6.3AD thermo diffusion shall work with material properties and the Jacobian shall be beautiful
Specification(s): ad_thermo_diffusion_jacobian
Design: ADThermoDiffusion
Issue(s): #5658
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
20

misc: GeneralSensorPostprocessor
9.7.1The system process a signal and send out a general sensor-mediated signal for transient case.
Specification(s): transient_general_sensor
Design: GeneralSensorPostprocessor
Issue(s): #25590
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28
9.7.2The system process a signal and send out a general sensor-mediated signal for steady-state case.
Specification(s): steady_general_sensor
Design: GeneralSensorPostprocessor
Issue(s): #25590
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28

misc: ThermocoupleSensorPostprocessor
9.7.3The system process a signal and send out a thermocouple sensor-mediated signal for transient case.
Specification(s): transient_thermocouple_sensor
Design: ThermocoupleSensorPostprocessor
Issue(s): #25590
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28
9.7.4The system process a signal and send out a thermocouple sensor-mediated signal for steady-state case.
Specification(s): steady_thermocouple_sensor
Design: ThermocoupleSensorPostprocessor
Issue(s): #25590
Collection(s): FUNCTIONAL
Type(s): CSVDiff
28

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

[exact]
  type = 'CSVDiff'
  input = 'exact.i'
  csvdiff = 'exact_out.csv'
  requirement = 'The system shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation while using the automatic differentiation system.'
[]

[exact-jac]
  type = 'PetscJacobianTester'
  input = 'exact.i'
  run_sim = 'True'
  cli_args = "Outputs/active=''"
  prereq = exact
  capabilities = 'petsc>=3.9'
  ratio_tol = 3e-7
  difference_tol = 1
  requirement = 'The system shall provide perfect derivatives when using ADArrheniusMaterialProperty.'
[]

[exact]
  type = 'CSVDiff'
  input = 'exact.i'
  csvdiff = 'exact_out.csv'
  issues = '#22384'
  design = 'ArrheniusMaterialProperty.md'
  requirement = 'The system material shall compute a generic material property based on an Arrhenius model that matches an analytic solution of that equation.'
[]

[./test]
  type = 'Exodiff'
  input = 'coupled_directional_mesh_height_interpolation.i'
  exodiff = 'coupled_directional_mesh_height_interpolation_out.e'
  requirement = 'The system shall linearly scale a variable based on the local position relative to the maximum and minimum mesh coordinate in a user-specified direction.'
[../]

[dynamic_load]
  type = 'Exodiff'
  input = 'misc_parent.i'
  exodiff = 'misc_parent_out.e misc_parent_out_sub_app0.e'
  allow_warnings = true
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'
  recover = false # See #5207
  requirement = "The system shall be able to dynamically load a multiapp from a dynamic library."
  # skip test if test is being run out-of-tree. Issue Ref: #25279
  installation_type = in_tree
[]

[dynamic_load_w_name]
  type = 'Exodiff'
  input = 'misc_parent.i'
  exodiff = 'misc_parent_out.e misc_parent_out_sub_app0.e'
  allow_warnings = true
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'
  cli_args = 'MultiApps/sub_app/library_name=libphase_field-opt.la'
  capabilities = 'method=opt' # because the library name is explicitly given
  prereq = 'dynamic_load'
  recover = false # See #5207
  requirement = 'The system shall be able to dynamically load a multiapp using the library name, to select a compiling optimization level for example.'
[]

[dynamic_load_error_check]
  type = 'RunException'
  input = 'misc_parent_bad.i'
  expect_err = 'Unable to locate library archive for "InvalidApp"'
  allow_warnings = true
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'
  requirement = "The system shall report an error if the type of application to dynamically load is not included in the dynamic library."
[]

[dynamic_load_bad_libary_name]
  type = 'RunException'
  input = 'misc_parent.i'
  expect_err = 'We attempted to locate the library archive "foo.la"'
  cli_args = 'MultiApps/sub_app/library_name=foo.la'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  issues = '#24751'
  requirement = "The system shall throw an error message when the library name is manually supplied but does not
                  supply the right application."
[]

[dynamic_load_no_path]
  type = 'RunException'
  input = 'misc_parent_no_path.i'
  expect_err = 'No search paths were set.'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'
  env_vars_not_set = 'MOOSE_LIBRARY_PATH'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  issues = '#24751'
  requirement = "The system shall throw an error when no path or environment variable is supplied for dynamic loading."
[]

[dynamic_object_loading]
  type = 'Exodiff'
  input = 'dynamic_objects.i'
  exodiff = 'dynamic_objects_out.e'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#4712'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library name inferred from the module or application name."
[]

[dynamic_object_loading2]
  type = 'RunApp'
  input = 'dynamic_objects2.i'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#24299'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and properly register the provided objects."
[]

[dynamic_object_loading_w_name]
  type = 'Exodiff'
  input = 'dynamic_objects.i'
  exodiff = 'dynamic_objects_out.e'
  cli_args = 'Problem/library_name=libphase_field-opt.la'
  capabilities = 'method=opt' # because the library name is explicitly given
  prereq = 'dynamic_object_restrict_bad'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#10911'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and use objects registered therein, with the library specified."
[]

[dynamic_object_loading_syntax]
  type = 'Exodiff'
  input = 'dynamic_syntax.i'
  exodiff = 'dynamic_syntax_out.e'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#4712'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library name inferred from the module or application name."
[]

[dynamic_object_loading_syntax_w_name]
  type = 'Exodiff'
  input = 'dynamic_syntax.i'
  exodiff = 'dynamic_syntax_out.e'
  cli_args = 'Problem/library_name=libphase_field-opt.la'
  capabilities = 'method=opt' # because the library name is explicitly given
  prereq = 'dynamic_object_loading_syntax'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#10911'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and properly register module or application specific syntax, with the library specified."
[]

[dynamic_object_restrict]
  type = 'Exodiff'
  input = 'dynamic_objects.i'
  exodiff = 'dynamic_objects_out.e'
  # Register only some of the objects necessary for running this test
  cli_args = "Problem/object_names='CHMath CHInterface'"
  library_mode = 'DYNAMIC'
  prereq = 'dynamic_object_loading'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#4712'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and register only select objects form the module or application."
[]

[dynamic_object_restrict_bad]
  type = 'RunException'
  input = 'dynamic_objects.i'
  expect_err = "A '\w+' is not a registered object"
  # Register only some of the objects necessary, not enough for running this test
  cli_args = "Problem/object_names='CHMath'"
  library_mode = 'DYNAMIC'
  prereq = 'dynamic_object_restrict'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  allow_warnings = true
  issues = '#4712'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not among selected objects for registration."
[]

[dynamic_object_loading_wrong_app]
  type = 'RunException'
  input = 'dynamic_wrong_lib.i'
  expect_err = 'We loaded objects from the following libraries.*\n\tlibsolid_mechanics'
  library_mode = 'DYNAMIC'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  issues = '#4712'
  requirement = "Any MOOSE application shall be able to dynamically load a module or application and throw an error if an object is used that is not provided by the module or application."
[]

[dynamic_object_loading_bogus_app]
  type = 'RunException'
  input = 'dynamic_wrong_lib.i'
  expect_err = 'If you are trying to find this object in a dynamically loaded library'
  cli_args = 'Problem/register_objects_from=FooApp'
  library_mode = 'DYNAMIC'
  prereq = 'dynamic_object_loading_wrong_app'
  group = 'dynamic_loading'

  # Test must be run with the misc app to test dynamic loading
  executable_pattern = 'misc-\w+$'
  issues = '#4712'
  requirement = "The system shall throw an error when trying to dynamically load a module or application that does not exist."
[]

[./test]
  type = Exodiff
  input = single.i
  exodiff = 'single_out.e'
  allow_test_objects = true
  abs_zero = 1E-6
  requirement = 'The system shall be able to simulate convective flow through lower-dimensional fractures embedded in a higher-dimensional solid'
  design = 'misc/index.md'
  issues = '#13318'
[../]

[./thermo_diffusion]
  type = 'Exodiff'
  input = 'thermo_diffusion.i'
  exodiff = 'thermo_diffusion_out.e'
  abs_zero = 1e-8
  rel_err = 5e-4
  requirement = 'Thermo diffusion shall reproduce an analytical solution'
  design = "ThermoDiffusion.md"
  issues = "#3392"
[../]

[./ad_thermo_diffusion]
  type = 'Exodiff'
  input = 'ad_thermo_diffusion.i'
  exodiff = 'ad_thermo_diffusion_out.e'
  abs_zero = 1e-8
  rel_err = 5e-4
  requirement = 'AD thermo diffusion shall reproduce an analytical solution'
  design = "ADThermoDiffusion.md"
  issues = "#12633"
  allow_test_objects = true
[../]

[./ad_thermo_diffusion_jacobian]
  type = 'PetscJacobianTester'
  input = 'ad_thermo_diffusion.i'
  ratio_tol = 1e-7
  difference_tol = 1e-3
  run_sim = True
  requirement = 'AD thermo diffusion shall work with material properties and the Jacobian shall be beautiful'
  design = "ADThermoDiffusion.md"
  issues = "#5658"
  allow_test_objects = true
[../]

[./transient_general_sensor]
  type = 'CSVDiff'
  input = 'transient_general_sensor.i'
  csvdiff = 'transient_general_sensor_out.csv'
  requirement = 'The system process a signal and send out a general sensor-mediated signal for transient case.'
  design = 'GeneralSensorPostprocessor.md'
  issues = '#25590'
[../]

[./steady_general_sensor]
  type = 'CSVDiff'
  input = 'steady_general_sensor.i'
  csvdiff = 'steady_general_sensor_out.csv'
  requirement = 'The system process a signal and send out a general sensor-mediated signal for steady-state case.'
  design = 'GeneralSensorPostprocessor.md'
  issues = '#25590'
[../]

[./transient_thermocouple_sensor]
  type = 'CSVDiff'
  input = 'transient_thermocouple_sensor.i'
  csvdiff = 'transient_thermocouple_sensor_out.csv'
  requirement = 'The system process a signal and send out a thermocouple sensor-mediated signal for transient case.'
  design = 'ThermocoupleSensorPostprocessor.md'
  issues = '#25590'
[../]

[./steady_thermocouple_sensor]
  type = 'CSVDiff'
  input = 'steady_thermocouple_sensor.i'
  csvdiff = 'steady_thermocouple_sensor_out.csv'
  requirement = 'The system process a signal and send out a thermocouple sensor-mediated signal for steady-state case.'
  design = 'ThermocoupleSensorPostprocessor.md'
  issues = '#25590'
[../]

Introduction
Definitions and Acronyms
Design Stakeholders and Concerns
System Design
Requirements Cross - Reference
References