Cardinal System Requirements Specification

System Purpose

The purpose of Cardinal is to perform fully integrated, high-fidelity, multiphysics simulations of nuclear energy systems at high-fidelity with a variety of materials, system configurations, and component designs in order to better understand system performance. Cardinal's main goal is to bring together the combined multiphysics capabilities of the MOOSE ecosystem with leading high-performance tools for radiation transport (OpenMC) and Navier-Stokes fluid flow (NekRS) in an open platform for research, safety assessment, engineering, and design studies of nuclear energy systems.

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.

System Context

The Cardinal application is command-line driven. Like MOOSE, this is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all 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. Cardinal does not maintain any back-end database or interact with any system daemons. It is an executable, which may be launched from the command line and writes out various result files as it runs.

Figure 1: Usage of Cardinal and other MOOSE-based applications.

System Functions

Since Cardinal is a command-line driven application, all functionality provided in the software is operated through the use of standard UNIX command line flags and the extendable MOOSE input file. Cardinal is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.

User Characteristics

Cardinal has two main classes of users:

• Cardinal Developers: These are the core developers of Cardinal. They are responsible for designing, implementing, and maintaining the software, while following and enforcing its software development standards. These scientists and engineers modify or add capabilities to Cardinal for their own purposes, which may include research or extending its capabilities. They will typically have a background in thermal-fluids and/or radiation transport, as well as in modeling and simulation techniques.

• Analysts: These are users that run Cardinal to run simulations, but do not develop code. The primary interface of these users with Cardinal is the input files that define their simulations. These users may interact with developers of the system requesting new features and reporting bugs found.

Assumptions and Dependencies

The Cardinal application is developed using MOOSE and is based on various modules, as such the SRS for Cardinal is dependent upon the files listed at the beginning of this document. Any further assumptions or dependencies are outlined in the remainder of this section.

Cardinal has no constraints on hardware and software beyond those of the MOOSE framework, MOOSE modules, OpenMC, NekRS, and DAGMC, as listed in their respective SRS documents, which are accessible through the links at the beginning of this document.

Cardinal provides access to a number of code objects that perform computations, such as particle transport, material behavior, and boundary conditions. These objects each make their own physics-based assumptions, such as the units of the inputs and outputs. Those assumptions are described in the documentation for those individual objects.

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

Functional Requirements

• cardinal: Auxkernels
• 1.1.1The system shall divide space into a 3-D Cartesian grid and assign an integer value for each bin to an auxiliary variable.
• 1.1.2The system shall compute a convective heat transfer coefficient using userobjects for the wall heat flux, wall temperature, and bulk temperature.
• 1.1.3System shall error if auxkernel is not paired with a compatible bin user object.
• 1.1.4System shall error if auxkernel is not paired with a velocity vector bin user object.

• cardinal: Bison Coupling
• 1.2.1Cardinal shall be able to run BISON as a main application without any data transfers. This test just ensures correct setup of BISON as a submodule with app registration.
• 1.2.2Cardinal shall be able to run BISON as a sub-application without any data transfers. This test just ensures correct setup of BISON as a submodule with app registration.

• cardinal: Cht
• 1.3.1The system shall correctly evaluate volume postprocessors for a dimensional NekRS solve on a conjugate heat transfer mesh. We test this by repeating the same integrals of the mapped data on the MOOSE mesh, and show exact equivalence.
• 1.3.2A coupled MOOSE-nekRS pincell-fluid flow problem shall predict correct conservation of energy and realistic thermal solutions when nekRS is run in nondimensional form. A wide variety of postprocessors are measured and compared against the same problem in dimensional form in the ../sfr_pincell directory. Most measurements match exactly, but there is about a 0.1% difference in temperatures (this is to be expected, though, because the solve is not exactly the same between a nondimensional and dimensional case - the governing equation is the same, but not necessarily the number of iterations, etc. For expediency in the test suite, only several time steps are run instead of the full approach to pseudo-steady state, though the pseudo-steady solution is what is compared for developing the test.
• 1.3.3A coupled MOOSE-nekRS pincell-fluid flow problem shall predict correct conservation of energy and realistic thermal solutions when nekRS is run in nondimensional form using an exact mesh mirror. This solution was compared to the sfr_pincell case, and results are very similar with only small differences due to the different mesh mirror representations.
• 1.3.4A coupled MOOSE-nekRS pebble flow problem shall predict physically realistic conjugate heat transfer when using an initial offset in the scratch space. The gold file was created when using no offset to prove equivalence.
• 1.3.5A coupled MOOSE-nekRS pebble flow problem shall predict physically realistic conjugate heat transfer.
• 1.3.6The system shall be able to output the pressure and velocity solution from NekRS when coupling to MOOSE.
• 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 (and the finite element method does not conserve power).
• 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.
• 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.

• cardinal: Conduction
• 1.4.1A coupled MOOSE-nekRS heat conduction problem shall produce the correct temperature distribution when (1) a heat source is applied in the nekRS volume and (2) a heat flux is imposed in nekRS through a boundary. The same problem is created in a standalone MOOSE simulation, in moose.i. Temperatures agree to within 0.2%, and the agreement can be made better by using finer meshes in the coupled Cardinal case.
• 1.4.2The system shall couple NekRS to MOOSE through simultaneous boundary heat flux and volumetric heating when using an exact mesh mirror. The solution is nearly identical to the pyramid test and the usrwrk output for flux and volumetric heating match the auxiliary variables in the Nek-wrapped input.
• 1.4.3The system shall error if the user specifies a duplicate variable with a name overlapping with special names reserved for Cardinal data transfers.
• 1.4.4A coupled MOOSE-nekRS slab heat conduction problem shall predict the correct interface and volume temperatures based on an analytic solution. The MOOSE portion of the domain (the left half) is compared against an exodiff with this test, while the nekRS portion of the domain (the right half) has been compared off-line at the time of the generation of this test to the known analytic solution via line plot in Paraview (this has to be done offline because the 'visnek' script needs to be run to get the nekRS output results into the exodus format. A heat conduction simulation performed with MOOSE over the combined nekRS-MOOSE domain in the 'moose.i' input file also matches the coupled results very well.
• 1.4.5A coupled MOOSE-nekRS two-region pyramid heat conduction problem shall predict the correct interface and volume temperatures that are obtained from a standalone MOOSE heat conduction simulation in the moose.i file of both pyramid blocks. Because only a constant heat flux is passed for each element during the data transfer from MOOSE to nekRS, we do not expect the results to match perfectly with the MOOSE standalone case (which represents the heat flux internally as a continuous function (as opposed to elementwise-constant). We compare extrema temperature values on the two pyramid blocks with the MOOSE solution, and see that (1) the overall temperature distribution matches qualitatively, and (2) the difference between the Cardinal case and the MOOSE standalone case decreases as the mesh is refined (i.e. as the effect of the constant monomial surface heat flux is lowered). Even with the fairly coarse mesh used in this test, the errors in temperature are less than 1% of the total temperature range in the problem (but can locally be high relative differences).
• 1.4.6A coupled MOOSE-nekRS slab heat conduction problem shall produce the correct temperature distribution when a heat source is applied to the nekRS problem. A reference MOOSE standalone problem (in moose.i) solves the equation k*nabla(T)7*T, i.e. the 'heat source' is 7*T. This surrogate problem is then repeated with Cardinal, where nekRS solves the k*nabla(T)q, where q is a heat source 'computed' by MOOSE to be 7*T_n, where T_n is the temperature from nekRS. This problem does not really represent any interesting physical case, but is solely intended to show that nekRS correctly solves the heat equation with a heat source 'computed' by some other app. The solution matches the standalone MOOSE case very well - with a nekRS mesh of 15x15x15 elements, postprocessors for the side- and volume-averaged temperature, as well as maximum temperature, match the MOOSE standalone case to within 0.1%. To keep the gold files small here, this test is only performed on a 7x7x7 nekRS mesh.
• 1.4.7A coupled MOOSE-nekRS two-region cylinder heat conduction problem shall predict the correct interface and volume temperatures that are obtained from a standalone MOOSE heat conduction simulation in the moose.i file of both cylinders. Because only a constant heat flux is passed for each element during the data transfer from MOOSE to nekRS, we do not expect the results to match perfectly with the MOOSE standalone case (which represents the heat flux internally as a continuous function (as opposed to elementwise-constant). We compare extrema temperature values on the two cylinders with the MOOSE solution, and see that (1) the overall temperature distribution matches qualitatively, and (2) the difference between the Cardinal case and the MOOSE standalone case decreases as the mesh is refined (i.e. as the effect of the constant monomial surface heat flux is lowered). Even with the fairly coarse mesh used in this test, the errors in temperature are less than 0.5%.As the BISON mesh is refined, the error continually decreases until the temperatures are very close to those predicted by the standalone MOOSE case.
• 1.4.8The same solution shall be obtained as the cylinder_conduction case when nekRS is run with a smaller time step than MOOSE with subcycling. The run will not require the the same overall number of time steps as the cylinder_conduction test, so we just compare some postprocessor values at the end of the simulation. These CSV results are less than 1e-3 different from those for the cylinder_conduction case, so the simulation process is equivalent. We don't use exactly the same CSV gold file because the number of time steps differs, and would trigger a failure.
• 1.4.9The same solution shall be obtained when nekRS is run before MOOSE. We compare CSV results against those for the cylinder_conduction case, which match wo within 1e-5. We don't use exactly the same CSV gold file because the number of time steps differ, and would trigger a failure.
• 1.4.10The same solution shall be obtained when nekRS is run as a sub-app with minimized transfers for in the incoming and outgoing data transfers. We compare against the same CSV file used for the cylinder_conduction_subcycle case because the results should be exactly the same.
• 1.4.11The system shall support an exact NekRS mesh mirror. The solution is compared against the cylinder_conduction case and nearly identical solutions are obtained.
• 1.4.12A coupled MOOSE-nekRS cylinder heat conduction problem shall produce the correct temperature distribution when a heat source is applied to the nekRS problem, and when the meshes do not perfectly line up (i.e. the volumes are different). A reference MOOSE standalone problem (in moose.i) solves the equation k*nabla(T)7*T, i.e. the 'heat source' is f(T,x,z). This surrogate problem is then repeated with Cardinal, where nekRS solves the k*nabla(T)q, where q is a heat source 'computed' by MOOSE to be f(T_n,x,z), where T_n is the temperature from nekRS. This problem does not really represent any interesting physical case, but is solely intended to show that nekRS correctly solves the heat equation with a heat source 'computed' by some other app. The solution matches the standalone MOOSE case very well - postprocessors for the volume-averaged and maximum temperature match the MOOSE standalone case to within 0.1%.
• 1.4.13The system shall couple NekRS to MOOSE through volumetric heating when using an exact mesh mirror. The output file was compared against the cylinder_heat_source test, giving very similar answers. The heat source sent into NekRS was also checked with the usrwrk_output feature.
• 1.4.14A coupled MOOSE-nekRS cylinder heat conduction problem shall produce the correct temperature distribution when a heat source is applied to the nekRS problem, and the nekRS solve is conducted in nondimensional scales. Temperatures match to within 0.1% between the nondimensional version and the dimensional version in ../cylinder.
• 1.4.15The system shall allow MOOSE and NekRS to be coupled via conjugate heat transfer, where MOOSE sends NekRS a wall temperature and NekRS sends MOOSE a wall heat flux. This is tested by building a two-region slab, where the left half is solved by MOOSE and the right-half is solved by NekRS. The analytic solution for temperature is compared against the coupled CHT solution.
• 1.4.16The NekRS wrapping shall allow a zero total flux to be sent from MOOSE to NekRS when all sidesets are conserved together.
• 1.4.17The NekRS wrapping shall allow a zero total flux to be sent from MOOSE to NekRS when sidesets are individually conserved.
• 1.4.18The NekRS wrapping shall allow unique sideset fluxes provided that the sidesets do not share any nodes in the NekRS mesh.
• 1.4.19The NekRS wrapping shall allow unique sideset fluxes provided that the sidesets do not share any nodes in the NekRS mesh, with some sidesets being zero flux.
• 1.4.20The system shall print a helpful error message if the sideset flux reporter does not have the correct length.
• 1.4.21The system shall error if conserving flux on each unique sideset, but with nodes shared across multiple sidesets.

• cardinal: Controls
• 1.5.1The system shall error if the controls is not used with the proper user object
• 1.5.2The system shall change OpenMC material compositions via a controls

• cardinal: Criticality
• 1.6.1The system shall error if an invalid minimum boron ppm is provided.
• 1.6.2The system shall error if an invalid maximum boron ppm is provided.
• 1.6.3The system shall warn the user if nuclides will be erased by the borated water criticality search. This test covers both non-H,B,O elements as well as non-natural isotopes of these elements.
• 1.6.4The system shall warn the user if they are omitting a nuclide from their cross section library which is irrelevant for boric acid control.
• 1.6.5The system shall perform a criticality search based on boron weight ppm in water. This test changes the water density and then searches for a criticality point; the resulting ppm is compared to a standalone OpenMC model (the comparison is done when running with many more particles for both scenarios). The multiplication factors agree within statistics. Due to floating point non-determinism, the actual test only compares that k matches unity within the desired convergence tolerance.
• 1.6.6The system shall error if a criticality search is not paired with the correct problem class.
• 1.6.7The system shall error if invalid values are provided for the range of values to consider for the criticality search.
• 1.6.8The system shall warn if the selected tolerance might cause failure to converge due to high statistical noise.
• 1.6.9The system shall error if the criticality search does not converge.
• 1.6.10The system shall conduct a criticality search based on material density. This test is created by running a criticality search with a high particle count (1-sigma less than 10 pcm on k) and comparing the critical search result against a standalone OpenMC simulation which is run at the identified critical value of material density. The two approaches match within statistics. Due to floating point non-determinism, the actual test just checks that k converges to the target within the desired tolerance.
• 1.6.11The system shall conduct a criticality search with a non-unity target k. This test is created by running a criticality search with a high particle count (1-sigma less than 10 pcm on k) and comparing the critical search result against a standalone OpenMC simulation which is run at the identified critical value of material density. The two approaches match within statistics. Due to floating point non-determinism, the actual test just checks that k converges to the target within the desired tolerance.
• 1.6.12The system shall error if an invalid minimum density is provided.
• 1.6.13The system shall error if the minmum search value passed to a RotationSearch is negative.
• 1.6.14The system shall error if the maximum search value passed to a RotationSearch is greater than 360 degrees.
• 1.6.15The system shall conduct a criticality search by modifying a cell rotation. This test is created by running a criticality search with a high particle count (1-sigma less than 10 pcm on k) and comparing the critical search result against a standalone OpenMC simulation which is run at the identified critical value of material density. The two approaches match within statistics. Due to floating point non-determinism, the actual test just checks that k converges to the target within the desired tolerance.
• 1.6.16The system shall correctly remap MOOSE mesh elements and OpenMC cells on each step of a rotation criticality search. This ensures tallies are extracted properly and feedback is applied correctly. This test checks to see if the cell IDs are rotated correctly by point sampling a single element. This is more robust than checking kappa_fission from a cell tally as criticality searches are somewhat non-deterministic on CIVET.
• 1.6.17The system shall error if the user disables tallies and does not request a critical state calculation.

• cardinal: Griffin Coupling
• 1.8.1Cardinal shall be able to run Griffin as the main application.

• cardinal: Ics
• 1.9.1The volume postprocessor must have execute_on initial
• 1.9.2The system shall error if invalid parameters are provided
• 1.9.3The system shall be able to apply a normalized sinusoidal initial condition.
• 1.9.4The system shall error if the pairing heat source action is missing
• 1.9.5The system shall be able to apply a normalized sinusoidal initial condition.

• cardinal: Markers
• 1.10.1The system shall be able to prioritize refinement while ANDing markers together.
• 1.10.2The system shall be able to prioritize coarsening while ANDing markers together.
• 1.10.3The system shall be able to prioritize refinement while ORing markers together.
• 1.10.4The system shall be able to prioritize coarsening while ORing markers together.

• cardinal: Mesh
• 1.11.1The system shall be able to construct a triangular lattice mesh for three pin rings of gaps.
• 1.11.2The system shall be able to construct a triangular lattice mesh for two pin rings of gaps.
• 1.11.3The system shall be able to construct a triangular lattice mesh for one pin ring of gaps.
• 1.11.4The system shall be able to construct a triangular lattice mesh for three pin rings.
• 1.11.5The system shall be able to construct a triangular lattice mesh for two pin rings.
• 1.11.6The system shall be able to construct a triangular lattice mesh for one pin ring.
• 1.11.7The system shall be able to construct a triangular lattice mesh for three pin rings as face meshes.
• 1.11.8The system shall be able to construct a triangular lattice mesh for two pin rings as face meshes.
• 1.11.9The system shall be able to construct a triangular lattice mesh for one pin ring as face meshes.

• cardinal: Meshgenerators
• 1.12.1The system shall be able to generate a structured mesh in MOOSE from an OpenMC RegularMesh and with scaling; this is checked by comparing node coordinates and element count against the internal OpenMC mesh
• 1.12.2OpenMCMeshGenerator will accept more than one mesh generator from the same xml_directory
• 1.12.3Points generated inside the mesh produced by OpenMCMeshGenerator must correctly map to the mesh element IDs.
• 1.12.4Consistent scaling factors between OpenMCMeshGenerator and OpenMCCellAverageProblem must work
• 1.12.5OpenMCMeshGenerator must fail if the requested mesh type is not an OpenMC RegularMesh
• 1.12.6OpenMCMeshGenerator must fail if the requested regular mesh is 2D
• 1.12.7OpenMCMeshGenerator must fail if the requested regular mesh is 1D
• 1.12.8OpenMCMeshGenerator must fail if the requested mesh ID is not available in the OpenMC model
• 1.12.9Inconsistent scaling factors between OpenMCMeshGenerator (S1) and OpenMCCellAverageProblem (S2) must fail when S2 is not equal to S1
• 1.12.10Inconsistent scaling factors across multiple OpenMCMeshGenerators must fail
• 1.12.11OpenMCMeshGenerator must fail if there are two different xml_directoryvalues
• 1.12.12Inconsistent xml_directory values between OpenMCMeshGenerator and OpenMCCellAverageProblem (S2) must fail
• 1.12.13The system shall error if the boundary specified for corner fitting does not exist
• 1.12.14The system shall error if an invalid polygon boundary is provided
• 1.12.15The system shall error if the radius of curvature is too big to fit inside the polygon
• 1.12.16The system shall curve corners of a six-sided polygon with zero boundary layers
• 1.12.17The system shall curve corners of a six-sided polygon with zero boundary layers with translation in space
• 1.12.18The system shall error if applying a rotation angle to a polygon not centered on (0, 0)
• 1.12.19The system shall curve corners of a six-sided polygon when the input mesh does not have one edge of the polygon horizontal.
• 1.12.20The system shall error if the length of smoothing adjustments does not equal the number of polygon layers
• 1.12.21The system shall error if the length of smoothing adjustments are not set to valid values
• 1.12.22The system shall curve corners of a six-sided polygon with zero boundary layers and output QUAD8 elements
• 1.12.23The system shall error if an invalid element type is used with a quad9 to quad8 converter
• 1.12.24The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sideset.
• 1.12.25The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sidesets.
• 1.12.26The system shall error if the boundary specified for circular sideset fitting does not exist
• 1.12.27The system shall correctly rebuild a QUAD9 mesh as QUAD8 with default behavior of rebuilding all boundaries, and without any circular movement.
• 1.12.28The system shall correctly rebuild a QUAD9 mesh as QUAD8 with no sidesets retained.
• 1.12.29The system shall correctly rebuild a QUAD9 mesh as QUAD8 with custom behavior of rebuilding only some boundaries, and without any circular movement.
• 1.12.30The system shall error if the boundary specified for rebuilding sidesets does not exist
• 1.12.31The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving the outer boundary to fit a circle.
• 1.12.32The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving the inner boundary to fit a circle.
• 1.12.33The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving multiple boundaries to fit a circle.
• 1.12.34The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving multiple boundaries to fit a circle with origins not at (0, 0, 0).
• 1.12.35The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving one boundary to fit a circle when the origin is not at (0, 0, 0)
• 1.12.36The system shall error if a point is already located on the origin, because then it lacks a nonzero unit vector to move it to a circular surface.
• 1.12.37The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving one boundary to fit circles based on multiple origins, with boundary layers.
• 1.12.38The system shall error if there is an obvious mismatch between the number of boundary layers and the mesh.
• 1.12.39The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving one boundary to fit a circle and when the alignment axis is not the default (z).
• 1.12.40The system shall error if an invalid element type is used with a hex27 to hex20 converter
• 1.12.41The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sideset.
• 1.12.42The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sidesets.
• 1.12.43The system shall error if the boundary specified for circular sideset fitting does not exist
• 1.12.44The system shall correctly rebuild a HEX27 mesh as HEX20 with default behavior of rebuilding all boundaries, and without any circular movement.
• 1.12.45The system shall correctly rebuild a HEX27 mesh as HEX20 with no sidesets retained.
• 1.12.46The system shall correctly rebuild a HEX27 mesh as HEX20 with custom behavior of rebuilding only some boundaries, and without any circular movement.
• 1.12.47The system shall error if the boundary specified for rebuilding sidesets does not exist
• 1.12.48The system shall correctly rebuild a HEX27 mesh as HEX20 when moving the outer boundary to fit a circle.
• 1.12.49The system shall correctly rebuild a HEX27 mesh as HEX20 when moving the inner boundary to fit a circle.
• 1.12.50The system shall correctly rebuild a HEX27 mesh as HEX20 when moving multiple boundaries to fit a circle.
• 1.12.51The system shall correctly rebuild a HEX27 mesh as HEX20 when moving multiple boundaries to fit a circle with origins not at (0, 0, 0).
• 1.12.52The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit a circle when the origin is not at (0, 0, 0)
• 1.12.53The system shall error if the invalid values are used for the radii.
• 1.12.54The system shall error if the radius and boundary are not the same length.
• 1.12.55The system shall error if the origin and boundary are not the same length.
• 1.12.56The system shall error if the origin and boundary are not the same length.
• 1.12.57The system shall error if the origin entries are not the correct length.
• 1.12.58The system shall error if the origin entries are not the correct length.
• 1.12.59The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit circles based on multiple origins.
• 1.12.60The system shall error if the number of layers does not match the number of boundaries to move
• 1.12.61The system shall correctly rebuild a HEX27 mesh as HEX20 when moving sidesets with boundary layers to fit a cylinder surface.
• 1.12.62The system shall error if there is an obvious mismatch between the number of boundary layers and the mesh.
• 1.12.63The system shall correctly rebuild a HEX27 mesh as HEX20 when moving sidesets with multiple boundary layers to fit a cylinder surface.
• 1.12.64The system shall error if trying to set the origins in more than one manner
• 1.12.65The system shall error if invalid points are provided for the origins
• 1.12.66The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit circles based on multiple origins provided from a file.
• 1.12.67The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit a circle and when the alignment axis is not the default (z).
• 1.12.68The system shall generate a mesh for a sphere.
• 1.12.69The system shall move the nodes on a sphere boundary to the curved surface
• 1.12.70The system shall move the nodes on a sphere boundary to the curved surface when the sphere is offset from the origin

• cardinal: Model Modifiers
• 1.13.1The system shall error if trying to modify a cell which does not exist in the OpenMC model
• 1.13.2The system shall error if the number of materials provided to modify a cell fill does not match the number of instances of that cell
• 1.13.3The system shall error if a nonexistent material is to be applied to an OpenMC cell
• 1.13.4The system shall be able to modify the material(s) filling a cell prior to executing OpenMC. This is verified by creating a standalone OpenMC model with the final set of materials, compared to a different starting model whose cell's fill is modified via Cardinal.
• 1.13.5The system shall be able to modify the same material filling all instances of a distributed cell prior to executing OpenMC. This is verified by creating a standalone OpenMC model with the final set of materials, compared to a different starting model whose cell's fill is modified via Cardinal.
• 1.13.6The system shall be able to apply different materials filling all instances of a distributed cell prior to executing OpenMC. This is verified by creating a standalone OpenMC model with the final set of materials, compared to a different starting model whose cell's fill is modified via Cardinal.
• 1.13.7The system shall be able to read and assign instances of a distributed cell prior to executing OpenMC. It should also be able to get the same answer whether the list of materials is specified from the "material_ids" param or via a "materials_id_file". As such, the HDF5 file used in this test has the same ID list as the change_material_different_instances test, and so it should be able to match the results in the gold file different.csv. A python script to generate the HDF5 input file lives in this directory, as well as a copy of the h5 file.
• 1.13.8The system shall error if both the "material_ids" and "material_ids_file" are specified

• cardinal: Multiple Nek Apps
• 1.14.1Cardinal shall be able to run NekRS input files nested within subdirectories in the same fashion that a standalone NekRS case will
• 1.14.2The system shall error if an invalid directory path is provided for the case
• 1.14.3The system shall error if trying to write output files for a Nek input without sibling apps
• 1.14.4The system shall be able to run multiple Nek simulations translated throughout a master app's domain. This test compares against a MOOSE standalone case, and gives less than 0.3% difference in various temperature metrics.
• 1.14.5The correct output files shall be written when writing separate output files for repeated Nek simulation instances.

• cardinal: Nek Errors
• 1.15.1The system shall error if Cardinal has displacements associated with NekRSMesh, but there is no mesh solver.
• 1.15.2The system shall error if the Nek .par file has a mesh solverbut the nekRS .par file has no moving mesh (codedFixedValue) boundary in the Mesh block.
• 1.15.3The system shall error if Cardinal is using the NekRS mesh blending solver without indicating the moving boundary of interest
• 1.15.4The system shall error if NekRSMesh is not paired with displacements for moving mesh problems.
• 1.15.5The system shall error if Cardinal has solver=user in the par file's MESH block, but there is no volume mesh mirror.
• 1.15.6MOOSE shall throw an error if an invalid boundary is specified for a side postprocessor.
• 1.15.7The system shall throw an error if trying to use temperature as a field for cases that do not have a temperature variable
• 1.15.8The system shall throw an error if trying to use scalar01 as a field for problems that don't have a scalar01 variable.
• 1.15.9The system shall throw an error if trying to use scalar02 as a field for problems that don't have a scalar02 variable.
• 1.15.10The system shall throw an error if trying to use scalar03 as a field for problems that don't have a scalar03 variable.
• 1.15.11The system shall throw an error if trying to use usrwrk00 as a field for problems that don't have sufficient usrwrk slots.
• 1.15.12The system shall throw an error if trying to use usrwrk01 as a field for problems that don't have sufficient usrwrk slots.
• 1.15.13The system shall throw an error if trying to use usrwrk02 as a field for problems that don't have sufficient usrwrk slots.
• 1.15.14The system shall correctly allocate scratch by accessing only quantities on the flow mesh if there is no temperature variable
• 1.15.15The system shall error if the user manually specifies a duplicate name for an output field.
• 1.15.16The system shall error if the user manually specifies a duplicate name for an output field.
• 1.15.17The system shall error if NekRSProblem is not paired with the correct executioner.
• 1.15.18The system shall error if the Dimensionalize action is not paired with the correct problem.
• 1.15.19The system shall error if NekRSProblem is not paired with the correct mesh type.
• 1.15.20The system shall error if a Nek object is not paired with the correct problem.
• 1.15.21The system shall error if a NekRSMesh is used without a corresponding Nek-wrappedproblem.
• 1.15.22The system shall error if NekRSProblem is not paired with the correct time stepper.
• 1.15.23MOOSE shall throw an error if there is no receiving heat flux boundary condition on the nekRS boundaries that are coupled to MOOSE.
• 1.15.24MOOSE shall throw an error if an invalid boundary is specified for the construction of nekRS's mesh as a MooseMesh.
• 1.15.25The system shall error if there is a mismatch between the scaling of the mesh and NekRS problem.
• 1.15.26When using the minimized transfers setting, the default value for the postprocessor in the master application must not be zero.
• 1.15.27The system shall error if the same MPI communicator is used to set up more than one Nek case.
• 1.15.28The system shall throw an error if there is no heat source kernel when using volume coupling
• 1.15.29MOOSE shall throw a warning if there is no temperature passive scalar solve in NekRS when passing heat flux
• 1.15.30MOOSE shall throw a warning if there is no temperature passive scalar solve in NekRS when passing heat flux
• 1.15.31MOOSE shall throw an error if there is no temperature passive scalar variable initialized in nekRS for flux coupling.
• 1.15.32MOOSE shall throw an error if there is no temperature passive scalar variable initialized in nekRS for source coupling.
• 1.15.33MOOSE shall throw an error if the user attempts to allocate the scratch space arrays in NekRS, since they are automatically allocated by Cardinal.
• 1.15.34MOOSE shall throw an error if a single transfer tries to occupy the same slot more than once
• 1.15.35MOOSE shall throw an error if a attempting to write a field into a usrwrk slot which has not been allocated
• 1.15.36MOOSE shall throw an error if a attempting to write a scalar into a usrwrk slot which has not been allocated
• 1.15.37MOOSE shall throw an error if a attempting to write a field into a usrwrk slot already claimed by another field transfer
• 1.15.38MOOSE shall throw an error if a attempting to write a scalar into a usrwrk slot already claimed by a field transfer
• 1.15.39The system shall error when a boundary flux transfer is applied when there is not boundary coupling
• 1.15.40The system shall error when a volumetric source transfer is applied when there is not volume coupling
• 1.15.41The system shall error when the usrwrk slot request does not match the needed number of slots for a flux transfer
• 1.15.42The system shall error when the usrwrk slot request does not match the needed number of slots for a source transfer
• 1.15.43The system shall error if trying to use field transfer syntax only relevant for NekRS wrapped cases with a non-Nek case.
• 1.15.44The system shall error if trying to use scalar transfer syntax only relevant for NekRS wrapped cases with a non-Nek case.

• cardinal: Nek File Output
• 1.16.1The correct output file writing sequence shall occur when driven by Cardinal, showing that the indications to write output files are correctly handledf by a driver
• 1.16.2The correct output file writing sequence shall occur based on .par settings when NekRS is the master application and when an uneven time step division occurs.
• 1.16.3The correct output file writing sequence shall occur based on .par settings when NekRS is the master application and when an even time step division occurs.
• 1.16.4The correct output file writing sequence shall occur based on master executioner settings when NekRS is the sub application and when an uneven time step division occurs.
• 1.16.5The correct output file writing sequence shall occur based on master executioner settings when NekRS is the sub application and when the time steps are evenly divisible.
• 1.16.6The system shall allow the user to write the user scratch space slots to field files.
• 1.16.7The system shall write the correct usrwrk data into the scratch space. This is tested by reading the written aaa0.f00001 file into a new simulation and applying it to the scalars, such that various Cardinal postprocessors can read those values and confirm a match. This test checks that the scalar indices are correctly interpreted when a temperature scalar is present (the test does not work if temperature is present because NekRS tries to load the restart file into the 0th scalar, which is temperature.
• 1.16.8The system shall write the correct usrwrk data into the scratch space. This is tested by reading the written ccc0.f00001 file into a new simulation and applying it to the scalars, such that various Cardinal postprocessors can read those values and confirm a match. This test checks that the scalar indices are correctly interpreted when a temperature scalar is present (the test does not work if temperature is present because NekRS tries to load the restart file into the 0th scalar, which is temperature.

• cardinal: Nek Mesh
• 1.17.1The system shall be able to generate an exact first-order boundary mesh mirror.
• 1.17.2The system shall be able to generate an exact first-order volume mesh mirror.
• 1.17.3The system shall error if trying to build an exact mesh mirror that is second order.
• 1.17.4NekRSMesh shall construct a first-order surface mesh from a list of boundary IDs. The ordering for the nodes shall be based on the libMesh ordering.
• 1.17.5NekRSMesh shall construct a first-order volume mesh. The ordering for the nodes shall be based on the libMesh ordering.
• 1.17.6NekRSMesh shall construct a second-order surface mesh from a list of boundary IDs. The ordering of the nodes for each element shall also be based on the libMesh ordering.
• 1.17.7NekRSMesh shall construct a second-order volume mesh. The ordering of the nodes for each element shall also be based on the libMesh ordering.
• 1.17.8NekRSMesh shall correctly assign sideset IDs based on the nekRS boundary IDs. This is verified here by performing area integrals on sidesets defined in MOOSE, which exactly match area integrals performed internally in nekRS.
• 1.17.9NekRSMesh shall correctly assign sideset IDs based on the nekRS boundary IDs when using an exact mesh mirror. The areas are matched to the 'cube_sidesets' test.
• 1.17.10NekRSMesh shall correctly assign sideset IDs based on the nekRS boundary IDs. This is verified here by performing area integrals on sidesets defined in MOOSE, which exactly match area integrals performed internally in nekRS.
• 1.17.11NekRSMesh shall correctly assign sideset IDs based on the nekRS boundary IDs when using an exact mesh mirror. The areas are matched to the 'pyramid_sidesets' test.

• cardinal: Nek Output
• 1.18.1Nek-wrapped MOOSE cases shall be able to output the passive scalars from the Nek solution onto the mesh mirror.
• 1.18.2Nek-wrapped MOOSE cases shall be able to output any quantity in the field enumeration from NekRS onto the mesh mirror.
• 1.18.3The system shall error if trying to write a usrwrk slot greater than the total number of allocated slots
• 1.18.4The system shall error if there is a mismatch between parameter lengths for writing usrwrk field files
• 1.18.5The system shall error if the default choice for the field cannot be matched from the object name.

• cardinal: Nek Standalone
• 1.19.1The system shall support adaptive time stepping in NekRS when running as the main application.
• 1.19.2The system shall support adaptive time stepping in NekRS when running as the main application and with a non-dimensional formulation.
• 1.19.3Cardinal shall be able to run the channel NekRS example with a thin wrapper. We check postprocessor differences between equivalent operations taken directly on the NekRS solution arrays (for instance, a NekVolumeAverage) and directly on the extracted solution (for instance, an ElementAverageValue). We require that all the postprocessors match between these two renderings of the solution (on the GLL points versus on the mesh mirror). This verifies correct extraction of the NekRS solution with the 'output' parameter feature.
• 1.19.4Cardinal shall be able to run the conj_ht NekRS example with a thin wrapper while using postprocessors acting on either the fluid mesh or fluid+solid mesh.
• 1.19.5The system shall throw an error if trying to act on only the NekRS solid mesh for side postprocessors.
• 1.19.6Postprocessing shall be possible directly on restart files without running a simulation. Here, we compare several postprocessors from a case restarted from a field file against the identical case where variables are instead initialized in the .udf from functions.
• 1.19.7Cardinal shall be able to run the lowMach NekRS example with a thin wrapper when using a volume mesh mirror. We add postprocessors to let us compare min/max values printed to the screen by NekRS. We also check postprocessor differences between equivalent operations taken directly on the NekRS solution arrays (for instance, a NekVolumeAverage) and directly on the extracted solution (for instance, an ElementAverageValue). We require that all the postprocessors match between these two renderings of the solution (on the GLL points versus on the mesh mirror).
• 1.19.8Cardinal shall be able to run the channel NekRS example with a thin wrapper when using a boundary mesh mirror. We add postprocessors to let us compare min/max values printed to the screen by NekRS. We also check postprocessor differences between equivalent operations taken directly on the NekRS solution arrays (for instance, a NekSideAverage) and directly on the extracted solution (for instance, an ElementAverageValue). We require that all the postprocessors match between these two renderings of the solution (on the GLL points versus on the mesh mirror).
• 1.19.9The system shall properly modify both the NekRS start time and the time recognized by the MOOSE wrapping.
• 1.19.10The system shall be able to force NekRS to start on a MOOSE-specified start time. This is checked by looking for the existence of an output file that NekRS only writes at t = 1.0005, which is only reached if MOOSE properly sets a custom start time.

• cardinal: Nek Stochastic
• 1.20.1The system shall stochastic values to be sent from MOOSE to NekRS. This example sends time-dependent random values from MOOSE to NekRS. The values of the random variables are used to apply a Dirichlet boundary condition on temperature, which we confirm by looking at the value of temperature on the boundary using postprocessors.
• 1.20.2The system shall clear the cache before attempting the test with another set of ranks.
• 1.20.3The system shall stochastic values to be sent from MOOSE to NekRS. This example sends 3 values to 3 unique NekRS solves, without any restart or overlap of MPI communicators. We check that the values are properly received in the scratch space by using that value to set a dummy scalar01. We purposefully put this test in its own directory to prove that there are no requirements on precompilation.
• 1.20.4The system shall clear the cache before attempting the test with another set of ranks.
• 1.20.5The system shall stochastic values to be sent from MOOSE to NekRS. This example sends 3 values to 3 unique NekRS solves, without any restart or overlap of MPI communicators. We check that the values are properly received in the scratch space by using that value to set a dummy scalar01. We purposefully put this test in its own directory to prove that there are no requirements on precompilation.
• 1.20.6The system shall clear the cache before attempting the test with another set of ranks.
• 1.20.7The system shall stochastic values to be sent from MOOSE to NekRS. This example sends 3 values to 3 unique NekRS solves, without any restart or overlap of MPI communicators. We check that the values are properly received in the scratch space by using that value to set a dummy scalar01. We purposefully put this test in its own directory to prove that there are no requirements on precompilation.
• 1.20.8The system shall clear the cache before attempting the test with another set of ranks.
• 1.20.9The system shall allow an arbitrary offset at the start of the scratch space. We check this by using the first slot in the scratch space to set the value of scalar01, but use the subsequent slots to obtain data from MOOSE. We show that the scalar01 is unaffected by the Cardinal copy into the other part of the scratch space.
• 1.20.10The system shall stochastic values to be sent from MOOSE to NekRS. This example sends time-dependent random values from MOOSE to NekRS, where time synchronization is driven by the main app. The values of the random variables are used to fill SCALAR TWO with a constant value, which we then measure by outputting the scalar and applying postprocessors to it. This confirms that the random data we send to NekRS does correctly make it to device
• 1.20.11The system shall cause stochastic values to be sent from MOOSE to NekRS and write unique NekRS field files for each. By limiting this test to fewer MPI ranks than Apps, we also check that we still get the correct naming scheme
• 1.20.12The system shall launch multiple independent Nek solves (with multiple separate output files) when running in stochastic mode. We check this by loading the field files created by the driver_multi_fld test into new NekRS runs (the read0, read1, and read2 tests) tests as initial conditions and check that the values of the loaded fields match the stochastic values sent there.
• 1.20.13The system shall launch multiple independent Nek solves (with multiple separate output files) when running in stochastic mode. We check this by loading the field files created by the driver_multi_fld test into new NekRS runs (the read0, read1, and read2 tests) tests as initial conditions and check that the values of the loaded fields match the stochastic values sent there.
• 1.20.14The system shall launch multiple independent Nek solves (with multiple separate output files) when running in stochastic mode. We check this by loading the field files created by the driver_multi_fld test into new NekRS runs (the read0, read1, and read2 tests) tests as initial conditions and check that the values of the loaded fields match the stochastic values sent there.

• cardinal: Nek Temp
• 1.21.1The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh with an exact surface transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).
• 1.21.2The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh with an exact volume transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).
• 1.21.3The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh with a first-order surface transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).
• 1.21.4The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh with a first-order volume transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).
• 1.21.5The nekRS temperature solution shall be accurately reconstructed on with a second-order surface transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).
• 1.21.6The nekRS temperature solution shall be accurately reconstructed on with a second-order volume transfer. By setting an intial condition for temperature on the nekRS side and then setting 'solver = none', we show that the max/min error in that reconstructed temperature compared to a MOOSE function of the same form is O(1e-16).

• cardinal: Neutronics
• 1.22.1The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies.
• 1.22.2The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies.
• 1.22.3The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block.
• 1.22.4The system shall error if adaptivity is active and a relaxation scheme is requested.
• 1.22.5The system shall skip running OpenMC when the mesh is unchanged by adaptivity.
• 1.22.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.
• 1.22.7The system shall error if attempting to use an axisymmetric mesh mirror because MOOSE's element volume functions only return areas for axisymmetric.
• 1.22.8The system shall error if a sideset is assigned both vacuum and reflective BCs.
• 1.22.9The system shall error if a mesh side belongs to two different sidesets, one assigned vacuum and the other reflective boundary conditions.
• 1.22.10The system shall error if an internal DAGMC surface shared between two skinned regions is assigned vacuum boundary conditions from one side and reflective boundary conditions from the other.
• 1.22.11The system shall error if a vacuum BC is assigned to a sideset whose faces are interior to a single skinned region, since no DAGMC surface receives the boundary condition.
• 1.22.12The system shall error if a reflective BC is assigned to a sideset whose faces are interior to a single skinned region, since no DAGMC surface receives the boundary condition.
• 1.22.13The system shall error if an unknown sideset ID was used.
• 1.22.14The system shall error if a BC is assigned to a boundary that exists only as a nodeset.
• 1.22.15The system shall error if an unknown sideset name was used to assign BC.
• 1.22.16The system shall give identical Monte Carlo solution (k) when adding boundary conditions through the skinner when all external surfaces are assigned reflective boundary conditions via 'reflective_bcs_surfaces' as compared to applying BCs on a CSG cell that contains the DAGMC geometry in /equivalent_bcs.
• 1.22.17The system shall give identical Monte Carlo solution (k) when adding boundary conditions through the skinner when all external surfaces are assigned vacuum boundary conditions via 'vacuum_bcs_surfaces', as compared to applying BCs on a CSG cell that containsthe DAGMC geometry in ./equivalent_bcs.
• 1.22.18The system shall give identical Monte Carlo solution (k) when adding boundary conditions through the skinner via 'reflective_bcs_surfaces' and 'vacuum_bcs_surfaces' as compared to applying BCs on a CSG cell that contains the DAGMC geometry in ./equivalent_bcs.
• 1.22.19The system shall give identical Monte Carlo solution (k) when adding boundary conditions through the skinner via 'reflective_bcs_surfaces' and 'vacuum_bcs_surfaces' using sideset id or name as compared to applying BCs on a CSG cell that contains the DAGMC geometry in ./equivalent_bcs.
• 1.22.20The system shall treat an internal skinned surface (the interface between the two mesh blocks) as a transmission surface by default, allowing particles to stream from the lower block through the upper block and leak out the vacuum top surface.
• 1.22.21The system shall apply reflective boundary conditions to an internal skinned surface. Relative to the internal_transmission case, which differs only in the interface boundary condition
• 1.22.22The system shall use a hexmesh and treat an internal skinned surface (the interface between the two mesh blocks) as a transmission surface by default, allowing particles to stream from the lower block through the upper block and leak out the vacuum top surface.
• 1.22.23The system shall use a hexmesh and apply reflective boundary conditions to an internal skinned surface. Relative to the internal_transmission case, which differs only in the interface boundary condition
• 1.22.24The system shall error if 'material_names' and 'material_blocks' are not the same length
• 1.22.25The system shall error if a block listed in 'material_blocks' does not exist in the mesh
• 1.22.26The system shall error if the same subdomain is listed more than once in 'material_blocks'
• 1.22.27The system shall error if 'material_blocks' is specified without 'material_names'
• 1.22.28The system shall error if neither 'material_blocks' nor 'material_names' is provided when using the skinner independent of an OpenMCCellAverageProblem
• 1.22.29The system shall warn when a mesh subdomain has no material assignment and will default to void
• 1.22.30The system shall assign materials to MOOSE mesh blocks and generate a new DAGMC geometrywith the correct material group tags
• 1.22.31The system shall update material assignments with 'material_blocks' and 'material_names' (using names or IDs) and run OpenMC with the regenerated geometry
• 1.22.32The system shall partially update material assignments with 'material_blocks' and 'material_names' (using names or IDs) and assign void to missing block and run OpenMC with the regenerated geometry
• 1.22.33The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning as compared to both (i) a CSG-equivalent version of the geometry and (ii) the same input file run with the skinner disabled. The CSG file used for comparison is in the csg_step_1 directory.
• 1.22.34The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory.
• 1.22.35The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning with a single density bin when compared to a case without any density skinning at all.
• 1.22.36The system shall scale a mesh by multiplying by 100.
• 1.22.37The system shall give identical results when scaling the Mesh by an arbitrary multiplier. The gold file was compared against a case with no scaling (scaling = 1) to get identical results.
• 1.22.38The system shall warn the user when there is a mismatch between the mesh mirror and the initial OpenMC DAGMC geometry.
• 1.22.39
• 1.22.40The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning by density as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory.
• 1.22.41The system shall give identical Monte Carlo solution when skinning as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory. For this case, a bin is split across disjoint elements.
• 1.22.42The system shall error if attempting to apply density skinning without any fluid blocks ready to receive variable density.
• 1.22.43The system shall assign a material to the implicit complement region when skinning as compared to a CSG-equivalent version of the geometry, which is in /csg_equivalent directory. The result for k is within statistics of the CSG equivalent.
• 1.22.44The system shall assign a material to the implicit complement region when skinning when there is no graveyard as compared to a CSG-equivalent version of the geometry which is in /csg_equivalent directory. The implicit complement region in this model exists as the space between the mesh geometry and an enclosing CSG cell. Results agree within statistics to the CSG reference.
• 1.22.45The system shall error if there is an obvious mismatch between the Mesh and DAGMC model for the case where the number of DAGMC materials which map to each Mesh subdomain do not match.
• 1.22.46The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning as compared to both (i) a CSG-equivalent version of the geometry and (ii) the same input file run with the skinner disabled. The CSG file used for comparison is in the csg_step_1 directory.
• 1.22.47The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory.
• 1.22.48The system shall give identical Monte Carlo solution (direct mesh tallies and k) when skinning as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory.
• 1.22.49The system shall give identical Monte Carlo solution (file mesh tallies and k) when skinning as compared to a CSG-equivalent version of the geometry, which is in the csg_step_2 directory. For this case, a bin is split across disjoint elements.
• 1.22.50The system shall scale a mesh by multiplying by 100.
• 1.22.51The system shall give identical results when scaling the Mesh by an arbitrary multiplier. The gold file was compared against a case with no scaling (scaling = 1) to get identical results.
• 1.22.52The system shall allow for the use of relaxation with a MeshTally and a MoabSkinner.
• 1.22.53The system shall error if the skinner user object is not the correct type
• 1.22.54The system shall warn if the graveyard is missing for OpenMC skinned models
• 1.22.55The system shall error if applying a symmetry mapping to an OpenMC model which must already exactly match the mesh.
• 1.22.56The system shall error if loading properties from HDF5 for skinned problems
• 1.22.57The system shall error if the cell containing the DAGMC universe is not contained in the root universe. If so, we cannot guarantee that the DAGMC geometry is not replicated and the skinner may produce an incorrect skin.
• 1.22.58The system shall error if the DAGMC universe is used as a lattice element. If so, the DAGMC geometry may be replicated and so the skinner may produce an incorrect skin.
• 1.22.59The system shall error if the DAGMC universe is used as a lattice element. If so, the DAGMC geometry may be replicated and so the skinner may produce an incorrect skin.
• 1.22.60The system shall error if the user attempts to map both CSG and DAGMC geometry to the MOOSE mesh.
• 1.22.61The system shall error if the DAGMC universe is used by multiple cells. If so, the DAGMC geometry is replicated and so the skinner will produce an incorrect skin.
• 1.22.62The system shall error if there are more than one DAGMC universe. If so, the universe to skin cannot be automatically determined.
• 1.22.63The system shall allow for the use of CSG and DAGMC geometry when using the MoabSkinner.
• 1.22.64The system shall not artificially inflate an OpenMC cell's instance count when the MOAB skinner reloads DAGMC geometry multiple times for a CSG-wrapped DAGMC universe.
• 1.22.65The system shall allow a material to be specified both in a cell with density feedback and a cell without density feedback. The gold file for this test was generated with a duplicated material of the feedback cell fill in the respective non-feedback cell.
• 1.22.66The system shall allow arbitrary combination of density-only, temperature-only, both, or no coupling. The file was compared against a standalone OpenMC run and gave identical values for k.
• 1.22.67The system shall give a warning when T+rho feedback is specified, but not all specified elements mapped into OpenMC
• 1.22.68The system shall give a warning when T feedback is specified, but not all specified elements mapped into OpenMC
• 1.22.69The system shall give a warning when rho feedback is specified, but not all specified elements mapped into OpenMC
• 1.22.70The system shall allow density feedback in OpenMC models per cell without requiring unique cell materials. This model was compared against a model with unique materials per cell.
• 1.22.71The system shall allow coupling of an OpenMC model with a length scale of centimeters to an applications with a length scale of meters. This is verified by ensuring exact agreement between two versions of the same problem - one with a length scale of centimeters (openmc_master_cm.i), and the other with a length scale of meters (openmc_master.i).
• 1.22.72The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.
• 1.22.73The system shall allow OpenMC tallies to be extracted on cell blocks which do not correspond to any multiphysics feedback settings. The tallies were compared against separate standalone OpenMC runs to confirm that the presence/absence of feedback does not change their values.
• 1.22.74The system shall allow OpenMC tallies to be extracted on cell blocks which also have temperature feedback.The tallies were compared against separate standalone OpenMC runs.
• 1.22.75The system shall allow OpenMC tallies to be extracted on cell blocks which also have temperature/density feedback.The tallies were compared against separate standalone OpenMC runs.
• 1.22.76The system shall allow OpenMC to be run within Cardinal without any data transfers in or out of the code.
• 1.22.77The system shall allow OpenMC tallies to be extracted on cell blocks which also have temperature feedback.The tallies were compared against separate standalone OpenMC runs.
• 1.22.78The system shall allow OpenMC tallies to be extracted on cell blocks which also have temperature/density feedback.The tallies were compared against separate standalone OpenMC runs.
• 1.22.79The system shall allow density feedback to be applied to cells which contain lattices. This is tested by applying densities to top-level cells which contain lattices; a comparison is made to a standalone OpenMC model, showing perfect agreement.
• 1.22.80Temperatures, densities, and a heat source shall be coupled between OpenMC and MOOSE and a solid pincell model when the model is set up with distributed cells. The solution for temperature, density, and heat source show an exact agreement with a case built without distributed cells in ../single_level.
• 1.22.81Temperatures, densities, and a heat source shall be coupled between OpenMC and MOOSE and a solid pincell model when the model is set up with distributed cells, but with material feedback applied by material. The gold file is identical to a cell-based feedback because we still have one unique material per cell.
• 1.22.82The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.
• 1.22.83The system shall allow the user to specify a 'heating' score in the OpenMC tally.
• 1.22.84The system shall allow the user to specify a 'heating-local' score in the OpenMC tally.
• 1.22.85The system shall allow the user to specify a 'damage-energy' score in the OpenMC tally.
• 1.22.86The system shall allow the user to specify a 'fission-q-prompt' score in the OpenMC tally.
• 1.22.87The system shall allow the user to specify a 'fission-q-recoverable' score in the OpenMC tally.
• 1.22.88The system shall error if the user adds a duplicate variable with a name Cardinal reserves for OpenMC coupling.
• 1.22.89The system shall allow reading density from user-defined names, with one density variable per cell. Reference values were obtained by running OpenMC standalone.
• 1.22.90The system shall allow reading density from user-defined names, with more than one density variable per cell
• 1.22.91The system shall allow lumping of subdomains together, equivalent to explicitly listing density correspondence to blocks
• 1.22.92The system shall error if the blocks and variables are not the same length
• 1.22.93The system shall error if a sub-vector is empty
• 1.22.94The system shall error if an entry in density_variables is not of unity length
• 1.22.95The system shall error if trying to collate multiple density variables onto the same block due to undefined behavior
• 1.22.96The system shall error if the blocks and variables are not the same length
• 1.22.97The system shall error if a sub-vector is empty
• 1.22.98The system shall error if an entry in temperature_variables is not of unity length
• 1.22.99The system shall error if trying to collate multiple temperature variables onto the same block due to undefined behavior
• 1.22.100The system shall allow reading temperature from user-defined names, with one temperature variable per cell
• 1.22.101The system shall allow reading temperature from user-defined names, with more than one temperature variable per cell
• 1.22.102The system shall allow lumping of subdomains together, equivalent to explicitly listing temperature correspondence to blocks
• 1.22.103The OpenMC wrapping shall support using the locally-lowest particle level in geometry regions where the cell_level does not exist. This input sets up a pincell with lattices where all cells of interest are on level 1. Surrounding this pincell is an exterior cell on level 0. Cell IDs, instances, and temperatures all correctly reflect using the lowest available level in the exterior region.
• 1.22.104Temperatures, densities, and a heat source shall be coupled between OpenMC and MOOSE and a solid pincell model.
• 1.22.105The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.
• 1.22.106The system shall exactly predict eigenvalue when sending temperatures which map 1:1 between subdomain and cell to OpenMC. We compare against a standalone OpenMC case to exactly match k.
• 1.22.107The system shall exactly predict eigenvalue when sending temperatures which map from one subdomain to multiple cells. We compare against a standalone OpenMC case to exactly match k.
• 1.22.108The system shall exactly predict eigenvalue when sending temperatures which map from multiple subdomains to one cell. We compare against a standalone OpenMC case to exactly match k.
• 1.22.109The system shall exactly predict eigenvalue when sending temperatures which map from multiple subdomains to one cell, when different temperature variables are used on each subdomain. This gold file exactly matches that used in the 'two_to_one' test.
• 1.22.110The system shall exactly predict eigenvalue when sending temperatures which map from multiple subdomains to one cell, when using the default name of 'temp' for the temperature field.
• 1.22.111The system shall allow any cell which maps to a particular subdomain to be set with an identical cell fill. Here, the gold files were created using an input which does not use this feature (which we also compare to a standalone OpenMC run).
• 1.22.112The system shall warn the user if the identical cell fill is unused because all mapped cells are simple, material-fills.
• 1.22.113The system shall error if trying to utilize identical cell fills but the filling cell IDs are not identical among the cells
• 1.22.114The system shall error if trying to utilize identical cell fills for a non-solid block
• 1.22.115The system shall error if inconsistent settings are applied for the identical cell mapping
• 1.22.116The system shall error if the single-increment applied to the tally cell contained material instances fails, such as when a TRISO universe is not being tallied.
• 1.22.117The system shall allow density feedback to be applied to cells which contain universes. This is tested by applying densities to top-level cells which contain universes; a comparison is made to a standalone OpenMC model, showing perfect agreement.
• 1.22.118The system shall correctly apply unique temperature feedback to an identical universe filled into multiple (non-lattice) cells. The reference solution from an identical OpenMC-only case is in the standalone directory.
• 1.22.119The system shall error if Cardinal tries to change the temperature/density of a given OpenMC cell more than once, since this indicates a problem with model setup.
• 1.22.120OpenMC postprocessors shall evaluate to -1 for unmapped MOOSE elements.
• 1.22.121The system shall return zero when reporting density of void regions and the material void index (-1) for material ID, when void is the only contained cell in the reporting element.
• 1.22.122The system shall return the density of the first non-void material cell if the containing cell contains both void and non-void material fills.
• 1.22.123The system shall error if trying to report a material ID for a cell which contains multiple material-filled cells.
• 1.22.124The system shall be capable of adding an AzimuthalAngleFilter to a CellTally with bins that are provided. This test also ensures the binned fluxes sum to the total flux through the use of global normalization.
• 1.22.125The system shall be capable of adding an AzimuthalAngleFilter to a CellTally with equally spaced bins. This test also ensures the binned fluxes sum to the total flux through the use of global normalization.
• 1.22.126The system shall be capable of adding an AzimuthalAngleFilter to a MeshTally.
• 1.22.127The system shall correctly compute azimuthal binned fluxes with mesh tallies such that the sum of the flux over each bin equals the total flux. The gold file was generated with an input file that scored the flux without a AzimuthalAngleFilter.
• 1.22.128The system shall error if 'azimuthal_angle_boundaries' doesn't contain enough boundaries to form bins.
• 1.22.129The system shall automatically sort bins to ensure they're monotonically increasing.
• 1.22.130The system shall error if neither 'num_equal_divisions' or 'azimuthal_angle_boundaries' are provided.
• 1.22.131The system shall error if both 'num_equal_divisions' and 'azimuthal_angle_boundaries' are provided.
• 1.22.132The system shall be capable of adding a DelayedGroupFilter to delayed neutron scores.
• 1.22.133The system shall error if the use attempts to add a DelayedGroupFilter to a tally with non-delayed scores.
• 1.22.134The system shall be capable of adding an EnergyFilter (with energy boundaries provided) to a CellTally. This test also ensures multi-group fluxes sum to the total flux for cell tallies.
• 1.22.135The system shall be capable of adding an EnergyFilter (with a group structure) to a CellTally. This test also ensures multi-group fluxes sum to the total flux for cell tallies.
• 1.22.136The system shall be capable of adding an EnergyFilter to a MeshTally.
• 1.22.137The system shall correctly compute multi-group fluxes with mesh tallies such that the sum of the flux over each group equals the total flux. The gold file was generated with an input file that scored the flux without an EnergyFilter.
• 1.22.138The system shall error if there aren't enough energy boundaries to form an EnergyTally.
• 1.22.139The system shall automatically sort bins to ensure they're monotonically increasing.
• 1.22.140The system shall error if no energy bins are provided.
• 1.22.141The system shall error if no energy bins are provided.
• 1.22.142The system shall error if duplicate energy boundaries are provided.
• 1.22.143The system shall error if negative energy boundaries are provided.
• 1.22.144The system shall be capable of adding an EnergyOutFilter (with energy boundaries provided).
• 1.22.145The system shall be capable of adding an EnergyOutFilter (with a group structure).
• 1.22.146The system shall error if the user attempts to use a non-analog estimator with an EnergyOutFilter.
• 1.22.147The system shall support Legendre filters in the scattering angle.
• 1.22.148The L0 Legendre moment in a L>0 Legendre expansion shall match the scattering reaction rate computed without a Legendre filter. This ensures that the L>0 Legendre moments are skipped during normalization.The gold file for this test was generated without a Legendre filter.
• 1.22.149The system shall error if the user attempts to use a non-analog estimator with an AngularLegendreFilter.
• 1.22.150The system shall be capable of adding a ParticleFilter for all particle types supported in OpenMC.
• 1.22.151The system shall be capable of adding an PolarAngleFilter to a CellTally with bins that are provided. This test also ensures the binned fluxes sum to the total flux through the use of global normalization.
• 1.22.152The system shall be capable of adding an PolarAngleFilter to a CellTally with equally spaced bins. This test also ensures the binned fluxes sum to the total flux through the use of global normalization.
• 1.22.153The system shall be capable of adding an PolarAngleFilter to a MeshTally.
• 1.22.154The system shall correctly compute polar binned fluxes with mesh tallies such that the sum of the flux over each bin equals the total flux. The gold file was generated with an input file that scored the flux without a PolarAngleFilter.
• 1.22.155The system shall error if 'polar_angle_boundaries' doesn't contain enough boundaries to form bins.
• 1.22.156The system shall automatically sort bins to ensure they're monotonically increasing.
• 1.22.157The system shall error if neither 'num_equal_divisions' or 'polar_angle_boundaries' are provided.
• 1.22.158The system shall error if both 'num_equal_divisions' and 'polar_angle_boundaries' are provided.
• 1.22.159The system shall support spherical harmonics filters.
• 1.22.160The system shall support spherical harmonics filters composed with other filters.
• 1.22.161The L0 spherical harmonics moment in a L>0 SH expansion shall match the scalar fluxes computed without a spherical harmonics filter. This ensures that the L>0 SH moments are skipped during normalization.The gold file for this test was generated without a SH filter.
• 1.22.162The system shall support multiple filters within a tally.
• 1.22.163The system shall support the automatic addition of the requested source rate normalization score to a single tally when using filters.
• 1.22.164The system shall error if a non-existent filter is requested by a tally.
• 1.22.165The system shall error if a filter is added when an OpenMCCellAverageProblem is not present.
• 1.22.166The system shall allow cell tallies to access filters added in the OpenMC tallies XML file.
• 1.22.167The system shall allow mesh tallies to access filters added in the OpenMC tallies XML file.
• 1.22.168The system shall error if a filter with the id requested has not been added by the tallie xml file.
• 1.22.169The system shall error if the user selects a spatial filter.
• 1.22.170The system shall warn the user if they have selected a functional expansion filter and set allow_expansion_filters = true.
• 1.22.171The system shall error if the user selected a functional expansion filter without setting allow_expansion_filters = true.
• 1.22.172The system shall correctly normalize tallies from a fixed source simulation when there is perfect mapping between the OpenMC model and the MOOSE mesh.
• 1.22.173The system shall notify the user that the settings related to normalizing by global or local tallies are inconsequential for fixed source mode.
• 1.22.174The system shall error if the total tally sum does not match the system-wide value for fixed source simulations.
• 1.22.175The system shall correctly normalize tallies from a fixed source simulation when there is only partial mapping between the OpenMC model and MOOSE domain.
• 1.22.176The system shall correctly normalize flux tallies for fixed source simulations.
• 1.22.177The system shall correctly normalize flux tallies for eigenvalue simulations.
• 1.22.178The system shall correctly normalize flux tallies for eigenvalue simulations when listed in an arbitrary order.
• 1.22.179The system shall correctly normalize flux tallies for eigenvalue simulations when listed in an arbitrary order and with user-defined names.
• 1.22.180The system shall correctly normalize flux tallies for eigenvalue simulations when the source rate normalization tally is not already added.
• 1.22.181The system shall error if the user tries to name only a partial set of the total tally scores.
• 1.22.182The system shall error if the user omits the required normalization tally for non-heating scores in eigenvalue mode
• 1.22.183The system shall ensure the provided tally values are constant monomials.
• 1.22.184The system shall ensure the provided initial tally values are constant monomials.
• 1.22.185The system shall ensure a tally variable is provided when using the AMR FoM.
• 1.22.186The system shall ensure an initial tally variable is provided when using the AMR FoM.
• 1.22.187The system shall ensure the provided stochastic relative errors are constant monomials.
• 1.22.188The system shall allow for the calculation of the variance reduction figure of merit.
• 1.22.189The system shall allow for the calculation of the AMR figure of merit.
• 1.22.190The system shall support the calculation of multi-group particle diffusion coefficients.
  1. The system shall calculate multi-group particle diffusion coefficients.
  2. The system shall prevent divide by zeros when calculating multi-group diffusion coefficients. This also checks for cases where the transport cross section is zero.
• 1.22.191The system shall support the calculation of multi-group transport corrected P0 scattering cross sections.
  1. The system shall calculate multi-group transport corrected P0 scattering cross sections.
  2. The system shall prevent divide by zeros when calculating transport corrected P0 scattering cross sections.
• 1.22.192The system shall support the calculation of multi-group cross sections using an arbitrary reaction rate and normalization factor.
  1. The system shall calculate multi-group cross sections using an arbitrary reaction rate and normalization factor.
  2. The system shall prevent divide by zeros when calculating cross sections.
• 1.22.193The system shall be capable of setting up MGXS generation for all relevant cross section types for photon.
• 1.22.194The system shall be capable of setting up MGXS generation for all relevant cross section types using mapped distributed cell tallies.
• 1.22.195The system shall be capable of generating L = 0 scattering cross sections without a transport correction.
• 1.22.196The system shall be capable of generating L > 0 scattering MGXS generation.
• 1.22.197The system shall be capable of generating certain multi-group cross sections with a collision estimator.
• 1.22.198The system shall be capable of generating certain multi-group cross sections with a tracklength estimator.
• 1.22.199The system shall be capable of setting up MGXS generation for all relevant cross section types using unstructured mesh tallies.
• 1.22.200The system shall be hide tally variables added for MGXS generation unless requested by the user.
• 1.22.201The system shall error if the user requests electron cross sections.
• 1.22.202The system shall error if the user requests positron cross sections.
• 1.22.203The system shall error if the user requests photon cross sections and includes fission.
• 1.22.204The system shall error if the user requests photon cross sections and includes fission.
• 1.22.205The system shall warn the user if they request transport corrected scattering cross sections with L > 0.
• 1.22.206The system shall warn the user if they select a mesh tally and request a tracklength estimator.
• 1.22.207The system shall warn the user if they wish to generate scattering / fission / diffusion group properties without an analog estimator.
• 1.22.208The heat source shall be correctly mapped if the solid cell level is not the highest level.
• 1.22.209The system shall be capable of block restricting CellTally variables.
• 1.22.210The heat source shall be extracted and normalized correctly from OpenMC for perfect model mapping with fissile fluid and solid phases.
• 1.22.211The power shall be provided by a postprocessor
• 1.22.212The system shall error if the user specifies an invalid number of particles.
• 1.22.213The system shall control the number of particles in OpenMC by a postprocessor
• 1.22.214The heat source shall be extracted and normalized correctly from OpenMC for perfect model mapping with fissile fluid and solid phases, but heat source coupling only performed for the solid phase.
• 1.22.215The system shall allow the user to specify a custom tally variable name. This test is identical to the mapping_solid test, but with a different name for the auxiliary variable.
• 1.22.216The heat source shall be extracted and normalized correctly from OpenMC for perfect model mapping with fissile fluid and solid phases, but heat source coupling only performed for the fluid phase.
• 1.22.217The heat source shall be extracted and normalized correctly from OpenMC for partial mapping of the OpenMC and MOOSE meshes, where all MOOSE elements map to OpenMC cells, but some OpenMC cells are not mapped.
• 1.22.218A warning shall be printed if any portion of the MOOSE solid blocks did not get mapped to OpenMC cells.
• 1.22.219The heat source shall be extracted and normalized correctly from OpenMC for partial mapping of the OpenMC and MOOSE meshes, where all OpenMC cells map to MOOSE elements, but some MOOSE elements are not mapped.
• 1.22.220For single-level geometries, tallies shall be added to all MOOSE blocks if tally blocks are not specified. The gold file for this test is simply a copy of mapping_all_out.e.
• 1.22.221The mapped cell volumes shall be correctly computed by the wrapping.
• 1.22.222The system shall be able to write multiple different tally scores with normalization by a global tally.
• 1.22.223The system shall be able to write multiple different tally scores with normalization by a local tally.
• 1.22.224The system shall be able to write multiple different tally scores with normalization by a local tally with the spatial separate assumption.
• 1.22.225The system shall be able to write multiple different tally scores with normalization by a global tally.
• 1.22.226The system shall be able to write multiple different tally scores with normalization by a global tally for mesh tallies.
• 1.22.227The system shall be able to write multiple different tally scores with normalization by a local tally for mesh tallies.
• 1.22.228The system shall allow for the calculation of the optical depth using the min/max vertex separation or the cube root of the element volume.
• 1.22.229The system shall allow for the calculation of the inverse optical depth using the min/max vertex separation or the cube root of the element volume.
• 1.22.230The system shall error if a non-reaction rate score is provided to ElementOpticalDepthIndicator.
• 1.22.231The system shall error if a a reaction rate score is requested, but not available in a tally.
• 1.22.232The system shall error if the flux is not available in a tally.
• 1.22.233The system shall allow for the computation of optical depth indicators when multiple tallies are added which accumulate the same scores.
• 1.22.234The system shall allow for the use of the statistical relative error of a tally score as an indicator.
• 1.22.235The system shall error if the provided score does not exist in StatRelErrorIndicator.
• 1.22.236The system shall error if no tallies are storing the relative error of the provided score.
• 1.22.237The system shall error if the provided tally external filter bin is greater than the total number of external filter bins.
• 1.22.238The system shall allow for the computation of relative error indicators when multiple tallies are added which accumulate the same scores.
• 1.22.239The system shall be able to compute IFP quantities on changing geometries.
• 1.22.240The system shall error if the problem attempts to enable IFP calculations when running in fixed source mode.
• 1.22.241The system shall be able to calculate neutron kinetics parameters.
• 1.22.242The system shall be able to calculate separate values of beta_eff for each delayed group in the ENDF delayed group structure.
• 1.22.243The system shall error if the problem does not enable IFP calculations and attempts to add an LambdaEffective post processor.
• 1.22.244The system shall error if the problem does not enable IFP calculations and attempts to add a BetaEffective post processor.
• 1.22.245The system shall error if the problem does not enable IFP calculations and attempts to add a BetaEffective post processor.
• 1.22.246The system shall allow the use of a look ahead marker to mitigate cyclic refinement.
• 1.22.247The system shall allow a mesh tally for coupling OpenMC, without any physics feedback.
• 1.22.248The heat source shall be tallied on an unstructured mesh and normalized against a local tally when a single mesh is used.
• 1.22.249This test is nearly identical to one_mesh. The difference lies in having no mesh_template in the input file. Without one, the system should be able to directly tally on a moose mesh instead of a file
• 1.22.250The system shall error if attempting to directly tally on a MOOSE mesh that is distributed, since all meshes are always replicated in OpenMC.
• 1.22.251The system shall allow users to use a mesh tally based on the mesh mirror with scaling. The gold file contains relative errors for an unscaled version of the test. The test itself scales the mesh down in the mesh block, and scales it back up with 'scaling'. If 'scaling' is not applied to the mesh mirror, the relative errors will change due to the difference in element volumes. The min/max values in the gold files are manually converted from W/cm^{3 (no scaling) to W/m}3 (scaled).
• 1.22.252The heat source shall be tallied on an unstructured mesh and normalized against a global tally when a single mesh is used. This test was run with successively finer meshes (from 256 elements to 94k elements) to show that the power of the mesh tally approaches the value of a cell tally as the difference in volume decreases.
• 1.22.253Mesh tallies shall allow for block restrictions to be applied.
• 1.22.254The heat source shall be tallied on an unstructured mesh and normalized against a local tally when multiple identical meshes are used.
• 1.22.255The heat source shall be tallied on an unstructured mesh and normalized against a global tally when multiple identical meshes are used. This test was run with successively finer meshes (from 256 elements to 94k elements) to show that the power of the mesh tally approaches the value of a cell tally as the difference in volume decreases.
• 1.22.256The heat source shall be correctly projected onto a Mesh in units of meters when the tally mesh template is in units of centimeters.
• 1.22.257The heat source shall be correctly projected onto a Mesh in units of meters when the tally mesh template and translations are in units of centimeters. The output was compared against the multiple_meshes case, which used an input entirely specified in terms of centimeters.
• 1.22.258The fission tally standard deviation shall be output correctly for unstructured mesh tallies.
• 1.22.259Mesh tallies shall temporarily require disabled renumbering until capability is available
• 1.22.260Mesh tallies shall error if the user attempts to apply a block restriction when using a mesh template.
• 1.22.261Mesh tallies shall error if the user attempts to apply a block restriction with no blocks.
• 1.22.262The system shall support nearest temperature interpolation when running in multi-group mode.
• 1.22.263The system shall support linear temperature interpolation when running in multi-group mode.
• 1.22.264The system shall solve the linear feedback Doppler slab problem with nearest temperature interpolation when running OpenMC's random ray solver.
• 1.22.265The system shall solve the linear feedback Doppler slab problem with linear temperature interpolation when running OpenMC's random ray solver.
• 1.22.266The system shall solve the inverse square root feedback Doppler slab problem, where cross section feedback is applied as density feedback instead of using MGXS temperature interpolation tables.
• 1.22.267The system shall be capable of solving the S2 thermal expansion benchmark problem with OpenMC's random ray solver.
• 1.22.268The system shall support void regions when running in multi-group mode.
• 1.22.269The system shall warn the user if there is an inconsistency between a moving mesh and the underlying OpenMC geometry.
• 1.22.270The system shall correctly reinitialize cell tallies when the mesh is moving. This is tested by translating the mesh over a stationary OpenMC model. The two cell tallies in the tallies.out file match the expected power density (accounting for the actual fractions of the cell which map to the moving mesh). This test also checks the cell IDs and instances as the mesh translates.
• 1.22.271The system shall correctly use a mesh tally on a moving MOOSE mesh. This is tested by translating the mesh over a stationary OpenMC model. The mesh translation exposes 20 percent of the left subdomain, which from a non-moving case we record 8 percent of the total power deposition in this region. For the moving mesh case, the total power deposited in the mesh tally is 92 percent.
• 1.22.272The system shall generate a file for mesh tallies.
• 1.22.273The system shall error if tallying on a file mesh for moving mesh cases, because there will be a disagreement between the mesh elements and the Mesh.
• 1.22.274The system shall correctly reinitialize temperature mapping and output of cell temperatures to a moving mesh. This is tested by applying temperatures based on the moving mesh.
• 1.22.275The system shall correctly reinitialize density mapping and output of cell densities and material fills to a moving mesh. This is tested by applying densities based on the moving mesh.
• 1.22.276The system shall correctly reinitialize volume calculations for a moving mesh. This is tested by comparing the OpenMC stochastic volume calculation against postprocessors for changing volumes.
• 1.22.277The system shall change the OpenMC mesh geometry on-the-fly. This is tested by running this case with a very high number of particles and batches, to compare against the CSG case in the reference folder. The reference case is a CSG model created at the deformed state. We cannot match these cases perfectly because we cannot control the seed of the second Picard iteration. The reference case gives k = 0.88782 plus or minus 5 pcm, and our Cardinal case gives 0.88786 plus of minus 5 pcm; these agree within 1 sigma.
• 1.22.278A statepoint file must be written when the batches parameter matches the batches in settings.xml and they are both specified.
• 1.22.279The number of particles shall optionally be set through the Cardinal input file. While the XML files set 100 particles, we change the number of particles to 200 in the Cardinal input file, and compare the eigenvalue against a standalone OpenMC run (with 'openmc –particles 200') to ensure correctness.
• 1.22.280The number of inactive batches shall optionally be set through the Cardinal input file. While the XML files set 10 inactive batches, we change the number of inactive batches to 20 in the Cardinal input file, and compare the eigenvalue against a standalone OpenMC run (with 20 inactive batches) to ensure correctness.
• 1.22.281The number of batches shall optionally be set through the Cardinal input file. While the XML files set 50 batches, we change the number of batches to 60 in the Cardinal input file, and compare the eigenvalue against a standalone OpenMC run (with 60 batches) to ensure correctness.
• 1.22.282The system shall allow skipping of statepoint output files
• 1.22.283The system shall allow resetting the OpenMC seed just before each execution. This is tested by confirming that tallies are identical in back-to-back OpenMC runs.
• 1.22.284The system shall allow for the output of the unrelaxed tally relative error for cell tallies.
• 1.22.285The system shall allow for the output of the unrelaxed tally relative error for mesh tallies.
• 1.22.286The system shall error if using incompatible tally estimator with a photon transport heating score.
• 1.22.287The system shall error if using a single tally with a photon transport heating score and nu-scatter score.
• 1.22.288The system shall support density feedback to OpenMC's random ray solver for the case when only density feedback blocks are provided. This test was verified with a standalone OpenMC simulation where distributed cell densities were set in the Python API. The k-eff and standard deviations matched exactly.
• 1.22.289The system shall support density feedback to OpenMC's random ray solver for the case when only density feedback blocks and variables are provided. This test was verified with a standalone OpenMC simulation where distributed cell densities were set in the Python API. The k-eff and standard deviations matched exactly.
• 1.22.290The system shall warn the user if a single MGXS reference density maps to multiple OpenMC materials.
• 1.22.291The system shall error if the user requests a combined estimator when running in random ray mode.
• 1.22.292The system shall error if the user provides more reference densities then density blocks/variables.
• 1.22.293The system shall error if the user requests the calculation of kinetics parameters when running in random ray mode.
• 1.22.294The system shall error if the user adds a MeshTally when running in random ray mode.
• 1.22.295The system shall error if the user requests flux volume normalization in their OpenMC model. This prevents a double-divide by volume, which Cardinal cannot recover due to the random ray volume estimations being cleared after tallies are extracted.
• 1.22.296The system shall error if the user provides a score to a tally that is not supported by OpenMC's random ray solver.
• 1.22.297The system shall error if the user requests a collision estimator for a tally.
• 1.22.298The system shall error if the user adds an AngularLegendreFilter when running the random ray solver.
• 1.22.299The system shall error if the user adds an AzimuthalAngleFilter when running the random ray solver.
• 1.22.300The system shall error if the user adds an DelayedGroupFilter when running the random ray solver.
• 1.22.301The system shall error if the user adds an EnergyOutFilter when running the random ray solver.
• 1.22.302The system shall error if the user adds an SphericalHarmonicsFilter when running the random ray solver.
• 1.22.303The system shall error if the user adds an PolarAngleFilter when running the random ray solver.
• 1.22.304The system shall error if the user adds an FromXMLFilter when running the random ray solver.
• 1.22.305The system shall error if the user adds an ParticleFilter when running the random ray solver.
• 1.22.306The system shall error if the user adds an OpenMCTallyEditor when running the random ray solver.
• 1.22.307The system shall error if the user adds an OpenMCNuclideDensities when running the random ray solver.
• 1.22.308The system shall error if the user adds an OpenMCDomainFilterEditor when running the random ray solver.
• 1.22.309The system shall error if the user adds a BoratedWater criticality search when running the random ray solver.
• 1.22.310The system shall properly normalize scores when running the random ray solver in fixed source mode. Tallies obtained from a standalone OpenMC random ray simulation were normalized manually and confirmed to match the Cardinal tallies on the MOOSE mesh.
• 1.22.311The system shall properly normalize scores when running the random ray solver in eigenvalue mode. Tallies obtained from a standalone OpenMC random ray simulation were normalized manually and confirmed to match the Cardinal tallies on the MOOSE mesh.
• 1.22.312The system shall allow the user to control the random ray inactive length.
• 1.22.313The system shall allow the user to control the random ray active length.
• 1.22.314The system shall allow for global tally normalization through the use of a universe filter.
• 1.22.315The system shall support temperature feedback to OpenMC's random ray solver with linear interpolation. A standalone calculation was performed where distributed cell temperatures were set with the OpenMC Python API. k-eff and its standard deviation were compared between the standalone calculation and the Cardinal result, and found to be in perfect agreement.
• 1.22.316The system shall support temperature feedback to OpenMC's random ray solver with nearest interpolation. A standalone calculation was performed where distributed cell temperatures were set with the OpenMC Python API. k-eff and its standard deviation were compared between the standalone calculation and the Cardinal result, and found to be in perfect agreement.
• 1.22.317A unity relaxation factor shall be equivalent to an unrelaxed case with globally-normalzed cell tallies on a model with perfect alignment between OpenMC model and the mesh mirror
• 1.22.318The wrapping shall apply constant relaxation for a case with globally-normalized cell tallies with perfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc.i run (without any command line parameter settings).
• 1.22.319The wrapping shall apply Robbins-Monro relaxation for a case with globally-normalized cell tallies with perfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc.i run (without any command line parameter settings).
• 1.22.320The wrapping shall apply Dufek-Gudowski relaxation for a case with globally-normalized cell tallies with perfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the same input file, but with the relaxation part commented out in the source code (so that we can compare directly against runs that only differ by changing the number of particles.
• 1.22.321A unity relaxation factor shall be equivalent to an unrelaxed case with locally-normalzed cell tallies on a model with perfect alignment between OpenMC model and the mesh mirror
• 1.22.322The wrapping shall apply constant relaxation for a case with locally-normalized cell tallies with perfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc.i case with normalize_by_global_tally=false.
• 1.22.323A unity relaxation factor shall be equivalent to an unrelaxed case with globally-normalzed cell tallies on a model with imperfect alignment between OpenMC model and the mesh mirror.
• 1.22.324The wrapping shall apply constant relaxation for a case with globally-normalized cell tallies with imperfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc_nonaligned.i case (without additional command line parameters)
• 1.22.325A unity relaxation factor shall be equivalent to an unrelaxed case with locally-normalzed cell tallies on a model with imperfect alignment between OpenMC model and the mesh mirror
• 1.22.326The wrapping shall apply constant relaxation for a case with locally-normalized cell tallies with imperfect alignment between the OpenMC model and the mesh mirror. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc_nonaligned.i case with normalize_by_global_tally=false
• 1.22.327The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.
• 1.22.328The wrapping shall allow output of the unrelaxed heat source for cell tallies
• 1.22.329The wrapping shall allow output of multiple tally scores, with relaxation applied independently to each score
• 1.22.330The system shall correctly error if trying to use relaxation with a time-varying mesh.
• 1.22.331A unity relaxation factor shall be equivalent to an unrelaxed case with globally-normalized mesh tallies.
• 1.22.332The wrapping shall apply constant relaxation for a case with globally-normalized mesh tallies. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc.i run (without any additional command line parameters).
• 1.22.333The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.
• 1.22.334A unity relaxation factor shall be equivalent to an unrelaxed case with locally-normalized mesh tallies.
• 1.22.335The wrapping shall apply constant relaxation for a case with locally-normalized mesh tallies. This test is verified by comparing the heat source computed via relaxation with the un-relaxed iterations from the openmc.i run with normalize_by_global_tally=false.
• 1.22.336The wrapping shall allow output of the unrelaxed heat source for mesh tallies
• 1.22.337A coupled OpenMC-MOOSE problem with zero power set in OpenMC should give exactly the same results as a standalone MOOSE heat conduction simulation of the same problem with zero heat source. The gold file was created with the zero_power.i input file, which does not have OpenMC as a sub-app.
• 1.22.338The system shall error if the heating tallies are missing power from other parts of the problem.
• 1.22.339The correct mesh shall be created for the sources test.
• 1.22.340The correct source files shall be created when re-using the source between iterations
• 1.22.341The system shall create the mesh mirror for later steps of these tests
• 1.22.342The system shall correctly reflect points about a partial symmetry sector
• 1.22.343The system shall create the mesh mirror for later steps of these tests
• 1.22.344The system shall correctly reflect points about a symmetry plane
• 1.22.345The system shall error if the symmetry mapper is not of the correct type
• 1.22.346The system shall create the mesh mirror for later steps of these tests
• 1.22.347The system shall correctly reflect points about a symmetry plane
• 1.22.348The system shall allow tallying of absorption/fission/scattering/total reaction rates in fixed source mode.
• 1.22.349The system shall allow tallying of nu-scatter, nu-fission, and inverse-velocity in fixed source mode.
  1. The system shall compute nu-scatter, nu-fission, and inverse-velocity scores in fixed source mode.
  2. The system shall error if the user attempts to specify a nu-scatter score without an analog estimator.
• 1.22.350The system shall allow tallying of prompt-nu-fission, delayed-nu-fission, and decay-rate in fixed source mode.
  1. The system shall compute prompt-nu-fission, delayed-nu-fission, and decay-rate scores in fixed source mode.
• 1.22.351The system shall allow tallying of tritium production rates in fixed source mode.
• 1.22.352The system shall allow for the approximation of tally gradients using finite differences.
• 1.22.353The system shall error if the variable provided to FDTallyGradAux is not of type CONSTANT MONOMIAL_VEC.
• 1.22.354The system shall error if a score is requested, but not available in a tally.
• 1.22.355The system shall error if the external filter bin provided by the user is out of bounds for the filters applied to the given score.
• 1.22.356The system shall allow for the computation of tally gradients with finite differences when multiple tallies are added which accumulate the same scores.
• 1.22.357The system shall correctly label elements in blocks which don't contain temperature feedback, density feedback, or a cell tally as unmapped.
• 1.22.358The system shall correctly normalize local tallies with different estimators using multiple global tallies.
• 1.22.359The system shall correctly apply and normalize two different CellTally objects with different scores. The gold file was generated using an input that had a single CellTally with multiple scores.
• 1.22.360The system shall correctly apply and normalize two different MeshTally objects with different scores. The gold file was generated using an input that had a single MeshTally with multiple scores.
• 1.22.361The system shall correctly apply and normalize two different CellTally objects with different scores and triggers. The gold file was generated using an input that had a single CellTally with multiple scores and triggers.
• 1.22.362The system shall correctly apply and normalize two different MeshTally objects with different scores and triggers. The gold file was generated using an input that had a single MeshTally with multiple scores and triggers.
• 1.22.363The system shall correctly apply and normalize two different CellTally objects with different scores when using relaxation. The gold file was generated using an input that had a single CellTally with multiple scores when using relaxation.
• 1.22.364The system shall correctly apply and normalize two different MeshTally objects with different scores when using relaxation. The gold file was generated using an input that had a single MeshTally with multiple scores when using relaxation.
• 1.22.365The system shall error if more than one tally is provided and the requested heating score is in none of the tallies.
• 1.22.366The system shall allow calculations with multiple different tallies.
• 1.22.367The system shall allow calculations with multiple different tally outputs.
• 1.22.368The system shall allow multiple tallies to use the same scores.
• 1.22.369The system shall error if two tallies score the normalization score and the user does not specify which to use for normalization.
• 1.22.370The system shall error if two tallies scoring the same score add the same variable names.
• 1.22.371The system shall error if attempting to use separate tallies when adding two tallies with the same score.
• 1.22.372The system shall ignore zero bins when executing tally triggers. This is done by measuring the maximum tally relative error of the H3 score. A smaller tally relative error indicates the simulation ran to max batches and didn't ignore the zero bin. If the zero bin is ignored, the simulation should only run 50 batches and the error will be above 4.2e-2. Otherwise, the extra batches will decrease the error to at least 4.1e-2 (running an additional extra batch), indicating the trigger fired on zero bins.
• 1.22.373The system shall enforce correct trigger ignore zero length
• 1.22.374The system shall ensure that the users provide values of trigger_ignore_zeros when the parameter is set.
• 1.22.375The system shall correctly terminate the OpenMC simulation once reaching a desired k standard deviation.
• 1.22.376The system shall terminate the OpenMC simulation once reaching a desired k standard deviation unless first reaching a maximum number of batches.
• 1.22.377The system shall terminate the OpenMC simulation once reaching a desired k variance.
• 1.22.378The system shall terminate the OpenMC simulation once reaching a desired k relative error.
• 1.22.379The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error with cell tallies.
• 1.22.380The system shall allow the user to customize the tally estimator for cell tallies
• 1.22.381The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error with mesh tallies.
• 1.22.382The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error when applying the same trigger to multiple scores.
• 1.22.383The system shall enforce correct trigger length
• 1.22.384The system shall enforce correct trigger threshold length
• 1.22.385The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error when applying a different trigger to multiple scores.
• 1.22.386The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error it unless first reaching a maximum number of batches when applying a different trigger to multiple scores.

• cardinal: Openmc Errors
• 1.23.1The system shall error if the user specifies a block for coupling that does not exist.
• 1.23.2The system shall error if an empty vector is provided for the blocks
• 1.23.3The system shall error if the MOOSE blocks and OpenMC cells don't overlap
• 1.23.4The system shall print a warning if some MOOSE elements are unmapped
• 1.23.5The system shall error if one OpenMC cell maps to more than one type of feedback
• 1.23.6The system shall error if one OpenMC cell maps to multiple subdomains that don't all have the same tally setting
• 1.23.7The system shall error if the user sets feedback blocks, but none of the elements map to OpenMC
• 1.23.8The system shall error if the user enforces equal mapped tally volumes but the mapped volumes are not identical across tally bins
• 1.23.9The system shall error if attempting to pass temperature feedback to a lattice outer universe due to lack of instance support in OpenMC
• 1.23.10The system shall error if attempting to change the material filling a cell with zero instances
• 1.23.11The system shall error if we attempt to set a density less than or equal to zero in OpenMC
• 1.23.12The system shall error if attempting to extract the eigenvalue from an OpenMC run that is not run with eigenvalue mode.
• 1.23.13The system shall error if attempting to extract the eigenvalue standard deviation from an OpenMC run that is not run with eigenvalue mode.
• 1.23.14The system shall error if attempting to set a k trigger for an OpenMC mode that doesn't have a notion of eigenvalues
• 1.23.15The system shall error if an OpenMC object is used without the correct OpenMC wrapped problem.
• 1.23.16The system shall error if an OpenMC model modifier object is used without the correct OpenMC wrapped problem.
• 1.23.17The system shall error if a auxkernel that queries OpenMC data structures is not used with the correct variable type.
• 1.23.18The system shall error if attempting to set a negative number of active batches
• 1.23.19The system shall error if attempting to set a negative number of active batches
• 1.23.20The system shall error if a properties file is loaded but does not exist
• 1.23.21The system shall error if using a skinner without a DagMC geometry
• 1.23.22The system shall error if both or none of the cell level options have been prescribed.
• 1.23.23The system shall error if the specified coordinate level for a phase is within the maximum coordinate levels across the OpenMC domain, but invalid for the particular region of the geometry.
• 1.23.24The system shall error if the specified coordinate level for finding a cell is greater than the maximum number of coordinate levels throughout the geometry.
• 1.23.25The system shall error if the mesh template is not provided in the same units as the Mesh.
• 1.23.26The system shall error if the mesh template does not exactly match the Mesh, such as when the order of mesh translations does not match the order of inputs in a CombinerGenerator.
• 1.23.27The system shall error if the mesh template does not exactly match the Mesh, such as when a totally different mesh is used (pincell versus pebbles).
• 1.23.28The system shall error if a tracklength estimator is attempted with unstructured mesh tallies, since this capability is not supported in libMesh.
• 1.23.29The system shall error if a particular set of coordinates in the mesh translations does not have all requisite x, y, and z components.
• 1.23.30The system shall error if attempting to run OpenMC in particle restart mode through Cardinal.
• 1.23.31The system shall error if attempting to run OpenMC in plotting mode through Cardinal.
• 1.23.32The system shall error if attempting to run OpenMC in volume mode through Cardinal.
• 1.23.33The system shall warn the user if they did not set the temperature range, protecting against seg faults within the tracking loop when trying to access nuclear data at temperatures that Cardinal wants to apply, but that weren't actually loaded at initialization.
• 1.23.34The system shall error if attempting to use separate tallies when a global tally exists
• 1.23.35The system shall error if name and score are not the same length.
• 1.23.36The system shall error if trigger and trigger_threshold are not simultaneously specified
• 1.23.37The system shall error if name has duplicate entries.
• 1.23.38The system shall error if score has duplicate entries.
• 1.23.39The system shall print a warning about zeroing-out the tally relative errors if no hits were made to the tally.
• 1.23.40The system shall error if we attempt to set a temperature in OpenMC below the lower bound of available data when using the interpolation method.
• 1.23.41The system shall error if we attempt to set a temperature in OpenMC above the upper bound of available data when using the interpolation method.
• 1.23.42The system shall allow a global tally to be zero.

• cardinal: Postprocessors
• 1.24.1The system shall output the number of coupled OpenMC cells
• 1.24.2The system shall correctly compute the Reynolds and Peclet numbers for a dimensional NekRS case.
• 1.24.3The system shall correctly output the number of NekRS MPI ranks
• 1.24.4The system shall correctly compute the Reynolds and Peclet numbers for a nondimensional NekRS case.
• 1.24.5The system shall allow zero scratch space allocation.
• 1.24.6The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.
• 1.24.7The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.
• 1.24.8The maximum and minimum tally relative errors shall be correctly retrieved from the OpenMC solution.
• 1.24.9The maximum and minimum tally relative errors shall be correctly retrieved from the OpenMC solution when using multiple scores.
• 1.24.10The system shall error if trying to extract score information that does not exist
• 1.24.11The system shall prove equivalence between a by-hand calculation of relative error (std_dev output divided by tally value) as compared to the tally relative error postprocessor.
• 1.24.12The system shall allow for the computation of tally relative errors when multiple tallies accumulating the same scores are added to the problem.
• 1.24.13The system shall error if two tallies accumulate the same scores and the user doesn't select one to use for computing a relative error metric.
• 1.24.14The system shall error if the user provides a non-existent tally.
• 1.24.15The system shall error if the user provides a tally that does not accumulate the score.
• 1.24.16NekHeatFluxIntegral shall correctly compute the heat flux integral on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same integrals 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. A fairly fine mesh is used in MOOSE to get closer to the higher-polynomial-order integration in nekRS.
• 1.24.17The 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
• 1.24.18The system shall error if non-temperature scalars are present, but temperature is requested through the variable interface.
• 1.24.19The system shall correctly query scalar point values when temperature scalars are not present. The gold file has the same data as the points.i test but with only the scalars included.
• 1.24.20The system shall allow pressure drag to be computed in the x, y, and z directions in dimensional form. This test compares drag as computed via Nek with by-hand calculations using combinations of native MOOSE postprocessors acting on the NekRS pressure mapped to the mesh mirror, for dimensional form
• 1.24.21The system shall allow pressure drag to be computed in the x, y, and z directions in non-dimensional form. This test compares drag as computed via Nek with by-hand calculations using combinations of native MOOSE postprocessors acting on the NekRS pressure mapped to the mesh mirror, for nondimensional form
• 1.24.22The system shall error if trying to compute pressure drag on non-fluid NekRS boundaries
• 1.24.23NekSideAverage 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.
• 1.24.24NekSideExtremeValue shall correctly compute max/min values on the nekRS mesh boundaries. The gold file was created by running the moose.i input, which computes the same max/min operations using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the pyramid.udf.
• 1.24.25System shall error if using an unsupported field with a side extrema postprocessor.
• 1.24.26NekSideIntegral shall correctly compute boundary areas and area-integrated temperatures on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same integrals 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.
• 1.24.27The system shall error if the requested usrwrk slot to integrate exceeds the number allocated
• 1.24.28The system shall allow total viscous drag to be computed in dimensional form. This test compares drag as computed via Nek with by-hand calculations using combinations of native MOOSE postprocessors using the analytic expression for velocity.
• 1.24.29The system shall error if trying to compute viscous drag on non-fluid NekRS boundaries
• 1.24.30dimensional form
• 1.24.31nondimensional form
• 1.24.32NekVolumeExtremeValue shall correctly compute max/min values on the nekRS volume mesh. The gold file was created by running the moose.i input, which computes the same max/min operations using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the pyramid.udf.
• 1.24.33System shall error if using an unsupported field with a volume extrema postprocessor.
• 1.24.34dimensional form
• 1.24.35nondimensional form
• 1.24.36The system shall correctly compute integral scalar values when temperature scalars are not present. The gold file has the same data as the nek.i test but with only the scalars included.
• 1.24.37NekMassFluxWeightedSideAverage shall correctly compute a mass flux weightedaverage of temperatures on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same integrals using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the brick.udf. Here, we don't technically make the gold file with a MOOSE run because MOOSE doesn't have a postprocessor that lets you divide two other postprocessors (such as mdot_side1 / weighted_T_side1 to get what NekMassFluxWeightedSideAverage is computing), but we do the division off-line to confirm that the results are correct.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.
• 1.24.38NekMassFluxWeightedSideIntegral shall correctly compute a mass flux weightedarea integral of temperatures on the nekRS mesh. The gold file was created by running the moose.i input, which computes the same integrals using existing MOOSE postprocessors on the same mesh on auxvariables that match the functional form of the solution fields initialized in the brick.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.
• 1.24.39System shall error if using an unsupported field with a mass flux weighted postprocessor.
• 1.24.40The system shall allow y plus to be computed. The resulting expression is checked against an analytic expression for the friction velocity and by inspection of the wall distance for the first GLL points near the wall.
• 1.24.41The system shall error if trying to compute y plus on non-fluid NekRS boundaries
• 1.24.42The system shall allow the number of particles run by OpenMC to be extracted as a postprocessor
• 1.24.43The system shall allow for the output of different timing statistics from OpenMC. Golding execution times is non-deterministic due to the difference in testing hardware and hardware utilization. This test is designed to avoid non-determinism when possible, and so raw timing statistics are not reported in the gold file.
• 1.24.44The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.

• cardinal: Sam Coupling
• 1.25.1Cardinal shall be able to run SAM as the master application without any data transfers. This test just ensures correct setup of SAM as a submodule with app registration.
• 1.25.2Cardinal shall be able to run SAM as a sub-application without any data transfers. This test just ensures correct setup of SAM as a submodule with app registration.

• cardinal: Sockeye Coupling
• 1.26.1Cardinal shall be able to run Sockeye as a master-application without any data transfers. This test just ensures correct setup of Sockeye as a submodule with app registration.
• 1.26.2Cardinal shall be able to run Sockeye as a sub-application without any data transfers. This test just ensures correct setup of Sockeye as a submodule with app registration.

• cardinal: Symmetry
• 1.27.1The OpenMC wrapping shall allow visualization of point reflection transformations
• 1.27.2The OpenMC wrapping shall allow visualization of rotation transformations

• cardinal: Transfers
• 1.28.1The system shall allow nearest point receiver transfers both to and from the multiapp.
• 1.28.2The system shall be able to read the flux from NekRS and write onto a boundary mesh mirror. This is tested by setting a known temperature distribution in NekRS such that the analytic heat flux can be computed and compared.
• 1.28.3The system shall error if trying to write heat flux on a boundary when the mesh mirror is a volume mesh.
• 1.28.4The system shall be able to transfer postprocessors to NekRS; we check this by passing postprocessors into the usrwrk array, and then using them as boundary conditions and looking at the field solution values on those boundaries.
• 1.28.5The NekScalarValue shall allow NekRS simulations to interface with MOOSE's Controls system
• 1.28.6The system shall be able to write multiple incoming volumetric source terms to NekRS. This is tested by writing two constant fields into the usrwrk array, and then integrating them over boundaries to ensure different fields are stored in each.
• 1.28.7The system shall be able to write multiple incoming boundary flux terms to NekRS. This is tested by writing two constant fields into the usrwrk array, and then integrating them over boundaries to ensure different fields are stored in each.
• 1.28.8The system shall be able to write into the scratch space a temperature which NekRS can use in its case files. This is tested by passing in a temperature field on a boundary and then applying that field as a Dirichlet condition.
• 1.28.9The system shall error if too many usrwrk slots are specified for a single field transfer
• 1.28.10The system shall be able to write multiple incoming field transfers to NekRS. This is tested by writing two constant fields into the usrwrk array, and then integrating them over boundaries to ensure different fields are stored in each.
• 1.28.11The system shall be able to write into the scratch space a temperature which NekRS can use in its case files. This is tested by passing in a temperature field in the volume and applying this field to the temperature instead of solving it.

• cardinal: Userobjects
• 1.29.1The system shall throw a warning if the extra element integer is not found in mesh.
• 1.29.2The system shall error if a non-replicated mesh is used while clustering.
• 1.29.3The system shall error if the 'metric_variable' is not constant monomial.
• 1.29.4The system shall error if 'lower_faction + upper_fraction' is more than 1.
• 1.29.5The system shall reproduce the clustering pattern by evaluating a boolean expression which combines multiple threshold-based heuristics and operates on element pairs.
• 1.29.6The system shall be able to cluster mesh elements by identifying elements with equal metric values within a specified tolerance using a value-difference heuristic.
• 1.29.7The system shall be able to cluster elements by identifying element pairs whose variable values both fall within either a specified upper or lower fraction of the extremes.
• 1.29.8The system shall be able to cluster elements by identifying element pairs whose metric values both fall within a range defined by a user-specified percentage above and below given reference values, with multiple ranges combined through a boolean expression.
• 1.29.9Spatially-binned volume integrals and averages shall be correctly dimensionalized for nondimensional cases. An equivalent setup with a dimensional problem is available at ../dimensional. The user object averages/integrals computed here exactly match.
• 1.29.10A hexagonal subchannel bin shall divide space according to subchannel discretization in the gaps of a hexagonal lattice.
• 1.29.11A hexagonal gap and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for side integrals and averages in directions normal to the gap planes.
• 1.29.12The correct unit normals shall be formed for a layered Cartesian gap bin.
• 1.29.13The system shall error if the userobjects aren't derived from the correct base class.
• 1.29.14A hexagonal gap and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for side integrals and averages.
• 1.29.15A layered gap and 2-D hexagonal subchannel bin shall be combined to give a multi-dimensional binning and demonstrate correct results for side integrals and averages.
• 1.29.16The system shall error if there are zero contributions to a gap bin.
• 1.29.17A hexagonal gap and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for side averages of velocity along a user-specified direction.
• 1.29.18A hexagonal subchannel bin shall divide space according to subchannel discretization in a hexagonal lattice.
• 1.29.19A hexagonal subchannel bin shall divide space according to a pin-centered subcannel discretization in a hexagonal lattice with two pin rings.
• 1.29.20A hexagonal subchannel bin shall divide space according to a pin-centered subcannel discretization in a hexagonal lattice with three pin rings.
• 1.29.21The system shall allow the Nek user objects to only evaluate on a fixed interval of time steps. The gold files were created by setting interval = 1 to ensure that the output files are exactly identical at the specified interval steps.
• 1.29.22The system shall allow the Nek to mesh-mirror interpolation to only occur on a fixed interval of time steps. The gold files were created by setting interval = 1 to ensure that the output files are exactly identical at the specified interval steps.
• 1.29.23A layered bin shall divide space according to 1-D layers in a given direction.
• 1.29.24A layered bin shall divide space according to 1-D layers in a given direction in a 3D mesh.
• 1.29.25A layered bin shall divide space according to 1-D layers in a given direction when the mesh contains a series of 2D planes.
• 1.29.26Multiple 1-D layered bins shall be combined to give a multi-dimensional binning and demonstrate correct results for volume integrals and averages.
• 1.29.27System shall error if user attemps to combine multiple bins that specify the same coordinate direction.
• 1.29.28The output points shall be automatically output for a 1-D Cartesian volume distribution and a 1-D Cartesian surface distribution.
• 1.29.29The output points shall be automatically output for a 3-D Cartesian distribution.
• 1.29.30System shall error if no points map to a spatial bin
• 1.29.31The system shall error if the maximum temperature is lower than the minimum temperature for the skinner bins
• 1.29.32The system shall error if the maximum density is lower than the minimum density for the skinner bins
• 1.29.33The system shall error if the temperature is below the minimum bin bound
• 1.29.34The system shall error if the temperature is above the maximum bin bound
• 1.29.35The system shall error if the density is below the minimum bin bound
• 1.29.36The system shall error if the density is above the maximum bin bound
• 1.29.37The system shall error if the outer graveyard surface is not larger than the inner graveyard surface
• 1.29.38The system shall error if the specified temperature auxiliary variable cannot be found
• 1.29.39The system shall error if the specified density auxiliary variable cannot be found
• 1.29.40The system shall error if the specified density and temperature auxiliary variables are the same
• 1.29.41The system shall error if trying to run in distributed mesh mode
• 1.29.42The system shall error if the material_names provided to the skinner do not match the required length
• 1.29.43The system shall bin elements according to temperature and density on an expanding mesh and be able to visualize the bins on the mesh volume.
• 1.29.44The system shall be able to convert a .h5m file to gmsh
• 1.29.45The system shall be able to convert a .h5m file to gmsh
• 1.29.46The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions
• 1.29.47The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions after expansion with the correct displacements.
• 1.29.48
• 1.29.49The system shall be able to convert a .h5m file to gmsh
• 1.29.50The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions, with a graveyard region outside the original mesh.
• 1.29.51The system shall bin hex mesh elements according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume.
• 1.29.52The system shall bin hex mesh elements according to temperature, on multiple subdomains, and be able to visualize the bins.
• 1.29.53The system shall be able to convert a .h5m file to gmsh
• 1.29.54The system shall be able to convert a .h5m file to gmsh
• 1.29.55The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions from a hex mesh
• 1.29.56The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions. The bins shall be re-generated on each time step from a hex mesh.
• 1.29.57The system shall bin mixed HEX8 and PRISM6 mesh elements from the loaded mesh according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume.
• 1.29.58The system shall bin mixed HEX27 and PRISM18 mesh elements from the loaded mesh according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume.
• 1.29.59The system shall output the MOAB mesh copied from libMesh into the .h5m format
• 1.29.60The system shall be able to convert a .h5m file to gmsh
• 1.29.61The system shall properly convert from libMesh to MOAB meshes in-memory. We check this in a somewhat circuitous manner by writing the volume mesh, then converting it to gmsh, and finally re-reading it into MOOSE so that we can use the Exodiff utility.
• 1.29.62The system shall bin elements according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume for second-order tets.
• 1.29.63The system shall be able to convert a .h5m file to gmsh
• 1.29.64The system shall be able to convert a .h5m file to gmsh
• 1.29.65The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions for second-order tets
• 1.29.66The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions for second-order tets. The bins shall be re-generated on each time step.
• 1.29.67The system shall bin elements according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume.
• 1.29.68The system shall bin elements according to temperature, on multiple subdomains, and be able to visualize the bins.
• 1.29.69The system shall be able to convert a .h5m file to gmsh
• 1.29.70The system shall be able to convert a .h5m file to gmsh
• 1.29.71The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions
• 1.29.72The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions. The bins shall be re-generated on each time step.
• 1.29.73The system shall error if the requirements for a binning variable type are violated.
• 1.29.74The system shall correctly reinitialize OpenMC coupling when multiple geometry cells are translated.This is tested by translating the mesh while also translating OpenMC universe which contains the coupled cells.
• 1.29.75The system shall error if the same cell id is provided more than once.
• 1.29.76The system shall correctly reinitialize OpenMC coupling when the geometry is translated.This is tested by translating the mesh while also translating OpenMC universe which contains the coupled cells.
• 1.29.77The system shall correctly reinitialize OpenMC coupling when a scaled geometry is translated.This is tested by translating the scaled mesh while also translating OpenMC universe which contains the coupled cells.
• 1.29.78The system shall correctly reinitialize OpenMC coupling when the geometry is rotated.This is tested by rotating the mesh while also rotating OpenMC universe which contains the coupled cells.
• 1.29.79The system shall correctly reinitialize OpenMC coupling when the geometry is translated.This is tested by translating an OpenMC geometry on a stationary mesh and ensure elements are reset correctly.
• 1.29.80
• 1.29.81
• 1.29.82
• 1.29.83
• 1.29.84
• 1.29.85The system shall error if trying to change nuclide densities for a non-existing material ID.
• 1.29.86The system shall error if trying to add a nuclide not accessible in the cross section library.
• 1.29.87The system shall give identical results to a standalone OpenMC run if the nuclide compositions are modified, but are still set to their initial values.
• 1.29.88The system shall give identical results to a standalone OpenMC run if the nuclide densities are modified, but there are no nuclides added or removed.
• 1.29.89The system shall give identical results to a standalone OpenMC run if the nuclide densities and nuclides are modified, after which the total density is modified due to thermal effects.
• 1.29.90The system shall give identical results to a standalone OpenMC run if the nuclide densities and nuclides are modified.
• 1.29.91The system shall error if inconsistent lengths for names and densities are provided.
• 1.29.92The 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
• 1.29.93Ensure that nuclides specified by a tally editor UO are present in the tally output
• 1.29.94Ensure that the scattering score specified by a tally editor UO are present in the tally output
• 1.29.95Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output
• 1.29.96Ensure that a cell filter specified by a tally editor UO are present in the tally output
• 1.29.97Ensure that a material filter specified by a tally editor UO are present in the tally output
• 1.29.98Ensure that a universe filters specified by a tally editor UO are present in the tally output
• 1.29.99A radial bin shall divide space according to 1-D layers in the radial direction.
• 1.29.100The output points shall be automatically output for a single-axis radial distribution.
• 1.29.101The output points shall be automatically output for a single-axis radial distribution plus a 1-D distribution.
• 1.29.102The system shall generate a boundary mesh to receive a side userobject during a multiapp transfer.
• 1.29.103Spatially-binned side integrals and averages shall be correctly dimensionalized for nondimensional cases. An equivalent setup with a dimensional problem is available at ../dimensional. The user object averages/integrals computed here exactly match.
• 1.29.104The system shall error if an invalid boundary ID is specified
• 1.29.105The system shall correctly integrate over a sideset in the NekRS domain when mapping space by the quadrature point
• 1.29.106The system shall correctly integrate over a sideset in the NekRS domain when mapping space by the face centroid
• 1.29.107The system shall correctly average over a sideset in the NekRS domain
• 1.29.108The system shall error if the userobjects aren't derived from the correct base class or if they are not found in the problem.
• 1.29.109A subchannel and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for volume integrals and averages.
• 1.29.110System shall error if user attemps to combine multiple bins that specify the same coordinate direction.
• 1.29.111The output points shall be automatically output for a single-axis subchannel binning
• 1.29.112System shall error if a side user object is provided to a volume binning user object.
• 1.29.113System shall error if attempting to use a normal velocity component with a user object that does not have normals defined
• 1.29.114A subchannel and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for volume averages of velocity projected along a constant direction.
• 1.29.115A pin-centered subchannel bin shall give correct results for side averages of temperature.
• 1.29.116The system shall error if the rotation axis is not perpendicular to the symmetry normal
• 1.29.117The system shall error if the rotation angle does not describe a valid symmetry wedge
• 1.29.118Spatially-binned volume integrals and averages shall be correctly dimensionalized for nondimensional cases. An equivalent setup with a dimensional problem is available at ../dimensional. The user object averages/integrals computed here exactly match.
• 1.29.119The system shall warn the user if encountering volume calculations needing instance-level granularity, since this is not available yet in OpenMC itself.
• 1.29.120The system shall map from a stochastic volume calculation to MOOSE for repeated cell instances
• 1.29.121The system shall terminate the stochastic volume calculation using a relative error metric.
• 1.29.122The system shall error if an invalid bounding box is specified for volume calculations
• 1.29.123The system shall map stochastic volumes for each OpenMC cell which maps to MOOSE.
• 1.29.124The system shall map stochastic volumes for each OpenMC cell which maps to MOOSE when the Mesh is not in units of centimeters
• 1.29.125The system shall error if trying to view stochastic volumes without the stochastic volume calculation having been created.
• 1.29.126The system shall terminate the stochastic volume calculation using a relative error metric.
• 1.29.127The system shall correctly compute volumes in OpenMC when using a user-provided bounding box.

Usability Requirements

Performance Requirements

System Interfaces

System Operations

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:

Physical Characteristics

The Cardinal application is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the Cardinal application.

Environmental Conditions

Not Applicable

System Security

MOOSE-based applications such as Cardinal have no requirements or special needs related to system-security. The software is designed to run completely in user-space with no elevated privileges required nor recommended.

Information Management

Cardinal as well as the core MOOSE framework, OpenMC, NekRS, and DAGMC are publicly available on an appropriate repository hosting site. Day-to-day backups and security services will be provided by the hosting service. More information about backups of the public repository on INL-hosted services can be found on the following page: GitHub Backups

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. The Cardinal development team follows the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing the Cardinal source code. However, some other applications that use Cardinal may be export-controlled, in which case all export control restrictions must be adhered to when packaging and shipping media.