Cardinal 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 Software Design Description (SDD) specific to the Cardinal application.

Introduction

Many of the phenomena related to nuclear energy systems depend on the solutions to multiple physics models, which can be described by partial differential equations that provide spatially- and temporally-varying values of solution variables. When these models for individual physics depend on one another, we call this "multiphysics." Cardinal relies on the OpenMC Monte Carlo radiation transport code and the NekRS spectral element Navier-Stokes code to perform high-fidelity multiphysics and multiscale simulation. Cardinal handles the couplings that may occur between these two codes, in addition to the numerous physics models provided by the MOOSE framework (such as solid mechanics, material science, and radiative heat transfer). This document describes the system design of Cardinal.

System Purpose

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

System Scope

Cardinal is an application for performing high-fidelity simulation of nuclear systems incorporating Monte Carlo neutron-photon transport and/or spectral element Computational Fluid Dynamics (CFD). These physics can be combined with one another and with the MOOSE modules to accomplish "multiphysics" simulation. High-fidelity simulations can also be performed independently, for the purpose of data postprocessing, to generate constitutive models suitable for lower-fidelity tools, a process referred to as "multiscale" simulation.

Interfaces to other MOOSE-based codes, including systems-level thermal-hydraulics (SAM), heat pipe flows (Sockeye), and fuel performance (Bison) are also optionally included to support Cardinal simulations. Cardinal enables high-fidelity modeling of heat transfer, fluid flow, passive scalar transport, fluid-structure interaction, nuclear heating, tritium breeding, shielding effectiveness, material activation, material damage, and sensor response. The MultiApp System is leveraged to allow for the multiscale, multiphysics coupling. Further, other MOOSE capabilities in the modules, such as the Stochastic Tools Module enable engineering studies with uncertainty quantification and sensitivity analysis. Cardinal therefore supports design, safety, engineering, and research projects.

Dependencies and Limitations

Cardinal inherits the software dependencies of: - MOOSE framework - OpenMC - NekRS - DAGMC

No additional dependencies are present.

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
ANL	Argonne National Laboratory
API	Application Programming Interface
CAD	Computer Aided Design
CFD	Computational Fluid Dynamics
DOE	Department of 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 Cardinal include several of the funding sources including Department of Energy (DOE), INL, and ANL. However, since Cardinal is an open-source project, several universities, companies, and foreign governments have an interest in the development and maintenance of the Cardinal 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, Cardinal 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, Cardinal 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

Cardinal relies on OpenMC to solve for neutron-photon transport (optionally on Computer Aided Design (CAD) geometries by relying on DAGMC). Cardinal also relies on NekRS to solve for fluid flow, heat transfer, and species transport. Cardinal integrates these external libraries within the structure of a MOOSE application, allowing these external libraries to be coupled to existing capabilities and interfaces in the MOOSE framework, such as for physics modeling (e.g., with the MOOSE modules or with other MOOSE applications) or data processing. Because Cardinal is based upon MOOSE, it employs the same concept of modular code objects that define all aspects of the solutions for physics. Cardinal provides specialized

- AuxKernels classes that extract internal solution fields in NekRS and OpenMC - Controls classes that modify NekRS and OpenMC simulations on-the-fly - Mesh classes to build the NekRS and OpenMC geometries in a MOOSE-compatible format, and modify existing meshes useful for postprocessing NekRS and OpenMC simulations - Postprocessors classes that query the NekRS and OpenMC simulations at points, through spatial integrals, etc. - Problem classes to execute NekRS and OpenMC as MOOSE applications and facilitate data transfer - TimeStepper classes to control time stepping based on NekRS's adaptive time stepping routines - UserObjects classes that spatially process the NekRS and OpenMC simulations

Cardinal also provides custom syntax for creating OpenMC tallies needed for multiphysics.

System Structure

Cardinal relies on the MOOSE framework to provide the core functionality of solving multiphysics problems. Cardinal replaces the actual physics solves with external API calls to OpenMC and NekRS, but relies on MOOSE for timestepping, synchronization, data transfers, and overall parallelization. Additional physics needed beyond OpenMC and NekRS are obtained from the MOOSE modules.

A summary listing of the current modules required for complete Cardinal operation are shown below:

Reactor

Cardinal's Makefile also includes other modules which are by default enabled, due to their common usage with Cardinal (though they are not strictly required).

The structure of Cardinal is based on defining C++ classes that derive from classes in the MOOSE framework or modules that provide functionality that is specifically tailored to nuclear modeling and simulation. By using the interfaces defined in MOOSE base classes for these classes, Cardinal 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 Hierarchical Input Text (HIT) input files to construct several objects that will constitute an finite element (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 Cardinal application is a command-line driven program. All interaction with Cardinal 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 API calls. Neither Cardinal, nor the MOOSE framework, nor the 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 Cardinal application 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

cardinal: HeatTransferCoefficientAux
1.1.2The system shall compute a convective heat transfer coefficient using userobjects for the wall heat flux, wall temperature, and bulk temperature.
Specification(s): h
Design: HeatTransferCoefficientAux
Issue(s): #1081
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: NekRSProblem
1.3.7A coupled MOOSE-nekRS pincell-fluid flow problem shall predict correct conservation of energy and realistic thermal solutions. Exact conservation of energy (based on the power imposed in the solid) will not be observed because some heat flux GLL points are also on Dirichlet boundaries, which win in boundary condition ties.
Specification(s): sfr_pincell
Design: NekRSProblem
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.3.8Individually conserving heat flux sideset by sideset shall give equivalent results to the all-combined option when there is just one coupling sideset. The gold file for this test is identical to that for the sfr_pincell case.
Specification(s): sfr_pincell_vpp
Design: NekRSProblem
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.3.9The system shall allow imposing heat flux through a dummy main application, instead of coupling NekRS via conjugate heat transfer. This is verified by computing the heat flux on the NekRS mesh, which adequately matches an initial value set in a postprocessor. This gold file is also identical to that obtained by running a dummy main app (solid_dummy) that passes in the desired flux_integral initial condition.
Specification(s): impose_heat_flux
Design: NekRSProblem
Issue(s): #797
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: BooleanComboMarker
1.10.1The system shall be able to prioritize refinement while ANDing markers together.
Specification(s): prioritize_refine_and
Design: BooleanComboMarker
Issue(s): #1025
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.10.2The system shall be able to prioritize coarsening while ANDing markers together.
Specification(s): prioritize_coarsen_and
Design: BooleanComboMarker
Issue(s): #1025
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.10.3The system shall be able to prioritize refinement while ORing markers together.
Specification(s): prioritize_refine_or
Design: BooleanComboMarker
Issue(s): #1025
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.10.4The system shall be able to prioritize coarsening while ORing markers together.
Specification(s): prioritize_coarsen_or
Design: BooleanComboMarker
Issue(s): #1025
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: MeshTally
1.23.1The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies.
Specification(s): adaptive_cell
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.2The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies.
Specification(s): adaptive_mesh
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.3The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block.
Specification(s): adaptive_mesh_template
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.4The system shall error if adaptivity is active and a relaxation scheme is requested.
Specification(s): adaptive_relaxation
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.5The system shall skip running OpenMC when the mesh is unchanged by adaptivity.
Specification(s): skip_openmc_unchanged
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.6The system shall run OpenMC on the first Picard iteration regardless of the mesh being previouslyunchanged by adaptivity. This test relies on noise in the solution; if OpenMC runs more than onceper Picard iteration the PRNG seed changes and so the tally results will be different.
Specification(s): skip_openmc_unchanged_picard
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff

cardinal: OpenMCCellAverageProblem
1.23.1The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies.
Specification(s): adaptive_cell
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.2The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies.
Specification(s): adaptive_mesh
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.3The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block.
Specification(s): adaptive_mesh_template
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.4The system shall error if adaptivity is active and a relaxation scheme is requested.
Specification(s): adaptive_relaxation
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.5The system shall skip running OpenMC when the mesh is unchanged by adaptivity.
Specification(s): skip_openmc_unchanged
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.6The system shall run OpenMC on the first Picard iteration regardless of the mesh being previouslyunchanged by adaptivity. This test relies on noise in the solution; if OpenMC runs more than onceper Picard iteration the PRNG seed changes and so the tally results will be different.
Specification(s): skip_openmc_unchanged_picard
Design: MeshTally OpenMCCellAverageProblem
Issue(s): #1054
Collection(s): FUNCTIONAL
Type(s): Exodiff

cardinal: ElementOpticalDepthIndicator
1.23.149The system shall allow for the calculation of the optical depth using the min/max vertex separation or the cube root of the element volume.
Specification(s): all_h
Design: ElementOpticalDepthIndicator
Issue(s): #1028
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.150The system shall error if a non-reaction rate score is provided to ElementOpticalDepthIndicator.
Specification(s): not_rxn_rate
Design: ElementOpticalDepthIndicator
Issue(s): #1028
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.151The system shall error if a a reaction rate score is requested, but not available in a tally.
Specification(s): missing_score
Design: ElementOpticalDepthIndicator
Issue(s): #1028
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.152The system shall error if the flux is not available in a tally.
Specification(s): missing_flux
Design: ElementOpticalDepthIndicator
Issue(s): #1028
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException

cardinal: FDTallyGradAux
1.23.208The system shall allow for the approximation of tally gradients using finite differences.
Specification(s): gradients
Design: FDTallyGradAux
Issue(s): #1031
Collection(s): FUNCTIONAL
Type(s): Exodiff
1.23.209The system shall error if the variable provided to FDTallyGradAux is not of type CONSTANT MONOMIAL_VEC.
Specification(s): not_const_mon
Design: FDTallyGradAux
Issue(s): #1031
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.210The system shall error if a score is requested, but not available in a tally.
Specification(s): missing_score
Design: FDTallyGradAux
Issue(s): #1031
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.23.211The system shall error if the external filter bin provided by the user is out of bounds for the filters applied to the given score.
Specification(s): invalid_bin_index
Design: FDTallyGradAux
Issue(s): #1031
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException

cardinal: NekPointValue
1.25.12
The system shall interpolate the NekRS solution onto a given point. This is tested by analytically comparing known initial conditions from NekRS against function evaluations for
1. dimensional form
2. non-dimensional form
3. non-dimensional scaling of usrwrk slots for which the units are known
Specification(s): pp/points, pp/nondimensional, pp/usrwrk_units
Design: NekPointValue
Issue(s): #1015 #1016 #1079
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.25.13
The system shall warn the user if dimensionalization is requested and cannot be performed, for
1. usrwrk slot 0
2. usrwrk slot 1
3. usrwrk slot 2
Specification(s): warn/u00, warn/u01, warn/u02
Design: NekPointValue
Issue(s): #1015 #1016 #1079
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException

cardinal: NekSideAverage
1.25.17NekSideAverage shall correctly compute area-averaged temperatures on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same averages using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the pyramid.udf. Perfect agreement is not to be expected, since the underlying basis functions and quadrature rules are different between nekRS and MOOSE's linear Lagrange variables - we just require that they are reasonably close.
Specification(s): nek_side_average
Design: NekSideAverage
Issue(s): #1015
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: NekVolumeAverage
1.25.24dimensional form
Specification(s): nek
Design: NekVolumeAverage
Issue(s): #1065
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.25.25nondimensional form
Specification(s): nondimensional
Design: NekVolumeAverage
Issue(s): #1065
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: NekVolumeIntegral
1.25.28dimensional form
Specification(s): nek
Design: NekVolumeIntegral
Issue(s): #1065
Collection(s): FUNCTIONAL
Type(s): CSVDiff
1.25.29nondimensional form
Specification(s): nondimensional
Design: NekVolumeIntegral
Issue(s): #1065
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: Reactivity
1.25.34The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.
Specification(s): k_eigenvalue
Design: Reactivity
Issue(s): #1051
Collection(s): FUNCTIONAL
Type(s): CSVDiff

cardinal: OpenMCTallyEditor
1.30.68
The system shall error if
1. trying to edit a non-existant tally
2. trying to add a nuclide not accessible in the cross section library
3. trying to add an invalid score to a tally
4. the filter referenced by an OpenMCFilterEditor via ID does not exist and is not flagged for creation
5. an OpenMCDomainFilter editor exists with the same filter ID but a different filter type
6. more than one OpenMCDomainFilterEditor eixsts with the same filter ID
7. more than one OpenMCTallyEditor eixsts with the same tally ID
8. an OpenMCTallyEditor eixsts for a mapped tally created by Cardinal
Specification(s): errors/nonexistent_tally, errors/nonexistent_nuclide, errors/invalid_score, errors/nonexistent_filter, errors/clashing_filter_types, errors/clashing_filter_ids, errors/clashing_tally_ids, errors/clashing_mapped_tally
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.30.69Ensure that nuclides specified by a tally editor UO are present in the tally output
Specification(s): nuclides
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.70Ensure that the scattering score specified by a tally editor UO are present in the tally output
Specification(s): scatter_tally
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.71Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output
Specification(s): absorption_u238
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.72Ensure that a cell filter specified by a tally editor UO are present in the tally output
Specification(s): add_cell_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.73Ensure that a material filter specified by a tally editor UO are present in the tally output
Specification(s): add_material_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.74Ensure that a universe filters specified by a tally editor UO are present in the tally output
Specification(s): add_universe_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles

cardinal: OpenMCDomainFilterEditor
1.30.68
The system shall error if
1. trying to edit a non-existant tally
2. trying to add a nuclide not accessible in the cross section library
3. trying to add an invalid score to a tally
4. the filter referenced by an OpenMCFilterEditor via ID does not exist and is not flagged for creation
5. an OpenMCDomainFilter editor exists with the same filter ID but a different filter type
6. more than one OpenMCDomainFilterEditor eixsts with the same filter ID
7. more than one OpenMCTallyEditor eixsts with the same tally ID
8. an OpenMCTallyEditor eixsts for a mapped tally created by Cardinal
Specification(s): errors/nonexistent_tally, errors/nonexistent_nuclide, errors/invalid_score, errors/nonexistent_filter, errors/clashing_filter_types, errors/clashing_filter_ids, errors/clashing_tally_ids, errors/clashing_mapped_tally
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONALFAILURE_ANALYSIS
Type(s): RunException
1.30.69Ensure that nuclides specified by a tally editor UO are present in the tally output
Specification(s): nuclides
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.70Ensure that the scattering score specified by a tally editor UO are present in the tally output
Specification(s): scatter_tally
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.71Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output
Specification(s): absorption_u238
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.72Ensure that a cell filter specified by a tally editor UO are present in the tally output
Specification(s): add_cell_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.73Ensure that a material filter specified by a tally editor UO are present in the tally output
Specification(s): add_material_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles
1.30.74Ensure that a universe filters specified by a tally editor UO are present in the tally output
Specification(s): add_universe_filter
Design: OpenMCTallyEditor OpenMCDomainFilterEditor
Issue(s): #837
Collection(s): FUNCTIONAL
Type(s): CheckFiles

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

[h]
  type = CSVDiff
  input = nek.i
  csvdiff = nek_out.csv
  requirement = 'The system shall compute a convective heat transfer coefficient using userobjects for the wall heat flux, wall temperature, and bulk temperature.'
  required_objects = 'NekRSProblem'
[]

[sfr_pincell]
  type = Exodiff
  input = nek_master.i
  exodiff = 'nek_master_out.e'
  min_parallel = 6
  custom_cmp = 'exodiff.cmp'
  heavy = true
  requirement = "A coupled MOOSE-nekRS pincell-fluid flow problem shall predict correct conservation of energy and realistic thermal solutions. Exact conservation of energy (based on the power imposed in the solid) will not be observed because some heat flux GLL points are also on Dirichlet boundaries, which win in boundary condition ties."
  required_objects = 'NekRSProblem'
  max_time = 500
[]

[sfr_pincell_vpp]
  type = Exodiff
  input = nek_main_vpp.i
  exodiff = 'nek_master_out.e'
  min_parallel = 6
  custom_cmp = 'exodiff_vpp.cmp'
  heavy = true
  requirement = "Individually conserving heat flux sideset by sideset shall give equivalent results to the all-combined option when there is just one coupling sideset. The gold file for this test is identical to that for the sfr_pincell case."
  required_objects = 'NekRSProblem'
  max_time = 500
[]

[impose_heat_flux]
  type = CSVDiff
  input = nek_isolated.i
  csvdiff = nek_isolated_out.csv
  min_parallel = 6
  requirement = "The system shall allow imposing heat flux through a dummy main application, instead of coupling NekRS via conjugate heat transfer. This is verified by computing the heat flux on the NekRS mesh, which adequately matches an initial value set in a postprocessor. This gold file is also identical to that obtained by running a dummy main app (solid_dummy) that passes in the desired flux_integral initial condition."
  required_objects = 'NekRSProblem'
  issues = '#797'
[]

[prioritize_refine_and]
  type = CSVDiff
  input = 'prioritize_refine_and.i'
  csvdiff = 'prioritize_refine_and_out.csv'
  requirement = 'The system shall be able to prioritize refinement while ANDing markers together.'
[]

[prioritize_coarsen_and]
  type = CSVDiff
  input = 'prioritize_refine_and.i'
  csvdiff = 'prioritize_refine_and_out.csv'
  cli_args = 'Adaptivity/Markers/combo/priority=coarsening'
  requirement = 'The system shall be able to prioritize coarsening while ANDing markers together.'
[]

[prioritize_refine_or]
  type = CSVDiff
  input = 'prioritize_refine_and.i'
  csvdiff = 'prioritize_refine_or_out.csv'
  cli_args = 'Adaptivity/Markers/combo/boolean_operator=or Outputs/file_base=prioritize_refine_or_out'
  requirement = 'The system shall be able to prioritize refinement while ORing markers together.'
[]

[prioritize_coarsen_or]
  type = CSVDiff
  input = 'prioritize_refine_and.i'
  csvdiff = 'prioritize_coarsen_or_out.csv'
  cli_args = 'Adaptivity/Markers/combo/boolean_operator=or Adaptivity/Markers/combo/priority=coarsening Outputs/file_base=prioritize_coarsen_or_out'
  requirement = 'The system shall be able to prioritize coarsening while ORing markers together.'
[]

[adaptive_cell]
  type = Exodiff
  input = cell.i
  exodiff = cell_out.e
  requirement = "The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_mesh]
  type = Exodiff
  input = mesh.i
  exodiff = mesh_out.e
  mesh_mode = 'replicated'
  requirement = "The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_mesh_template]
  type = RunException
  input = mesh.i
  cli_args = "Problem/Tallies/Mesh/mesh_template='../meshes/sphere.e'"
  mesh_mode = 'replicated'
  expect_err = "Adaptivity is not supported when loading a mesh from 'mesh_template'!"
  requirement = "The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_relaxation]
  type = RunException
  input = cell.i
  cli_args = "Problem/relaxation='constant'"
  expect_err = "When adaptivity is requested or a displaced problem is used, the mapping from the OpenMC model to the \[Mesh\] may vary in time."
  requirement = "The system shall error if adaptivity is active and a relaxation scheme is requested."
  required_objects = 'OpenMCCellAverageProblem'
[]

[skip_openmc_unchanged]
  type = Exodiff
  input = unchanged_mesh.i
  exodiff = unchanged_mesh_out.e
  mesh_mode = 'replicated'
  requirement = "The system shall skip running OpenMC when the mesh is unchanged by adaptivity."
  required_objects = 'OpenMCCellAverageProblem'
[]

[skip_openmc_unchanged_picard]
  type = Exodiff
  input = unchanged_main.i
  exodiff = unchanged_main_out.e
  requirement = "The system shall run OpenMC on the first Picard iteration regardless of the mesh being previouslyunchanged by adaptivity. This test relies on noise in the solution; if OpenMC runs more than onceper Picard iteration the PRNG seed changes and so the tally results will be different."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_cell]
  type = Exodiff
  input = cell.i
  exodiff = cell_out.e
  requirement = "The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_mesh]
  type = Exodiff
  input = mesh.i
  exodiff = mesh_out.e
  mesh_mode = 'replicated'
  requirement = "The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_mesh_template]
  type = RunException
  input = mesh.i
  cli_args = "Problem/Tallies/Mesh/mesh_template='../meshes/sphere.e'"
  mesh_mode = 'replicated'
  expect_err = "Adaptivity is not supported when loading a mesh from 'mesh_template'!"
  requirement = "The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block."
  required_objects = 'OpenMCCellAverageProblem'
[]

[adaptive_relaxation]
  type = RunException
  input = cell.i
  cli_args = "Problem/relaxation='constant'"
  expect_err = "When adaptivity is requested or a displaced problem is used, the mapping from the OpenMC model to the \[Mesh\] may vary in time."
  requirement = "The system shall error if adaptivity is active and a relaxation scheme is requested."
  required_objects = 'OpenMCCellAverageProblem'
[]

[skip_openmc_unchanged]
  type = Exodiff
  input = unchanged_mesh.i
  exodiff = unchanged_mesh_out.e
  mesh_mode = 'replicated'
  requirement = "The system shall skip running OpenMC when the mesh is unchanged by adaptivity."
  required_objects = 'OpenMCCellAverageProblem'
[]

[skip_openmc_unchanged_picard]
  type = Exodiff
  input = unchanged_main.i
  exodiff = unchanged_main_out.e
  requirement = "The system shall run OpenMC on the first Picard iteration regardless of the mesh being previouslyunchanged by adaptivity. This test relies on noise in the solution; if OpenMC runs more than onceper Picard iteration the PRNG seed changes and so the tally results will be different."
  required_objects = 'OpenMCCellAverageProblem'
[]

[all_h]
  type = Exodiff
  input = 'openmc.i'
  exodiff = 'openmc_out.e'
  requirement = 'The system shall allow for the calculation of the optical depth using the min/max vertex separation or the cube root of the element volume.'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[not_rxn_rate]
  type = RunException
  input = 'openmc.i'
  cli_args = 'Adaptivity/Indicators/optical_depth_hmin/rxn_rate=kappa_fission'
  requirement = 'The system shall error if a non-reaction rate score is provided to ElementOpticalDepthIndicator.'
  expect_err = 'At present the ElementOpticalDepthIndicator only works with reaction rate scores. kappa_fission is not a valid reaction rate score.'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[missing_score]
  type = RunException
  input = 'openmc.i'
  cli_args = 'Adaptivity/Indicators/optical_depth_hmin/rxn_rate=fission'
  requirement = 'The system shall error if a a reaction rate score is requested, but not available in a tally.'
  expect_err = 'The problem does not contain any score named fission!'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[missing_flux]
  type = RunException
  input = 'openmc.i'
  cli_args = 'Problem/Tallies/Mesh/score="kappa_fission total"'
  requirement = 'The system shall error if the flux is not available in a tally.'
  expect_err = 'In order to use an ElementOpticalDepthIndicator one of your'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[gradients]
  type = Exodiff
  input = 'openmc.i'
  exodiff = 'openmc_out.e'
  requirement = 'The system shall allow for the approximation of tally gradients using finite differences.'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[not_const_mon]
  type = RunException
  input = 'openmc.i'
  cli_args = 'AuxVariables/grad_kappa_fission/order=FIRST'
  requirement = 'The system shall error if the variable provided to FDTallyGradAux is not of type CONSTANT MONOMIAL_VEC.'
  expect_err = 'FDTallyGradAux only supports CONSTANT MONOMIAL_VEC shape functions.'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[missing_score]
  type = RunException
  input = 'openmc.i'
  cli_args = 'AuxKernels/comp_grad_kappa_fission/score=fission'
  requirement = 'The system shall error if a score is requested, but not available in a tally.'
  expect_err = 'The problem does not contain any score named fission!'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[invalid_bin_index]
  type = RunException
  input = 'openmc.i'
  cli_args = 'AuxKernels/comp_grad_kappa_fission/ext_filter_bin=1'
  requirement = 'The system shall error if the external filter bin provided by the user is out of bounds for the filters applied to the given score.'
  expect_err = 'The external filter bin provided is invalid'
  mesh_mode = 'replicated'
  required_objects = 'OpenMCCellAverageProblem'
[]

[usrwrk_units]
  type = CSVDiff
  input = usrwrk_units.i
  csvdiff = usrwrk_units_out.csv
  detail = 'non-dimensional scaling of usrwrk slots for which the units are known'
  required_objects = 'NekRSProblem'
[]

[u00]
  type = RunException
  input = unknown.i
  cli_args = 'Postprocessors/usrwrk/field=usrwrk00 --error'
  expect_err = "The units of 'usrwrk00' are unknown, so we cannot dimensionalize any objects using 'field = usrwrk00'."
  detail = 'usrwrk slot 0'
  required_objects = 'NekRSProblem'
[]

[u01]
  type = RunException
  input = unknown.i
  cli_args = 'Postprocessors/usrwrk/field=usrwrk01 --error'
  expect_err = "The units of 'usrwrk01' are unknown, so we cannot dimensionalize any objects using 'field = usrwrk01'."
  detail = 'usrwrk slot 1'
  required_objects = 'NekRSProblem'
[]

[u02]
  type = RunException
  input = unknown.i
  cli_args = '--error'
  expect_err = "The units of 'usrwrk02' are unknown, so we cannot dimensionalize any objects using 'field = usrwrk02'."
  detail = 'usrwrk slot 2'
  required_objects = 'NekRSProblem'
[]

[nek_side_average]
  type = CSVDiff
  input = nek.i
  csvdiff = nek_out.csv
  rel_err = 1e-2
  requirement = "NekSideAverage shall correctly compute area-averaged temperatures on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same averages using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the pyramid.udf. Perfect agreement is not to be expected, since the underlying basis functions and quadrature rules are different between nekRS and MOOSE's linear Lagrange variables - we just require that they are reasonably close."
  required_objects = 'NekRSProblem'
  issues = '#1015' # not finished
[]

[k_eigenvalue]
  type = CSVDiff
  input = openmc.i
  csvdiff = 'openmc_out.csv'
  # This test has very few particles, and OpenMC will error if there aren't enough source particles
  # in the fission bank on a process
  max_parallel = 8
  requirement = "The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution."
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_tally]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/tally_id=3000'
  expect_err = 'Tally 3000 does not exist in the OpenMC model'
  detail = 'trying to edit a non-existant tally'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_nuclide]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/nuclides="fake fake2"'
  expect_err = "Nuclide 'fake' is not present in library."
  detail = "trying to add a nuclide not accessible in the cross section library"
  required_objects = 'OpenMCCellAverageProblem'
[]

[invalid_score]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/scores="invalid"'
  expect_err = 'Invalid tally score "invalid".'
  detail = 'trying to add an invalid score to a tally'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_filter]
  type = RunException
  input = add_filter.i
  cli_args = 'UserObjects/new_filter/create_filter=false'
  expect_err = 'Filter 100 does not exist and create_filter is false'
  detail = 'the filter referenced by an OpenMCFilterEditor via ID does not exist and is not flagged for creation'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_filter_types]
  type = RunException
  input = add_filter.i
  cli_args = 'UserObjects/new_filter/filter_type="universe" UserObjects/new_filter/filter_id=1'
  expect_err = 'An existing filter, Filter 1, is of type "cell" and cannot be changed to type "universe"'
  detail = 'an OpenMCDomainFilter editor exists with the same filter ID but a different filter type'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_filter_ids]
  type = RunException
  input = clashing_filter_ids.i
  expect_err = 'Filter ID \(10\) found in multiple OpenMCDomainFilterEditors'
  detail = 'more than one OpenMCDomainFilterEditor eixsts with the same filter ID'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_tally_ids]
  type = RunException
  input = clashing_tally_ids.i
  expect_err = 'Tally ID \(10\) found in multiple OpenMCTallyEditors'
  detail = 'more than one OpenMCTallyEditor eixsts with the same tally ID'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_mapped_tally]
  type = RunException
  input = clash_mapped_tally.i
  expect_err = 'Tally ID 3 is a tally which Cardinal has automatically created and is controlling'
  detail = 'an OpenMCTallyEditor eixsts for a mapped tally created by Cardinal'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nuclides]
  type = CheckFiles
  input = tally_param_checks.i
  check_files = tallies.out
  file_expect_out = 'U238'
  requirement = 'Ensure that nuclides specified by a tally editor UO are present in the tally output'
  cli_args = 'UserObjects/tally_editor_uo/nuclides="U238"'
  required_objects = 'OpenMCCellAverageProblem'
[]

[scatter_tally]
  type = CheckFiles
  input = scatter.i
  check_files = tallies.out
  requirement = 'Ensure that the scattering score specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Scattering Rate'
  required_objects = 'OpenMCCellAverageProblem'
[]

[absorption_u238]
  type = CheckFiles
  input = nuclide_absorption.i
  check_files = tallies.out
  requirement = 'Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output'
  file_expect_out = 'U238\n   Absorption Rate'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_cell_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  requirement = 'Ensure that a cell filter specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Cell'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_material_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  cli_args = 'UserObjects/new_filter/filter_type="material"'
  requirement = 'Ensure that a material filter specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Material'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_universe_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  cli_args = 'UserObjects/new_filter/filter_type="universe"'
  requirement = 'Ensure that a universe filters specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Universe'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_tally]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/tally_id=3000'
  expect_err = 'Tally 3000 does not exist in the OpenMC model'
  detail = 'trying to edit a non-existant tally'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_nuclide]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/nuclides="fake fake2"'
  expect_err = "Nuclide 'fake' is not present in library."
  detail = "trying to add a nuclide not accessible in the cross section library"
  required_objects = 'OpenMCCellAverageProblem'
[]

[invalid_score]
  type = RunException
  input = tally_param_checks.i
  cli_args = 'UserObjects/tally_editor_uo/scores="invalid"'
  expect_err = 'Invalid tally score "invalid".'
  detail = 'trying to add an invalid score to a tally'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nonexistent_filter]
  type = RunException
  input = add_filter.i
  cli_args = 'UserObjects/new_filter/create_filter=false'
  expect_err = 'Filter 100 does not exist and create_filter is false'
  detail = 'the filter referenced by an OpenMCFilterEditor via ID does not exist and is not flagged for creation'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_filter_types]
  type = RunException
  input = add_filter.i
  cli_args = 'UserObjects/new_filter/filter_type="universe" UserObjects/new_filter/filter_id=1'
  expect_err = 'An existing filter, Filter 1, is of type "cell" and cannot be changed to type "universe"'
  detail = 'an OpenMCDomainFilter editor exists with the same filter ID but a different filter type'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_filter_ids]
  type = RunException
  input = clashing_filter_ids.i
  expect_err = 'Filter ID \(10\) found in multiple OpenMCDomainFilterEditors'
  detail = 'more than one OpenMCDomainFilterEditor eixsts with the same filter ID'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_tally_ids]
  type = RunException
  input = clashing_tally_ids.i
  expect_err = 'Tally ID \(10\) found in multiple OpenMCTallyEditors'
  detail = 'more than one OpenMCTallyEditor eixsts with the same tally ID'
  required_objects = 'OpenMCCellAverageProblem'
[]

[clashing_mapped_tally]
  type = RunException
  input = clash_mapped_tally.i
  expect_err = 'Tally ID 3 is a tally which Cardinal has automatically created and is controlling'
  detail = 'an OpenMCTallyEditor eixsts for a mapped tally created by Cardinal'
  required_objects = 'OpenMCCellAverageProblem'
[]

[nuclides]
  type = CheckFiles
  input = tally_param_checks.i
  check_files = tallies.out
  file_expect_out = 'U238'
  requirement = 'Ensure that nuclides specified by a tally editor UO are present in the tally output'
  cli_args = 'UserObjects/tally_editor_uo/nuclides="U238"'
  required_objects = 'OpenMCCellAverageProblem'
[]

[scatter_tally]
  type = CheckFiles
  input = scatter.i
  check_files = tallies.out
  requirement = 'Ensure that the scattering score specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Scattering Rate'
  required_objects = 'OpenMCCellAverageProblem'
[]

[absorption_u238]
  type = CheckFiles
  input = nuclide_absorption.i
  check_files = tallies.out
  requirement = 'Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output'
  file_expect_out = 'U238\n   Absorption Rate'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_cell_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  requirement = 'Ensure that a cell filter specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Cell'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_material_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  cli_args = 'UserObjects/new_filter/filter_type="material"'
  requirement = 'Ensure that a material filter specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Material'
  required_objects = 'OpenMCCellAverageProblem'
[]

[add_universe_filter]
  type = CheckFiles
  input = add_filter.i
  check_files = tallies.out
  cli_args = 'UserObjects/new_filter/filter_type="universe"'
  requirement = 'Ensure that a universe filters specified by a tally editor UO are present in the tally output'
  file_expect_out = 'Universe'
  required_objects = 'OpenMCCellAverageProblem'
[]

Introduction
Definitions and Acronyms
Design Stakeholders and Concerns
System Design
Requirements Cross - Reference
References
ActionComponents
Adaptivity
Application
AuxKernels
AuxScalarKernels
AuxVariables
BCs
Bounds
Cardinal
Closures
Components
Constraints
ControlLogic
Controls
Correctors
CoupledHeatTransfers
Covariance
DGKernels
Dampers
Debug
DeprecatedBlock
DiracKernels
Distributions
DomainIntegral
Executioner
Executors
FVBCs
FVICs
FVInterfaceKernels
FVKernels
FluidProperties
FluidPropertiesInterrogator
Functions
FunctorMaterials
GlobalParams
GrayDiffuseRadiation
HDGBCs
HDGKernels
HeatStructureMaterials
ICs
InterfaceKernels
Kernels
Likelihood
LinearFVBCs
LinearFVKernels
Materials
Mesh
MeshDivisions
MeshModifiers
Modules
MortarGapHeatTransfer
MultiApps
NEML2
NodalKernels
NodalNormals
Outputs
ParameterStudy
Physics
Positions
Postprocessors
Preconditioning
Problem
ProjectedStatefulMaterialStorage
RayBCs
RayKernels
Reporters
Samplers
ScalarKernels
SolidProperties
StochasticTools
Surrogates
ThermalContact
Times
Trainers
Transfers
UserObjects
VariableMappings
Variables
VectorPostprocessors