Cardinal Requirements Traceability Matrix

This template follows INL template TEM-214, "IT System Requirements Traceability Matrix."

Introduction

Minimum System Requirements

In general, the following is required for MOOSE-based development:

A POSIX compliant Unix-like operating system. This includes any modern Linux-based operating system (e.g., Ubuntu, Fedora, Rocky, etc.), or a Macintosh machine running either of the last two MacOS releases.

HardwareInformation
CPU Architecturex86_64, ARM (Apple Silicon)
Memory8 GB (16 GBs for debug compilation)
Disk Space30GB

LibrariesVersion / Information
GCC8.5.0 - 12.2.1
LLVM/Clang10.0.1 - 16.0.6
Intel (ICC/ICX)Not supported at this time
Python3.7 - 3.11
Python Packagespackaging pyaml jinja2

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 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.

Assumptions and Dependencies

The Cardinal application is developed using MOOSE and is based on various modules, as such the RTM for Cardinal is dependent upon the files listed at the beginning of this document.

Pre-test Instructions/Environment/Setup

Ideally all testing should be performed on a clean test machine following one of the supported configurations setup by the test system engineer. Testing may be performed on local workstations and cluster systems containing supported operating systems.

The repository should be clean prior to building and testing. When using "git" this can be done by doing a force clean in the main repository and each one of the submodules:

git clean -xfd
git submodule foreach 'git clean -xfd'

All tests must pass in accordance with the type of test being performed. This list can be found in the Software Test Plan.

Changelog Issue Revisions

Errors in changelog references can sometimes occur as a result of typos or conversion errors. If any need to be noted by the development team, they will be noted here.

Currently, no errors in issue references related to the changelog have been discovered.

System Requirements Traceability

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.

    Specification(s): grid

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.1.2The system shall compute a convective heat transfer coefficient using userobjects for the wall heat flux, wall temperature, and bulk temperature.

    Specification(s): h

    Design: HeatTransferCoefficientAux

    Issue(s): #1081

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.1.3System shall error if auxkernel is not paired with a compatible bin user object.

    Specification(s): invalid_uo

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.1.4System shall error if auxkernel is not paired with a velocity vector bin user object.

    Specification(s): invalid_field

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 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.

    Specification(s): bison_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 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.

    Specification(s): bison_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 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.

    Specification(s): volume_pp

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): sfr_pincell

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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. The usrwrk_output feature was also used to check the correctness of the flux map into NekRS.

    Specification(s): sfr_pincell_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): pebble

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.3.5A coupled MOOSE-nekRS pebble flow problem shall predict physically realistic conjugate heat transfer.

    Specification(s): pebble

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.3.6The system shall be able to output the pressure and velocity solution from NekRS when coupling to MOOSE.

    Specification(s): output_cht

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.3.7A coupled MOOSE-nekRS pincell-fluid flow problem shall predict correct conservation of energy and realistic thermal solutions. Exact conservation of energy (based on the power imposed in the solid) will not be observed because some heat flux GLL points are also on Dirichlet boundaries, which win in boundary condition ties.

    Specification(s): sfr_pincell

    Design: NekRSProblem

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.3.8Individually conserving heat flux sideset by sideset shall give equivalent results to the all-combined option when there is just one coupling sideset. The gold file for this test is identical to that for the sfr_pincell case.

    Specification(s): sfr_pincell_vpp

    Design: NekRSProblem

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.3.9The system shall allow imposing heat flux through a dummy main application, instead of coupling NekRS via conjugate heat transfer. This is verified by computing the heat flux on the NekRS mesh, which adequately matches an initial value set in a postprocessor. This gold file is also identical to that obtained by running a dummy main app (solid_dummy) that passes in the desired flux_integral initial condition.

    Specification(s): impose_heat_flux

    Design: NekRSProblem

    Issue(s): #797

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: 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% degrees, and the agreement can be made better by using finer meshes in the coupled Cardinal case.

    Specification(s): pyramid

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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.

    Specification(s): pyramid_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): duplicate_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 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.

    Specification(s): slab_conduction

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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).

    Specification(s): pyramid_conduction

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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 10x10x10 nekRS mesh.

    Specification(s): slab_heat_source

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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.

    Specification(s): cylinder_conduction

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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.

    Specification(s): cylinder_conduction_subcycle

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): cylinder_conduction_reversed

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): cylinder_conduction_mini

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): cylinder_conduction_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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%.

    Specification(s): cylinder_heat_source

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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.

    Specification(s): cylinder_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.4.121.4.14

  • 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.

    Specification(s): cylinder_heat_source

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.4.15The NekRS wrapping shall allow a zero total flux to be sent from MOOSE to NekRS when all sidesets are conserved together.

    Specification(s): zero_flux_total

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.4.16The NekRS wrapping shall allow a zero total flux to be sent from MOOSE to NekRS when sidesets are individually conserved.

    Specification(s): zero_flux_total_vpp

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.4.17The NekRS wrapping shall allow unique sideset fluxes provided that the sidesets do not share any nodes in the NekRS mesh.

    Specification(s): vpp_disjoint

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.4.18The 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.

    Specification(s): vpp_disjoint_zero

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.4.19The system shall print a helpful error message if the sideset flux reporter does not have the correct length.

    Specification(s): mismatch_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.4.20The system shall error if conserving flux on each unique sideset, but with nodes shared across multiple sidesets.

    Specification(s): nodes_on_shared

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • cardinal: Controls
  • 1.5.1The system shall error if the controls is not used with the proper user object

    Specification(s): wrong_uo

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.5.2The system shall change OpenMC material compositions via a controls

    Specification(s): mat

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Deformation
  • 1.6.1A boundary displacement in the main app will displace the mesh in NekRS when using a boundary mesh mirror. The deformation is verified by looking at the change in area on the (i) main app, (ii) mesh mirror, and (iii) internal NekRS meshes, which agree very well. Improved agreement is obtained by decreasing the time step of the data transfers, due to the first-order finite difference approximation made for velocity.

    Specification(s): boundary

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.6.2A boundary displacement in the main app will displace the mesh in NekRS when using a volume mesh mirror. We use the same gold file as for the boundary test, proving equivalence.

    Specification(s): volume

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.6.3The system shall be able to run the mv_cyl NekRS example with a thin wrapper when using a volume mesh mirror. We show that the volume and area on the NekRS side is changing, whereas the volume/area in MOOSE will not change because we currently do not send displacements from NekRS to MOOSE.

    Specification(s): volume

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.6.4The system shall be able to run the mv_cyl NekRS example with a thin wrapper when using a boundary mesh mirror. We show that the volume and area on the NekRS side is changing, whereas the volume/area in MOOSE will not change because we currently do not send displacements from NekRS to MOOSE.

    Specification(s): boundary

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.6.5This test solves the steady state heat conduction equation with a source term of 3*sin(x)sin(y)sin(z) and a conductivityof 1. The temperature obtained should be sin(x)sin(y)sin(z).The domain is a cube that is deforming at eachtime step in the to the arbitrary functions t*x*z*(2-z)0.1 for x-coordinates,tx*z*(2-z)0.05 in y coordinates, and t(y+1)(y-1)0.1 in z coordinates.The gold solution was verified by comparing itto the analytic solution and a solution obtained by MOOSE's heat conduction solve.

    Specification(s): deformed_conduction

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.6.6An arbitrary mesh displacement in the main app will displace the meshin the sub-app equivalently at each time-step. This shall be verified bycomparing the areas of each sideset in both the main and the sub-app.The domain is a cube, with the initial area of each of thesidesets being 4.0. The areas across the main and sub-app should matchexactly, provided we are using Gauss Lobatto quadrature for MOOSE's areapost-processors, in order to match NekRS's GLL quadrature.

    Specification(s): deformed_areas

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Fluid Prop Subs
  • 1.7.1Cardinal shall be able to use fluid properties from the sodium submodule (in a master app).

    Specification(s): sodium

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.7.2Cardinal shall be able to use fluid properties from the potassium submodule (in a master app).

    Specification(s): potassium

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.7.3Cardinal shall be able to use fluid properties from the IAPWS95 submodule (in a master app).

    Specification(s): iapws95

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.7.4Cardinal shall be able to use fluid properties from the sodium submodule (in a sub app).

    Specification(s): sodium_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.7.5Cardinal shall be able to use fluid properties from the potassium submodule (in a sub app).

    Specification(s): potassium_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.7.6Cardinal shall be able to use fluid properties from the IAPWS95 submodule (in a sub app).

    Specification(s): iapws95_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

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

    Specification(s): griffin_main

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • cardinal: Ics
  • 1.9.1The volume postprocessor must have execute_on initial

    Specification(s): missing_initial

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.9.2The system shall error if invalid parameters are provided

    Specification(s): invalid_mdot_cp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.9.3The system shall be able to apply a normalized sinusoidal initial condition.

    Specification(s): sinusoidal

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.9.4The system shall error if the pairing heat source action is missing

    Specification(s): missing_paired_action

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.9.5The system shall be able to apply a normalized sinusoidal initial condition.

    Specification(s): sinusoidal

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • cardinal: Mesh
  • 1.11.1The system shall be able to construct a triangular lattice mesh for three pin rings of gaps.

    Specification(s): three_rings

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.2The system shall be able to construct a triangular lattice mesh for two pin rings of gaps.

    Specification(s): two_rings

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.3The system shall be able to construct a triangular lattice mesh for one pin ring of gaps.

    Specification(s): one_ring

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.4The system shall be able to construct a triangular lattice mesh for three pin rings.

    Specification(s): three_rings

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.5The system shall be able to construct a triangular lattice mesh for two pin rings.

    Specification(s): two_rings

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.6The system shall be able to construct a triangular lattice mesh for one pin ring.

    Specification(s): one_ring

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.7The system shall be able to construct a triangular lattice mesh for three pin rings as face meshes.

    Specification(s): three_rings_faces

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.8The system shall be able to construct a triangular lattice mesh for two pin rings as face meshes.

    Specification(s): two_rings_faces

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.11.9The system shall be able to construct a triangular lattice mesh for one pin ring as face meshes.

    Specification(s): one_ring_faces

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • cardinal: Meshgenerators
  • 1.12.1The system shall error if the boundary specified for corner fitting does not exist

    Specification(s): invalid_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.2The system shall error if an invalid polygon boundary is provided

    Specification(s): duplicate_boundary

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.3The system shall error if the radius of curvature is too big to fit inside the polygon

    Specification(s): too_big_radius

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.4The system shall curve corners of a six-sided polygon with zero boundary layers

    Specification(s): corners

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.5The system shall curve corners of a six-sided polygon with zero boundary layers with translation in space

    Specification(s): corners_translate

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.6The system shall error if applying a rotation angle to a polygon not centered on (0, 0)

    Specification(s): corners_translate_rotate

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.7The system shall curve corners of a six-sided polygon when the input mesh does not have one edge of the polygon horizontal.

    Specification(s): corners_rotation

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.8The system shall error if the length of smoothing adjustments does not equal the number of polygon layers

    Specification(s): invalid_number_of_smoothing

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.9The system shall error if the length of smoothing adjustments are not set to valid values

    Specification(s): zero_smoothing

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.10The system shall curve corners of a six-sided polygon with zero boundary layers and output QUAD8 elements

    Specification(s): corners_quad8

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.11The system shall error if an invalid element type is used with a quad9 to quad8 converter

    Specification(s): invalid_elem

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.12The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sideset.

    Specification(s): multiple_sides

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.13The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sidesets.

    Specification(s): repeated_sides

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.14The system shall error if the boundary specified for circular sideset fitting does not exist

    Specification(s): invalid_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.15The system shall correctly rebuild a QUAD9 mesh as QUAD8 with default behavior of rebuilding all boundaries, and without any circular movement.

    Specification(s): convert

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.16The system shall correctly rebuild a QUAD9 mesh as QUAD8 with no sidesets retained.

    Specification(s): convert_no_sidsets

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.17The system shall correctly rebuild a QUAD9 mesh as QUAD8 with custom behavior of rebuilding only some boundaries, and without any circular movement.

    Specification(s): convert_some_sidsets

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.18The system shall error if the boundary specified for rebuilding sidesets does not exist

    Specification(s): convert_some_sidsets_invalid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.19The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving the outer boundary to fit a circle.

    Specification(s): convert_outer

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.20The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving the inner boundary to fit a circle.

    Specification(s): convert_inner

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.21The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving multiple boundaries to fit a circle.

    Specification(s): convert_multiple

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.22The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving multiple boundaries to fit a circle with origins not at (0, 0, 0).

    Specification(s): convert_multiple_origin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.23The 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)

    Specification(s): offcenter

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.24The 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.

    Specification(s): point_already_on_origin

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.25The system shall correctly rebuild a QUAD9 mesh as QUAD8 when moving one boundary to fit circles based on multiple origins, with boundary layers.

    Specification(s): multiple_origins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.26The system shall error if there is an obvious mismatch between the number of boundary layers and the mesh.

    Specification(s): layers_too_many

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.27The 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).

    Specification(s): rotation

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.28The system shall error if an invalid element type is used with a hex27 to hex20 converter

    Specification(s): invalid_elem

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.29The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sideset.

    Specification(s): multiple_sides

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.30The system shall error if attempting to move elements to a circular surface when those elements have more than one face on the circular sidesets.

    Specification(s): repeated_sides

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.31The system shall error if the boundary specified for circular sideset fitting does not exist

    Specification(s): invalid_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.32The system shall correctly rebuild a HEX27 mesh as HEX20 with default behavior of rebuilding all boundaries, and without any circular movement.

    Specification(s): convert

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.33The system shall correctly rebuild a HEX27 mesh as HEX20 with no sidesets retained.

    Specification(s): convert_no_sidsets

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.34The system shall correctly rebuild a HEX27 mesh as HEX20 with custom behavior of rebuilding only some boundaries, and without any circular movement.

    Specification(s): convert_some_sidsets

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.35The system shall error if the boundary specified for rebuilding sidesets does not exist

    Specification(s): convert_some_sidsets_invalid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.36The system shall correctly rebuild a HEX27 mesh as HEX20 when moving the outer boundary to fit a circle.

    Specification(s): convert_outer

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.37The system shall correctly rebuild a HEX27 mesh as HEX20 when moving the inner boundary to fit a circle.

    Specification(s): convert_inner

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.38The system shall correctly rebuild a HEX27 mesh as HEX20 when moving multiple boundaries to fit a circle.

    Specification(s): convert_multiple

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.39The system shall correctly rebuild a HEX27 mesh as HEX20 when moving multiple boundaries to fit a circle with origins not at (0, 0, 0).

    Specification(s): convert_multiple_origin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.40The 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)

    Specification(s): offcenter

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.41The system shall error if the invalid values are used for the radii.

    Specification(s): invalid_radius

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.42The system shall error if the radius and boundary are not the same length.

    Specification(s): mismatch_radius_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.43The system shall error if the origin and boundary are not the same length.

    Specification(s): mismatch_origin_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.44The system shall error if the origin and boundary are not the same length.

    Specification(s): mismatch_origin_file_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.45The system shall error if the origin entries are not the correct length.

    Specification(s): mismatch_origin_space

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.46The system shall error if the origin entries are not the correct length.

    Specification(s): mismatch_origin_empty

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.47The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit circles based on multiple origins.

    Specification(s): multiple_origins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.48The system shall error if the number of layers does not match the number of boundaries to move

    Specification(s): layers_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.49The system shall correctly rebuild a HEX27 mesh as HEX20 when moving sidesets with boundary layers to fit a cylinder surface.

    Specification(s): layers

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.50The system shall error if there is an obvious mismatch between the number of boundary layers and the mesh.

    Specification(s): layers_too_many

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.51The system shall correctly rebuild a HEX27 mesh as HEX20 when moving sidesets with multiple boundary layers to fit a cylinder surface.

    Specification(s): three_layers

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.52The system shall error if trying to set the origins in more than one manner

    Specification(s): too_many_origins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.53The system shall error if invalid points are provided for the origins

    Specification(s): invalid_origin_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.12.54The system shall correctly rebuild a HEX27 mesh as HEX20 when moving one boundary to fit circles based on multiple origins provided from a file.

    Specification(s): multiple_origins_files

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.55The 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).

    Specification(s): rotation

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.12.56The system shall generate a mesh for a sphere.

    Specification(s): sphere

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.12.57The system shall move the nodes on a sphere boundary to the curved surface

    Specification(s): convert

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.12.56

  • 1.12.58The system shall move the nodes on a sphere boundary to the curved surface when the sphere is offset from the origin

    Specification(s): shift_convert

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.12.56

  • cardinal: Multiple Nek Apps
  • 1.13.1Cardinal shall be able to run NekRS input files nested within subdirectories in the same fashion that a standalone NekRS case will

    Specification(s): sub

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.13.2The system shall error if an invalid directory path is provided for the case

    Specification(s): invalid_directory

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.13.3The system shall error if trying to write output files for a Nek input without sibling apps

    Specification(s): invalid_write_fld

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.13.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.

    Specification(s): two_channels

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.13.5The correct output files shall be written when writing separate output files for repeated Nek simulation instances.

    Specification(s): app_outputs

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • cardinal: Nek Errors
  • 1.14.1The system shall error if Cardinal has displacements associated with NekRSMesh, but there is no mesh solver.

    Specification(s): missing_mesh_solver

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.2The system shall error if Cardinal is using NekRSStandaloneProblem with NekRS's moving mesh problems.

    Specification(s): standalone

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.3The 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.

    Specification(s): missing_mv_boundary

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.4The system shall error if Cardinal is using the NekRS mesh blending solver without indicating the moving boundary of interest

    Specification(s): missing_boundary

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.5The system shall error if NekRSMesh is not paired with displacements for moving mesh problems.

    Specification(s): displacements

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.6The system shall error if Cardinal has solver=user in the par file's MESH block, but there is no volume mesh mirror.

    Specification(s): volume_for_user_solver

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.7The system shall error if the nekRS .par file has a moving mesh solverbut the problem type in Cardinal is NekRSSeprateDomainProblem.

    Specification(s): separate_domain

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.8The system shall not error if there is no scratch space conflict for standalone Nek cases.

    Specification(s): ok_standalone

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.14.9The system shall error if the user tries to allocate scratch from Cardinal for standalone NekRS cases, but the Nek case files are also separately trying to allocate scratch.

    Specification(s): error_standalone

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.10The system shall error if the user enters too small a scratch space allocation; NekRSProblem always requires at least 1 slot

    Specification(s): too_small_a

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.11The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_b

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.12The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_c

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.13The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_d

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.14The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_e

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.15The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_f

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.16The system shall error if the user enters too small a scratch space allocation

    Specification(s): too_small_g

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.17The system shall error if the user enters too small a scratch space allocation; an initial shift cannot exceed the number of allocated slots

    Specification(s): too_small_h

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.18The system shall error if the user enters too small a scratch space allocation, when using a front shift for the slots

    Specification(s): too_small_i

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.19MOOSE shall throw an error if an invalid boundary is specified for the construction of nekRS's mesh as a MooseMesh.

    Specification(s): invalid_boundary_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.20The system shall throw an error if trying to use temperature as a field for cases that do not have a temperature variable

    Specification(s): temperature

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.21The system shall throw an error if trying to use scalar01 as a field for problems that don't have a scalar01 variable.

    Specification(s): scalar01

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.22The system shall throw an error if trying to use scalar02 as a field for problems that don't have a scalar02 variable.

    Specification(s): scalar02

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.23The system shall throw an error if trying to use scalar03 as a field for problems that don't have a scalar03 variable.

    Specification(s): scalar03

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.24The system shall throw an error if trying to use usrwrk00 as a field for problems that don't have sufficient usrwrk slots.

    Specification(s): usrwrk00

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.25The system shall throw an error if trying to use usrwrk01 as a field for problems that don't have sufficient usrwrk slots.

    Specification(s): usrwrk01

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.26The system shall throw an error if trying to use usrwrk02 as a field for problems that don't have sufficient usrwrk slots.

    Specification(s): usrwrk02

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.27The system shall correctly allocate scratch by accessing only quantities on the flow mesh if there is no temperature variable

    Specification(s): allocate_scratch_no_T

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.14.28The system shall error if the user manually specifies a duplicate name for an output field.

    Specification(s): duplicate_auxvar

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.29The system shall error if the user manually specifies a duplicate name for an output field.

    Specification(s): duplicate_var

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.30The system shall error if NekRSProblem is not paired with the correct executioner.

    Specification(s): executioner

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.31The system shall error if the Dimensionalize action is not paired with the correct problem.

    Specification(s): dimensionalize

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.32The system shall error if NekRSProblem is not paired with the correct mesh type.

    Specification(s): mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.33The system shall error if a Nek object is not paired with the correct problem.

    Specification(s): problem_base

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.34The system shall error if a NekRSMesh is used without a corresponding Nek-wrappedproblem.

    Specification(s): problem_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.35The system shall error if NekRSProblem is not paired with the correct time stepper.

    Specification(s): timestepper

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.36MOOSE shall throw an error if there is no receiving heat flux boundary condition on the nekRS boundaries that are coupled to MOOSE.

    Specification(s): missing_flux_bc

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.37MOOSE shall throw an error if an invalid boundary is specified for the construction of nekRS's mesh as a MooseMesh.

    Specification(s): boundary_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.38MOOSE shall throw an error if 'boundary' is empty for separate domain coupling, because the correct internal arrays would not be initialized

    Specification(s): separate_boundary

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.39The system shall error if there is a mismatch between the scaling of the mesh and NekRS problem.

    Specification(s): scaling_mismatch

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.40When using the minimized transfers setting, the default value for the postprocessor in the master application must not be zero.

    Specification(s): invalid_transfer_pp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.41The system shall error if the same MPI communicator is used to set up more than one Nek case.

    Specification(s): too_few_mpi_ranks

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.42The system shall throw an error if there is no heat source kernel when using volume coupling

    Specification(s): no_occa_source_kernel

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.43MOOSE shall throw an error if there is no temperature passive scalar variable initialized in nekRS.

    Specification(s): no_temperature_variable

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.14.44MOOSE shall throw an error if the user attempts to allocate the scratch space arrays in NekRS, since they are automatically allocated by Cardinal.

    Specification(s): occupied_scratch_space

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • cardinal: Nek File Output
  • 1.15.1The correct output file writing sequence shall occur when relying on nrs->isOutputStep

    Specification(s): avg_plugin

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.15.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.

    Specification(s): nek_as_master_output

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.15.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.

    Specification(s): nek_as_master_even_output

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.15.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.

    Specification(s): nek_as_sub_output

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.15.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.

    Specification(s): nek_as_sub_even_output

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.15.6The system shall allow the user to write the user scratch space slots to field files.

    Specification(s): check_scratch

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • cardinal: Nek Mesh
  • 1.16.1The system shall be able to generate an exact first-order boundary mesh mirror.

    Specification(s): boundary_exact

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.2The system shall be able to generate an exact first-order volume mesh mirror.

    Specification(s): volume_exact

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.3The system shall error if trying to build an exact mesh mirror that is second order.

    Specification(s): second_exact

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.16.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.

    Specification(s): first_order_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.5NekRSMesh shall construct a first-order volume mesh. The ordering for the nodes shall be based on the libMesh ordering.

    Specification(s): first_order_volume_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.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.

    Specification(s): second_order_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.7NekRSMesh shall construct a second-order volume mesh. The ordering of the nodes for each element shall also be based on the libMesh ordering.

    Specification(s): second_order_volume_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.16.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.

    Specification(s): cube_sidesets

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.16.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.

    Specification(s): cube_sidesets_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.16.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.

    Specification(s): pyramid_sidesets

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.16.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.

    Specification(s): pyramid_sidesets_exact

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Nek Output
  • 1.17.1Nek-wrapped MOOSE cases shall be able to output the passive scalars from the Nek solution onto the mesh mirror.

    Specification(s): scalar_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.17.2The system shall error if trying to write a usrwrk slot greater than the total number of allocated slots

    Specification(s): too_high_slot

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.17.3The system shall error if there is a mismatch between parameter lengths for writing usrwrk field files

    Specification(s): mismatch_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • cardinal: Nek Separatedomain
  • 1.18.1The system shall throw an error if trying to assign inlet_boundary to multiple boundary IDs.

    Specification(s): invalid_inlet_boundary_multiple

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.18.2The system shall throw an error if trying to assign inlet_boundary to an ID not contained in NekRSMesh's boundary input.

    Specification(s): invalid_inlet_boundary_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.18.3The system shall throw an error if trying to assign inlet_boundary to an ID not contained in NekRS boundary IDs.

    Specification(s): invalid_inlet_boundary_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.18.4The system shall throw an error if trying to assign outlet_boundary to multiple boundary IDs.

    Specification(s): invalid_outlet_boundary_multiple

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.18.5The system shall throw an error if trying to assign outlet_boundary to an ID not contained in NekRS boundary IDs.

    Specification(s): invalid_outlet_boundary_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.18.6Cardinal shall be able to transfer inlet temperature and velocity to the inlet_boundary of NekRS. We check this by applying those boundary conditions in NekRS, and looking at postprocessors on those boundaries to match the values we sent in.

    Specification(s): inlet_t

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.18.7Cardinal shall be able to transfer inlet temperature and velocity to the inlet_boundary of NekRS. We check this by applying those boundary conditions in NekRS, and looking at postprocessors on those boundaries to match the values we sent in. Cardinal shall also be able to extract outlet temperature and velocity from outlet_boundary. We check this by fetching these values using postprocessors.

    Specification(s): inlet_outlet_t

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.18.8Cardinal shall be able to extract outlet temperature and velocity from outlet_boundary of NekRS. We check this by fetching those values using postprocessors.

    Specification(s): outlet_t

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Nek Standalone
  • 1.19.1The system shall support adaptive time stepping in NekRS when running as the main application.

    Specification(s): variable_dt

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.2The system shall support adaptive time stepping in NekRS when running as the main application and with a non-dimensional formulation.

    Specification(s): variable_dt_nondim

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): test

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 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.

    Specification(s): nek_example

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.5The system shall throw an error if trying to act on only the NekRS solid mesh for side postprocessors.

    Specification(s): invalid_mesh_solid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.19.6Cardinal shall be able to run the ethier NekRS example with a thin wrapper. We add postprocessors to let us compare min/max values printed to the screen by NekRS.

    Specification(s): test

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.7Postprocessing 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.

    Specification(s): postprocess_from_restart

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.8Cardinal shall be able to run the ktauChannel NekRS example with a thin wrapper when using a volume mesh mirror.

    Specification(s): volume

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.19.9Cardinal 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). This verifies correct extraction of the NekRS solution with the 'output' parameter feature.

    Specification(s): volume

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.10Cardinal 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). This verifies correct extraction of the NekRS solution with the 'output' parameter feature.

    Specification(s): boundary

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.11The system shall properly modify both the NekRS start time and the time recognized by the MOOSE wrapping.

    Specification(s): wrapper

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.19.12The 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.

    Specification(s): manual_start_time

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • cardinal: Nek Stochastic
  • 1.20.1The system shall precompile a NekRS case.

    Specification(s): precompile

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

  • 1.20.2The 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.

    Specification(s): device

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.1

  • 1.20.3The system shall error if trying to write stochastic input into a scratch space slot that has not been allocated

    Specification(s): exceed_available

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.20.4The system shall error if trying to write stochastic input into a scratch space slot that is needed for other physics coupling purposes.

    Specification(s): overlap_coupling

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.20.5The system shall error if the scratch space is not allocated via Cardinal for stochastic cases for standalone Nek runs. We only need to test this for the standalone case because the other two coupling classes (NekRSProblem, NekRSSeparateDomainProblem) automatically require scratch allocated from Cardinal.

    Specification(s): standalone_scratch

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.20.6The system shall error if there is a gap between the slots used for coupling (0 to n) and the slots needed for NekScalarValue, because this would mess up the host to device data transfer.

    Specification(s): lower_gap

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.20.7The system shall error if there is a gap between the slots used for NekScalarValues, because this would mess up the host to device data transfer.

    Specification(s): interior_gap

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

    Prerequisite(s): 1.20.6

  • 1.20.8The system shall clear the cache before attempting the test with another set of ranks.

    Specification(s): clear0

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

  • 1.20.9The 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.

    Specification(s): driver_multi_1

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.8

  • 1.20.10The system shall clear the cache before attempting the test with another set of ranks.

    Specification(s): clear1

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

  • 1.20.11The 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.

    Specification(s): driver_multi_2

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.10

  • 1.20.12The system shall clear the cache before attempting the test with another set of ranks.

    Specification(s): clear2

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.20.11

  • 1.20.13The 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.

    Specification(s): driver_multi_3

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.12

  • 1.20.14The system shall clear the cache before attempting the test with another set of ranks.

    Specification(s): clear3

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.20.13

  • 1.20.15The 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.

    Specification(s): initial_offset

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.20.16The 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 SCALAR02 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

    Specification(s): driver_transient

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.20.17The system shall 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

    Specification(s): driver_multi_fld

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.20.18The 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.

    Specification(s): read0

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.17

  • 1.20.19The 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.

    Specification(s): read1

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.17

  • 1.20.20The 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.

    Specification(s): read2

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.20.17

  • 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).

    Specification(s): exact_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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).

    Specification(s): exact_volume_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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).

    Specification(s): first_order_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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).

    Specification(s): first_order_volume_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.21.5The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh 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).

    Specification(s): second_order_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.21.6The nekRS temperature solution shall be accurately reconstructed on the nekRSMesh 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).

    Specification(s): second_order_volume_temperature

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • cardinal: Nek Warnings
  • 1.22.1MOOSE shall throw a warning if there is no temperature passive scalar solve in nekRS.

    Specification(s): no_temp_solve

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.22.2The system shall print a warning if both volume and boundary mesh mirror information is set on NekRSStandaloneProblem, since the combined specification of these quantities for NekRSMesh is exclusively used for CHT coupling + volume coupling.

    Specification(s): boundary_warning

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • cardinal: Neutronics
  • 1.23.1The system shall allow problems which contain adaptivity on the mesh mirror for cell tallies.

    Specification(s): adaptive_cell

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.2The system shall allow problems which contain adaptivity on the mesh mirror for mesh tallies.

    Specification(s): adaptive_mesh

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.3The system shall error if adaptivity is active and tallying on a mesh template instead of the mesh block.

    Specification(s): adaptive_mesh_template

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.4The system shall error if adaptivity is active and a relaxation scheme is requested.

    Specification(s): adaptive_relaxation

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.5The system shall skip running OpenMC when the mesh is unchanged by adaptivity.

    Specification(s): skip_openmc_unchanged

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.6The system shall run OpenMC on the first Picard iteration regardless of the mesh being previouslyunchanged by adaptivity. This test relies on noise in the solution; if OpenMC runs more than onceper Picard iteration the PRNG seed changes and so the tally results will be different.

    Specification(s): skip_openmc_unchanged_picard

    Design: MeshTally OpenMCCellAverageProblem

    Issue(s): #1054

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.7The 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.

    Specification(s): null_skin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.8The 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.

    Specification(s): skin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.9The 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.

    Specification(s): skin_null_density

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.10The system shall scale a mesh by multiplying by 100.

    Specification(s): scale_mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.11The 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.

    Specification(s): with_scaling

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.23.101.23.21

  • 1.23.12The system shall warn the user when there is a mismatch between the mesh mirror and the initial OpenMC DAGMC geometry.

    Specification(s): unmapped_cells

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.13The 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.

    Specification(s): skin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.14The 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.

    Specification(s): disjoint_bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.15The system shall error if attempting to apply density skinning without any fluid blocks ready to receive variable density.

    Specification(s): cannot_skin_solid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.16The 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.

    Specification(s): mismatch

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.17The 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.

    Specification(s): null_skin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.18The 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.

    Specification(s): skin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.19The 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.

    Specification(s): skin_direct

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.20The 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.

    Specification(s): disjoint_bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.21The system shall scale a mesh by multiplying by 100.

    Specification(s): scale_mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.22The 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.

    Specification(s): with_scaling

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.23.101.23.21

  • 1.23.23The system shall error if the skinner user object is not the correct type

    Specification(s): wrong_uo

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.24The system shall warn if the graveyard is missing for OpenMC skinned models

    Specification(s): missing_graveyard

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.25The system shall error if applying a symmetry mapping to an OpenMC model which must already exactly match the mesh.

    Specification(s): no_symmetry

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.26The system shall error if loading properties from HDF5 for skinned problems

    Specification(s): properties

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.27The 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.

    Specification(s): dag_cell_not_root

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.28The 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.

    Specification(s): dag_in_lattice

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.29The 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.

    Specification(s): dag_lattice_outer

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.30The system shall error if the user attempts to map both CSG and DAGMC geometry to the MOOSE mesh.

    Specification(s): csg_with_dag_feedback

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.31The 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.

    Specification(s): multi_dag_uni_cells

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.32The system shall error if there are more than one DAGMC universe. If so, the universe to skin cannot be automatically determined.

    Specification(s): multi_dag_uni

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.33The 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.

    Specification(s): openmc

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.34The system shall give a warning when T+rho feedback is specified, but not all specified elements mapped into OpenMC

    Specification(s): warn_T_rho

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.35The system shall give a warning when T feedback is specified, but not all specified elements mapped into OpenMC

    Specification(s): warn_T

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.36The system shall give a warning when rho feedback is specified, but not all specified elements mapped into OpenMC

    Specification(s): warn_rho

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.37The 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).

    Specification(s): different_units

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.38The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.

    Specification(s): different_units_null_fixed_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.39The 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.

    Specification(s): no_feedback_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.40The 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.

    Specification(s): T_feedback_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.41The 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.

    Specification(s): rho_feedback_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.42The system shall allow OpenMC to be run within Cardinal without any data transfers in or out of the code.

    Specification(s): no_data_flow

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.43The 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.

    Specification(s): T_feedback_no_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.44The 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.

    Specification(s): rho_feedback_no_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.45Temperatures, 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.

    Specification(s): pincell

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.46Temperatures, 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.

    Specification(s): pincell_null_mat

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.47The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.

    Specification(s): pincell_null_fixed_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.48The system shall allow the user to specify a 'heating' score in the OpenMC tally.

    Specification(s): heating

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.49The system shall allow the user to specify a 'heating-local' score in the OpenMC tally.

    Specification(s): heating_local

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.50The system shall allow the user to specify a 'damage-energy' score in the OpenMC tally.

    Specification(s): damage_energy

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.51The system shall allow the user to specify a 'fission-q-prompt' score in the OpenMC tally.

    Specification(s): fission_q_prompt

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.52The system shall allow the user to specify a 'fission-q-recoverable' score in the OpenMC tally.

    Specification(s): fission_q_recoverable

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.53The system shall error if the user adds a duplicate variable with a name Cardinal reserves for OpenMC coupling.

    Specification(s): duplicate_variable

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.54The system shall error if trying to set density in a cell filled by a universe or lattice.

    Specification(s): nonmaterial_fluid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.55The system shall allow density feedback in OpenMC models by material, as opposed to individual cell mappings. This model was compared against an OpenMC standalone case where the density of the water was manually set to the average value applied from MOOSE.

    Specification(s): pincell

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.56The system shall allow reading density from user-defined names, with one density variable per cell. Reference values were obtained by running OpenMC standalone.

    Specification(s): collate_density

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.57The system shall allow reading density from user-defined names, with more than one density variable per cell

    Specification(s): multi_vars

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.58The system shall allow lumping of subdomains together, equivalent to explicitly listing density correspondence to blocks

    Specification(s): multi_vars_alt

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.59The system shall error if the blocks and variables are not the same length

    Specification(s): wrong_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.60The system shall error if a sub-vector is empty

    Specification(s): empty

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.61The system shall error if an entry in density_variables is not of unity length

    Specification(s): multi_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.62The system shall error if trying to collate multiple density variables onto the same block due to undefined behavior

    Specification(s): block_already_used

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.63The system shall error if the blocks and variables are not the same length

    Specification(s): wrong_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.64The system shall error if a sub-vector is empty

    Specification(s): empty

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.65The system shall error if an entry in temperature_variables is not of unity length

    Specification(s): multi_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.66The system shall error if trying to collate multiple temperature variables onto the same block due to undefined behavior

    Specification(s): block_already_used

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.67The system shall allow reading temperature from user-defined names, with one temperature variable per cell

    Specification(s): collate_temps

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.68The system shall allow reading temperature from user-defined names, with more than one temperature variable per cell

    Specification(s): multi_vars

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.69The system shall allow lumping of subdomains together, equivalent to explicitly listing temperature correspondence to blocks

    Specification(s): multi_vars_alt

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.70The 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.

    Specification(s): multiple_layers

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.71Temperatures, densities, and a heat source shall be coupled between OpenMC and MOOSE and a solid pincell model.

    Specification(s): pincell

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.72The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.

    Specification(s): pincell_null_fixed_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.73The 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.

    Specification(s): one_to_one

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.74The 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.

    Specification(s): one_to_two

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.75The 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.

    Specification(s): two_to_one

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.76The 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.

    Specification(s): two_to_one_multi

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.77The 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.

    Specification(s): default

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.78The 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).

    Specification(s): identical

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.79The system shall warn the user if the identical cell fill is unused because all mapped cells are simple, material-fills.

    Specification(s): warn_unused

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.80The system shall error if trying to utilize identical cell fills but the filling cell IDs are not identical among the cells

    Specification(s): different_fill_universes

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.81The system shall error if trying to utilize identical cell fills for a non-solid block

    Specification(s): non_solid

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.82The system shall error if inconsistent settings are applied for the identical cell mapping

    Specification(s): inconsistent_map

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.83The 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.

    Specification(s): noncontinguous_triso_univs

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.84The 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.

    Specification(s): universe_in_flat_geom

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.85The system shall error if Cardinal tries to change the temperature of a given OpenMC cell more than once, since this indicates a problem with model setup.

    Specification(s): triso_lattice

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.86OpenMC postprocessors shall evaluate to -1 for unmapped MOOSE elements.

    Specification(s): unmapped

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.87The 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.

    Specification(s): azimuthal_cell_provided_bins

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.88The 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.

    Specification(s): azimuthal_cell_equally_spaced_bins

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.89The system shall be capable of adding an AzimuthalAngleFilter to a MeshTally.

    Specification(s): azimuthal_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.90The 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.

    Specification(s): bin_sum

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.91The system shall error if 'azimuthal_angle_boundaries' doesn't contain enough boundaries to form bins.

    Specification(s): not_enough_provided_bnds

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.92The system shall automatically sort bins to ensure they're monotonically increasing.

    Specification(s): bnds_wrong_order

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.93The system shall error if neither 'num_equal_divisions' or 'azimuthal_angle_boundaries' are provided.

    Specification(s): no_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.94The system shall error if both 'num_equal_divisions' and 'azimuthal_angle_boundaries' are provided.

    Specification(s): both_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.95The 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.

    Specification(s): energy_cell_bnds

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.96The 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.

    Specification(s): energy_cell_structure

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.97The system shall be capable of adding an EnergyFilter to a MeshTally.

    Specification(s): energy_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.98The 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.

    Specification(s): group_sum

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.99The system shall error if there aren't enough energy boundaries to form an EnergyTally.

    Specification(s): not_enough_bnds

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.100The system shall automatically sort bins to ensure they're monotonically increasing.

    Specification(s): bnds_wrong_order

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.101The system shall error if no energy bins are provided.

    Specification(s): missing_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.102The system shall error if no energy bins are provided.

    Specification(s): both_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.103The 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.

    Specification(s): polar_cell_provided_bins

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.104The 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.

    Specification(s): polar_cell_equally_spaced_bins

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.105The system shall be capable of adding an PolarAngleFilter to a MeshTally.

    Specification(s): polar_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.106The 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.

    Specification(s): bin_sum

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.107The system shall error if 'polar_angle_boundaries' doesn't contain enough boundaries to form bins.

    Specification(s): not_enough_provided_bnds

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.108The system shall automatically sort bins to ensure they're monotonically increasing.

    Specification(s): bnds_wrong_order

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.109The system shall error if neither 'num_equal_divisions' or 'polar_angle_boundaries' are provided.

    Specification(s): no_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.110The system shall error if both 'num_equal_divisions' and 'polar_angle_boundaries' are provided.

    Specification(s): both_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.111The system shall support multiple filters within a tally.

    Specification(s): multi_filter

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.112The system shall support the automatic addition of the requested source rate normalization score to a single tally when using filters.

    Specification(s): no_norm_score

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.113The system shall error if a non-existent filter is requested by a tally.

    Specification(s): missing_filter

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.114The system shall error if a filter is added when an OpenMCCellAverageProblem is not present.

    Specification(s): wrong_problem

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.115The system shall allow cell tallies to access filters added in the OpenMC tallies XML file.

    Specification(s): arbitrary_cell

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.116The system shall allow mesh tallies to access filters added in the OpenMC tallies XML file.

    Specification(s): arbitrary_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.117The system shall error if a filter with the id requested has not been added by the tallie xml file.

    Specification(s): missing_filter

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.118The system shall error if the user selects a spatial filter.

    Specification(s): spatial_filter_error

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.119The system shall warn the user if they have selected a functional expansion filter and set allow_expansion_filters = true.

    Specification(s): func_exp_warning

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.120The system shall error if the user selected a functional expansion filter without setting allow_expansion_filters = true.

    Specification(s): func_exp_error

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.121The system shall correctly normalize tallies from a fixed source simulation when there is perfect overlap between the OpenMC model and the MOOSE mesh.

    Specification(s): overlap_all

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.122The system shall notify the user that the settings related to normalizing by global or local tallies are inconsequential for fixed source mode.

    Specification(s): normalize_unused

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.123The system shall error if the total tally sum does not match the system-wide value for fixed source simulations.

    Specification(s): missing_power

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.124The system shall correctly normalize tallies from a fixed source simulation when there is only partial overlap between the OpenMC model and MOOSE domain.

    Specification(s): overlap_solid

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.125The system shall correctly normalize flux tallies for fixed source simulations.

    Specification(s): flux

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.126The system shall correctly normalize flux tallies for eigenvalue simulations.

    Specification(s): flux

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.127The system shall correctly normalize flux tallies for eigenvalue simulations when listed in an arbitrary order.

    Specification(s): flip_order

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.128The system shall correctly normalize flux tallies for eigenvalue simulations when listed in an arbitrary order and with user-defined names.

    Specification(s): flip_order_and_name

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.129The system shall correctly normalize flux tallies for eigenvalue simulations when the source rate normalization tally is not already added.

    Specification(s): not_already_added

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.130The system shall error if the user tries to name only a partial set of the total tally scores.

    Specification(s): missing_name

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.131The system shall error if the user omits the required normalization tally for non-heating scores in eigenvalue mode

    Specification(s): missing_norm

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.132The heat source shall be correctly mapped if the solid cell level is not the highest level.

    Specification(s): solid

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.133The heat source shall be extracted and normalized correctly from OpenMC for perfect model overlap with fissile fluid and solid phases.

    Specification(s): overlap_all

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.134The power shall be provided by a postprocessor

    Specification(s): from_postprocessor

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.135The heat source shall be extracted and normalized correctly from OpenMC for perfect model overlap with fissile fluid and solid phases, but heat source coupling only performed for the solid phase.

    Specification(s): overlap_solid

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.136The system shall allow the user to specify a custom tally variable name. This test is identical to the overlap_solid test, but with a different name for the auxiliary variable.

    Specification(s): custom_name

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.137The heat source shall be extracted and normalized correctly from OpenMC for perfect model overlap with fissile fluid and solid phases, but heat source coupling only performed for the fluid phase.

    Specification(s): overlap_fluid

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.138The heat source shall be extracted and normalized correctly from OpenMC for partial overlap of the OpenMC and MOOSE meshes, where all MOOSE elements map to OpenMC cells, but some OpenMC cells are not mapped.

    Specification(s): partial_overlap_openmc_union

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.139A warning shall be printed if any portion of the MOOSE solid blocks did not get mapped to OpenMC cells.

    Specification(s): partial_overlap_moose_union_msg

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.140The heat source shall be extracted and normalized correctly from OpenMC for partial overlap of the OpenMC and MOOSE meshes, where all OpenMC cells map to MOOSE elements, but some MOOSE elements are not mapped.

    Specification(s): partial_overlap_moose_union

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.141For 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 overlap_all_out.e.

    Specification(s): default_tally_blocks

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.142The mapped cell volumes shall be correctly computed by the wrapping.

    Specification(s): cell_volumes

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.143The system shall be able to write multiple different tally scores with normalization by a global tally.

    Specification(s): multi_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.144The system shall be able to write multiple different tally scores with normalization by a local tally.

    Specification(s): multi_tally_local

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.145The system shall be able to write multiple different tally scores with normalization by a local tally with the spatial separate assumption.

    Specification(s): multi_tally_local_assume_separate

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.146The system shall be able to write multiple different tally scores with normalization by a global tally.

    Specification(s): multi_tally_global

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.147The system shall be able to write multiple different tally scores with normalization by a global tally for mesh tallies.

    Specification(s): multi_tally_global_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.148The system shall be able to write multiple different tally scores with normalization by a local tally for mesh tallies.

    Specification(s): multi_tally_local_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.149The system shall allow for the calculation of the optical depth using the min/max vertex separation or the cube root of the element volume.

    Specification(s): all_h

    Design: ElementOpticalDepthIndicator

    Issue(s): #1028

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.150The system shall error if a non-reaction rate score is provided to ElementOpticalDepthIndicator.

    Specification(s): not_rxn_rate

    Design: ElementOpticalDepthIndicator

    Issue(s): #1028

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.151The system shall error if a a reaction rate score is requested, but not available in a tally.

    Specification(s): missing_score

    Design: ElementOpticalDepthIndicator

    Issue(s): #1028

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.152The system shall error if the flux is not available in a tally.

    Specification(s): missing_flux

    Design: ElementOpticalDepthIndicator

    Issue(s): #1028

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.153The system shall allow a mesh tally for coupling OpenMC, without any physics feedback.

    Specification(s): no_coupling

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.154The heat source shall be tallied on an unstructured mesh and normalized against a local tally when a single mesh is used.

    Specification(s): one_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.155This 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

    Specification(s): one_mesh_no_input_file

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.156The system shall error if attempting to directly tally on a MOOSE mesh that is distributed, since all meshes are always replicated in OpenMC.

    Specification(s): moose_mesh_tally_distributed

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.157The system shall error if attempting to directly tally on a MOOSE mesh that has a scaling not equal to 1.0.

    Specification(s): scaling

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.158The 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.

    Specification(s): one_mesh_global

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.159Mesh tallies shall allow for block restrictions to be applied.

    Specification(s): block_restrict

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.160The heat source shall be tallied on an unstructured mesh and normalized against a local tally when multiple identical meshes are used.

    Specification(s): multiple_meshes

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.161The 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.

    Specification(s): multiple_meshes_global

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.162The heat source shall be correctly projected onto a Mesh in units of meters when the tally mesh template is in units of centimeters.

    Specification(s): different_units

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.163The 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.

    Specification(s): different_units_and_translations

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.164The fission tally standard deviation shall be output correctly for unstructured mesh tallies.

    Specification(s): fission_tally_std_dev

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.165Mesh tallies shall temporarily require disabled renumbering until capability is available

    Specification(s): disable_renumbering

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.166Mesh tallies shall error if the user attempts to apply a block restriction when using a mesh template.

    Specification(s): file_mesh_block_restrict

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.167Mesh tallies shall error if the user attempts to apply a block restriction with no blocks.

    Specification(s): block_restrict_no_blocks

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.168The 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.

    Specification(s): particles

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.169The 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.

    Specification(s): inactive

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.170The 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.

    Specification(s): batches

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.171The system shall allow skipping of statepoint output files

    Specification(s): skip_statepoint

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.23.172The system shall allow for the output of the unrelaxed tally relative error for cell tallies.

    Specification(s): unrelaxed_tally_rel_error_cell

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.173The system shall allow for the output of the unrelaxed tally relative error for mesh tallies.

    Specification(s): unrelaxed_tally_rel_error_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.174The system shall error if using incompatible tally estimator with a photon transport heating score.

    Specification(s): photon_heating

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.175A 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

    Specification(s): global_with_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.176The 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).

    Specification(s): global_with_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.177The 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).

    Specification(s): global_with_alignment_rm_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.178The 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.

    Specification(s): global_with_alignment_dg_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.179A 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

    Specification(s): local_with_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.180The 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.

    Specification(s): local_with_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.181A 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.

    Specification(s): global_without_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.182The 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)

    Specification(s): global_without_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.183A 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

    Specification(s): local_without_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.184The 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

    Specification(s): local_without_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.185The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.

    Specification(s): none_fixed_mesh

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.186The wrapping shall allow output of the unrelaxed heat source for cell tallies

    Specification(s): output_fission_tally_cell

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.187The wrapping shall allow output of multiple tally scores, with relaxation applied independently to each score

    Specification(s): multi_tally

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.188The system shall correctly error if trying to use relaxation with a time-varying mesh.

    Specification(s): no_relax_with_fixed_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.189A unity relaxation factor shall be equivalent to an unrelaxed case with globally-normalized mesh tallies.

    Specification(s): global_without_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.190The 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).

    Specification(s): global_without_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.191The system shall correctly re-initialize the same mapping when the MooseMesh does not change during a simulation.

    Specification(s): none_fixed_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.192A unity relaxation factor shall be equivalent to an unrelaxed case with locally-normalized mesh tallies.

    Specification(s): local_without_alignment_unity_relax

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.193The 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.

    Specification(s): local_without_alignment_relax

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.194The wrapping shall allow output of the unrelaxed heat source for mesh tallies

    Specification(s): output_fission_tally_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.195A 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.

    Specification(s): zero_power

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.196The system shall error if the heating tallies are missing power from other parts of the problem.

    Specification(s): missing_pebble

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.197The correct mesh shall be created for the sources test.

    Specification(s): mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.198The correct source files shall be created when re-using the source between iterations

    Specification(s): sources

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

    Prerequisite(s): 1.23.197

  • 1.23.199The system shall create the mesh mirror for later steps of these tests

    Specification(s): generate_mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.200The system shall correctly reflect points about a partial symmetry sector

    Specification(s): symmetry_sector

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.23.1991.23.2011.23.204

  • 1.23.201The system shall create the mesh mirror for later steps of these tests

    Specification(s): generate_mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.202The system shall correctly reflect points about a symmetry plane

    Specification(s): symmetry_plane

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    Prerequisite(s): 1.23.1991.23.2011.23.204

  • 1.23.203The system shall error if the symmetry mapper is not of the correct type

    Specification(s): wrong_uo

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.204The system shall create the mesh mirror for later steps of these tests

    Specification(s): generate_mesh

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.23.205The system shall correctly reflect points about a symmetry plane

    Specification(s): symmetry_plane

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.23.1991.23.2011.23.204

  • 1.23.206The system shall allow tallying of absorption/fission/scattering/total reaction rates in fixed source mode.

    Specification(s): reaction_rates

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.207The system shall allow tallying of tritium production rates in fixed source mode.

    Specification(s): tritium

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.208The system shall allow for the approximation of tally gradients using finite differences.

    Specification(s): gradients

    Design: FDTallyGradAux

    Issue(s): #1031

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.209The system shall error if the variable provided to FDTallyGradAux is not of type CONSTANT MONOMIAL_VEC.

    Specification(s): not_const_mon

    Design: FDTallyGradAux

    Issue(s): #1031

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.210The system shall error if a score is requested, but not available in a tally.

    Specification(s): missing_score

    Design: FDTallyGradAux

    Issue(s): #1031

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.211The system shall error if the external filter bin provided by the user is out of bounds for the filters applied to the given score.

    Specification(s): invalid_bin_index

    Design: FDTallyGradAux

    Issue(s): #1031

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.212The system shall correctly label elements in blocks which don't contain temperature feedback, density feedback, or a cell tally as unmapped.

    Specification(s): cell_tally_unmapped

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.213The system shall correctly normalize local tallies with different estimators using multiple global tallies.

    Specification(s): multi_global_estimator

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.214The 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.

    Specification(s): multiple_tallies_cell

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.215The 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.

    Specification(s): multiple_tallies_mesh

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.216The 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.

    Specification(s): multiple_tallies_cell_triggers

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.217The 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.

    Specification(s): multiple_tallies_mesh_triggers

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.218The 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.

    Specification(s): multiple_tallies_cell_relax

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.219The 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.

    Specification(s): multiple_tallies_mesh_relax

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.220The system shall error if the user provides multiple tallies with overlapping scores.

    Specification(s): duplicate_scores

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.221The system shall error if more than one tally is provided and the requested heating score is in none of the tallies.

    Specification(s): multi_no_norm

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.222The system shall allow calculations with multiple different tallies.

    Specification(s): multiple_different_tallies

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.223The system shall allow calculations with multiple different tally outputs.

    Specification(s): multiple_different_outputs

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.23.224The 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.

    Specification(s): empty_bin

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.225The system shall enforce correct trigger ignore zero length

    Specification(s): length_igore_zero

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.226The system shall ensure that the users provide values of trigger_ignore_zeros when the parameter is set.

    Specification(s): set_trigger_ignore_zero

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.227The system shall correctly terminate the OpenMC simulation once reaching a desired k standard deviation.

    Specification(s): k_std_dev

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.228The system shall terminate the OpenMC simulation once reaching a desired k standard deviation unless first reaching a maximum number of batches.

    Specification(s): k_std_dev_cutoff

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.229The system shall terminate the OpenMC simulation once reaching a desired k variance.

    Specification(s): k_variance

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.230The system shall terminate the OpenMC simulation once reaching a desired k relative error.

    Specification(s): k_rel_err

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.231The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error with cell tallies.

    Specification(s): tally_rel_err

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.232The system shall allow the user to customize the tally estimator for cell tallies

    Specification(s): tally_rel_err_collision

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.233The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error with mesh tallies.

    Specification(s): mesh_tally_rel_err

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.234The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error when applying the same trigger to multiple scores.

    Specification(s): multi_rel_err

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.235The system shall enforce correct trigger length

    Specification(s): length_trigger

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.236The system shall enforce correct trigger threshold length

    Specification(s): length_threshold

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.23.237The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error when applying a different trigger to multiple scores.

    Specification(s): multi_diff_rel_err

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.23.238The system shall correctly terminate the OpenMC simulation once reaching a desired tally relative error when applying a different trigger to multiple scores.

    Specification(s): multi_diff_rel_err_b

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Openmc Errors
  • 1.24.1The system shall error if the user specifies a block for coupling that does not exist.

    Specification(s): nonexistent_block

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.2The system shall error if an empty vector is provided for the blocks

    Specification(s): empty_block

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.3The system shall error if the MOOSE blocks and OpenMC cells don't overlap

    Specification(s): no_overlap

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.4The system shall print a warning if some MOOSE elements are unmapped

    Specification(s): skipping_moose_feedback

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.5The system shall error if one OpenMC cell maps to more than one type of feedback

    Specification(s): multiple_phases

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.6The system shall error if one OpenMC cell maps to multiple subdomains that don't all have the same tally setting

    Specification(s): multiple_tally_settings

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.7The system shall error if the user sets feedback blocks, but none of the elements map to OpenMC

    Specification(s): absent_solid_block

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.8The system shall error if the user enforces equal mapped tally volumes but the mapped volumes are not identical across tally bins

    Specification(s): unequal_volumes

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.9The system shall error if we attempt to set a density in a material that is repeated throughout our list of fluid cells.

    Specification(s): insufficient_materials

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.10If the same material appears in more than one solid cell, there should be no error like there is for the fluid case, because we do not change the density of solid cells.

    Specification(s): no_error_for_solid

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.24.11The system shall error if attempting to pass temperature feedback to a lattice outer universe due to lack of instance support in OpenMC

    Specification(s): temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.12The system shall error if we attempt to set a density less than or equal to zero in OpenMC

    Specification(s): zero_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.13The system shall error if we attempt to set a density in a void OpenMC cell

    Specification(s): void_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.14The system shall error if attempting to extract the eigenvalue from an OpenMC run that is not run with eigenvalue mode.

    Specification(s): k

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.15The system shall error if attempting to extract the eigenvalue standard deviation from an OpenMC run that is not run with eigenvalue mode.

    Specification(s): k_std_dev

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.16The system shall error if attempting to set a k trigger for an OpenMC mode that doesn't have a notion of eigenvalues

    Specification(s): k_trigger

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.17The system shall error if an OpenMC object is used without the correct OpenMC wrapped problem.

    Specification(s): incorrect_problem

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.18The system shall error if a auxkernel that queries OpenMC data structures is not used with the correct variable type.

    Specification(s): incorrect_var_type

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.19The system shall error if attempting to set a negative number of active batches

    Specification(s): invalid_batches

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.20The system shall error if attempting to set a negative number of active batches

    Specification(s): invalid_max_batches

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.21The system shall error if a properties file is loaded but does not exist

    Specification(s): missing_properties

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.22The system shall error if using a skinner without a DagMC geometry

    Specification(s): no_dag

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.23The system shall error if both or none of the cell level options have been prescribed.

    Specification(s): duplicate_levels

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.24The 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.

    Specification(s): fluid_too_high

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.25The system shall error if the specified coordinate level for finding a cell is greater than the maximum number of coordinate levels throughout the geometry.

    Specification(s): level_too_high

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.26The system shall error if a fluid material exists in non-fluid parts of the domain, because density would inadvertently be changed in other parts of the OpenMC model.

    Specification(s): material_duplication

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.27The system shall error if the mesh template is not provided in the same units as the Mesh.

    Specification(s): incorrect_scaling

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.28The 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.

    Specification(s): incorrect_order

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.29The 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).

    Specification(s): incorrect_file

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.30The system shall error if a tracklength estimator is attempted with unstructured mesh tallies, since this capability is not supported in libMesh.

    Specification(s): invalid_estimator

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.31The system shall error if a particular set of coordinates in the mesh translations does not have all requisite x, y, and z components.

    Specification(s): invalid_row

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.32The system shall error if attempting to run OpenMC in particle restart mode through Cardinal.

    Specification(s): volume

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.33The system shall error if attempting to run OpenMC in plotting mode through Cardinal.

    Specification(s): plot

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.34The system shall error if attempting to run OpenMC in volume mode through Cardinal.

    Specification(s): volume

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.35The 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.

    Specification(s): no_range

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.36The system shall error if attempting to use separate tallies when a global tally exists

    Specification(s): separate_tallies

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.37The system shall error if name and score are not the same length.

    Specification(s): invalid_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.38The system shall error if trigger and trigger_threshold are not simultaneously specified

    Specification(s): missing_threshold

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.39The system shall error if name has duplicate entries.

    Specification(s): duplicate_name

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.40The system shall error if score has duplicate entries.

    Specification(s): duplicate_score

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.41The system shall error if we attempt to set a temperature in OpenMC below the lower bound of available data when using the interpolation method.

    Specification(s): interpolation_min

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.42The system shall error if we attempt to set a temperature in OpenMC above the upper bound of available data when using the interpolation method.

    Specification(s): interpolation_max

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.24.43The system shall allow a global tally to be zero.

    Specification(s): local_zero

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Postprocessors
  • 1.25.1The system shall output the number of coupled OpenMC cells

    Specification(s): cells

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.2The system shall correctly compute the Reynolds and Peclet numbers for a dimensional NekRS case.

    Specification(s): dimensional_Re_Pe

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.3The system shall correctly output the number of NekRS MPI ranks

    Specification(s): ranks

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.4The system shall correctly compute the Reynolds and Peclet numbers for a nondimensional NekRS case.

    Specification(s): nondimensional_Re_Pe

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.5The system shall allow zero scratch space allocation for NekRSStandaloneProblem.

    Specification(s): check_zero_scratch

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.25.6The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.

    Specification(s): k_eigenvalue

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.7The maximum and minimum tally relative errors shall be correctly retrieved from the OpenMC solution.

    Specification(s): fission_tally_relative_error

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.8The maximum and minimum tally relative errors shall be correctly retrieved from the OpenMC solution when using multiple scores.

    Specification(s): multi_score

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.9The system shall error if trying to extract score information that does not exist

    Specification(s): nonexistent_score

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.10The 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.

    Specification(s): manual_rel_err_calc

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.11NekHeatFluxIntegral 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.

    Specification(s): nek_heat_flux_integral

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.12The system shall interpolate the NekRS solution onto a given point. This is tested by analytically comparing known initial conditions from NekRS against function evaluations for
    1. dimensional form
    2. non-dimensional form
    3. non-dimensional scaling of usrwrk slots for which the units are known

    Specification(s): pp/points, pp/nondimensional, pp/usrwrk_units

    Design: NekPointValue

    Issue(s): #1015#1016#1079

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.13The system shall warn the user if dimensionalization is requested and cannot be performed, for
    1. usrwrk slot 0
    2. usrwrk slot 1
    3. usrwrk slot 2

    Specification(s): warn/u00, warn/u01, warn/u02

    Design: NekPointValue

    Issue(s): #1015#1016#1079

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.14The 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

    Specification(s): pressure

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.15The 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 nondimensional form

    Specification(s): pressure_nondim

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.16The system shall error if trying to compute pressure drag on non-fluid NekRS boundaries

    Specification(s): invalid_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

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

    Specification(s): nek_side_average

    Design: NekSideAverage

    Issue(s): #1015

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.18NekSideExtremeValue 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.

    Specification(s): nek_side_extrema

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.19System shall error if using an unsupported field with a side extrema postprocessor.

    Specification(s): invalid_field

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.20NekSideIntegral 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.

    Specification(s): nek_side_integral

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.21The system shall error if the requested usrwrk slot to integrate exceeds the number allocated

    Specification(s): invalid_slot

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.22The 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.

    Specification(s): drag

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.23The system shall error if trying to compute viscous drag on non-fluid NekRS boundaries

    Specification(s): invalid_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.24dimensional form

    Specification(s): nek

    Design: NekVolumeAverage

    Issue(s): #1065

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.25nondimensional form

    Specification(s): nondimensional

    Design: NekVolumeAverage

    Issue(s): #1065

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.26NekVolumeExtremeValue 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.

    Specification(s): nek_volume_extrema

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.27System shall error if using an unsupported field with a volume extrema postprocessor.

    Specification(s): invalid_field

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.28dimensional form

    Specification(s): nek

    Design: NekVolumeIntegral

    Issue(s): #1065

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.29nondimensional form

    Specification(s): nondimensional

    Design: NekVolumeIntegral

    Issue(s): #1065

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.30NekMassFluxWeightedSideAverage 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.

    Specification(s): nek_weighted_side_average

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.31NekMassFluxWeightedSideIntegral 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.

    Specification(s): nek_weighted_side_integral

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.32System shall error if using an unsupported field with a mass flux weighted postprocessor.

    Specification(s): invalid_field

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.25.33The system shall allow the number of particles run by OpenMC to be extracted as a postprocessor

    Specification(s): particles

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.25.34The k-eigenvalue and its standard deviation shall be correctly retrieved from the OpenMC solution.

    Specification(s): k_eigenvalue

    Design: Reactivity

    Issue(s): #1051

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • cardinal: Sam Coupling
  • 1.26.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.

    Specification(s): sam_master

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.26.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.

    Specification(s): sam_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • cardinal: Sockeye Coupling
  • 1.27.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.

    Specification(s): sockeye_master

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.27.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.

    Specification(s): sockeye_sub

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • cardinal: Symmetry
  • 1.28.1The OpenMC wrapping shall allow visualization of point reflection transformations

    Specification(s): reflection

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.28.2The OpenMC wrapping shall allow visualization of rotation transformations

    Specification(s): rotation

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • cardinal: Transfers
  • 1.29.1The system shall allow nearest point receiver transfers both to and from the multiapp.

    Specification(s): nearest_point_receiver

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • cardinal: Userobjects
  • 1.30.1Spatially-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.

    Specification(s): nondim

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.2A hexagonal subchannel bin shall divide space according to subchannel discretization in the gaps of a hexagonal lattice.

    Specification(s): bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.3A 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.

    Specification(s): normal_component

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.4The correct unit normals shall be formed for a layered Cartesian gap bin.

    Specification(s): normal_component_aux

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.5The system shall error if the userobjects aren't derived from the correct base class.

    Specification(s): type_error

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.6A 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.

    Specification(s): gap_layered

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.7A 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.

    Specification(s): gap_horizontal_layered

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.8The system shall error if there are zero contributions to a gap bin.

    Specification(s): bins_too_fine

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.9A 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.

    Specification(s): user_component

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.10A hexagonal subchannel bin shall divide space according to subchannel discretization in a hexagonal lattice.

    Specification(s): bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.11A hexagonal subchannel bin shall divide space according to a pin-centered subcannel discretization in a hexagonal lattice with two pin rings.

    Specification(s): pin_centered

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.12A hexagonal subchannel bin shall divide space according to a pin-centered subcannel discretization in a hexagonal lattice with three pin rings.

    Specification(s): pin_centered_3

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.13The 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.

    Specification(s): interval

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.14The 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.

    Specification(s): interval_synchronization

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.15A layered bin shall divide space according to 1-D layers in a given direction.

    Specification(s): bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.16A layered bin shall divide space according to 1-D layers in a given direction.

    Specification(s): bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.17A layered bin shall divide space according to 1-D layers in a given direction.

    Specification(s): axial_bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.18Multiple 1-D layered bins shall be combined to give a multi-dimensional binning and demonstrate correct results for volume integrals and averages.

    Specification(s): multiple_layers

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.19System shall error if user attemps to combine multiple bins that specify the same coordinate direction.

    Specification(s): conflicting_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.20The output points shall be automatically output for a 1-D Cartesian volume distribution and a 1-D Cartesian surface distribution.

    Specification(s): 1d_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.21The output points shall be automatically output for a 3-D Cartesian distribution.

    Specification(s): 3d_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.22System shall error if no points map to a spatial bin

    Specification(s): bins_too_fine

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.23The system shall error if the maximum temperature is lower than the minimum temperature for the skinner bins

    Specification(s): invalid_max_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.24The system shall error if the maximum density is lower than the minimum density for the skinner bins

    Specification(s): invalid_max_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.25The system shall error if the temperature is below the minimum bin bound

    Specification(s): too_low_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.26The system shall error if the temperature is above the maximum bin bound

    Specification(s): too_high_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.27The system shall error if the density is below the minimum bin bound

    Specification(s): too_low_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.28The system shall error if the density is above the maximum bin bound

    Specification(s): too_high_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.29The system shall error if the skinned mesh does not contain tetrahedral elements

    Specification(s): invalid_mesh

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.30The system shall error if the outer graveyard surface is not larger than the inner graveyard surface

    Specification(s): invalid_graveyard_scales

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.31The system shall error if the specified temperature auxiliary variable cannot be found

    Specification(s): no_aux_temp

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.32The system shall error if the specified density auxiliary variable cannot be found

    Specification(s): no_aux_density

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.33The system shall error if the specified density and temperature auxiliary variables are the same

    Specification(s): overlap_t_rho

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.34The system shall error if trying to run in distributed mesh mode

    Specification(s): distributed

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.35The system shall error if the material_names provided to the skinner do not match the required length

    Specification(s): incorrect_material_names

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.36The system shall bin elements according to temperature and density on an expanding mesh and be able to visualize the bins on the mesh volume.

    Specification(s): bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.37The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step0

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.38The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step1

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.39The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions

    Specification(s): check_skins_step0

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.371.30.481.30.54

  • 1.30.40The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions after expansion with the correct displacements.

    Specification(s): check_skins_step1

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.381.30.491.30.55

  • 1.30.41

    Specification(s): graveyard

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 1.30.42The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.41

  • 1.30.43The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions, with a graveyard region outside the original mesh.

    Specification(s): check_skins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.421.30.45

  • 1.30.44The system shall output the MOAB mesh copied from libMesh into the .h5m format

    Specification(s): output_mesh

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.45The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.44

  • 1.30.46The 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.

    Specification(s): check_volume0

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.421.30.45

  • 1.30.47The 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.

    Specification(s): bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.48The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step0

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.49The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step1

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.50The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions for second-order tets

    Specification(s): check_skins_step0

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.371.30.481.30.54

  • 1.30.51The 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.

    Specification(s): check_skins_step1

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.381.30.491.30.55

  • 1.30.52The system shall bin elements according to temperature and density, on multiple subdomains, and be able to visualize the bins on the mesh volume.

    Specification(s): bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.53The system shall bin elements according to temperature, on multiple subdomains, and be able to visualize the bins.

    Specification(s): bins_without_density

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.54The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step0

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.55The system shall be able to convert a .h5m file to gmsh

    Specification(s): convert_to_gmsh_step1

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

    Prerequisite(s): 1.30.361.30.471.30.52

  • 1.30.56The system shall properly skin a MOAB mesh and create new MOAB surface meshes bounding bin regions

    Specification(s): check_skins_step0

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.371.30.481.30.54

  • 1.30.57The 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.

    Specification(s): check_skins_step1

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    Prerequisite(s): 1.30.381.30.491.30.55

  • 1.30.58The system shall error if the requirements for a binning variable type are violated.

    Specification(s): wrong_type

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.59The NekScalarValue shall allow NekRS simulations to interface with MOOSE's Controls system

    Specification(s): controls

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.60The NekScalarValue shall allow standalone NekRS simulations to interface with MOOSE's Controls system

    Specification(s): controls_standalone

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.61The system shall error if trying to change nuclide densities for a non-existing material ID.

    Specification(s): nonexistent_id

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.62The system shall error if trying to add a nuclide not accessible in the cross section library.

    Specification(s): nonexistent_nuclide

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.63The system shall give identical results to a standalone OpenMC run if the nuclide compositions are modified, but are still set to their initial values.

    Specification(s): no_change

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.64The system shall give identical results to a standalone OpenMC run if the nuclide densities are modified, but there are no nuclides added or removed.

    Specification(s): no_composition_change

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.65The 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.

    Specification(s): thermal_density

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.66The system shall give identical results to a standalone OpenMC run if the nuclide densities and nuclides are modified.

    Specification(s): nuclide_and_density

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.67The system shall error if inconsistent lengths for names and densities are provided.

    Specification(s): different_length

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.68The system shall error if
    1. trying to edit a non-existant tally
    2. trying to add a nuclide not accessible in the cross section library
    3. trying to add an invalid score to a tally
    4. the filter referenced by an OpenMCFilterEditor via ID does not exist and is not flagged for creation
    5. an OpenMCDomainFilter editor exists with the same filter ID but a different filter type
    6. more than one OpenMCDomainFilterEditor eixsts with the same filter ID
    7. more than one OpenMCTallyEditor eixsts with the same tally ID
    8. an OpenMCTallyEditor eixsts for a mapped tally created by Cardinal

    Specification(s): errors/nonexistent_tally, errors/nonexistent_nuclide, errors/invalid_score, errors/nonexistent_filter, errors/clashing_filter_types, errors/clashing_filter_ids, errors/clashing_tally_ids, errors/clashing_mapped_tally

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.69Ensure that nuclides specified by a tally editor UO are present in the tally output

    Specification(s): nuclides

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.70Ensure that the scattering score specified by a tally editor UO are present in the tally output

    Specification(s): scatter_tally

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.71Ensure that the absorption score for a specific nuclide specified by a tally editor UO are present in the tally output

    Specification(s): absorption_u238

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.72Ensure that a cell filter specified by a tally editor UO are present in the tally output

    Specification(s): add_cell_filter

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.73Ensure that a material filter specified by a tally editor UO are present in the tally output

    Specification(s): add_material_filter

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.74Ensure that a universe filters specified by a tally editor UO are present in the tally output

    Specification(s): add_universe_filter

    Design: OpenMCTallyEditorOpenMCDomainFilterEditor

    Issue(s): #837

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • 1.30.75A radial bin shall divide space according to 1-D layers in the radial direction.

    Specification(s): bin

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.76The output points shall be automatically output for a single-axis radial distribution.

    Specification(s): 1d_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.77The output points shall be automatically output for a single-axis radial distribution plus a 1-D distribution.

    Specification(s): 2d_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.78The system shall precompile a Nek case in preparation for a multi-input simulation.

    Specification(s): precompile

    Collection(s): FUNCTIONAL

    Type(s): RunCommand

  • 1.30.79The system shall error if an invalid boundary ID is specified

    Specification(s): invalid_boundary

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.80The system shall correctly integrate over a sideset in the NekRS domain when mapping space by the quadrature point

    Specification(s): z_bins

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.81The system shall correctly integrate over a sideset in the NekRS domain when mapping space by the face centroid

    Specification(s): z_bins_by_centroid

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.82The system shall correctly average over a sideset in the NekRS domain

    Specification(s): side_average

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.83The system shall error if the userobjects aren't derived from the correct base class.

    Specification(s): type_error

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.84The system shall error if the userobjects aren't listed in the correct order in the input file.

    Specification(s): ordering_error

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.85A subchannel and 1-D layered bin shall be combined to give a multi-dimensional binning and demonstrate correct results for volume integrals and averages.

    Specification(s): subchannel_layered

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.86System shall error if user attemps to combine multiple bins that specify the same coordinate direction.

    Specification(s): conflicting_bins

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.87The output points shall be automatically output for a single-axis subchannel binning

    Specification(s): 1d_output

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.88System shall error if a side user object is provided to a volume binning user object.

    Specification(s): wrong_type

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.89System shall error if attempting to use a normal velocity component with a user object that does not have normals defined

    Specification(s): invalid_component

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.90A 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.

    Specification(s): user_component

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.91A pin-centered subchannel bin shall give correct results for side averages of temperature.

    Specification(s): pin_1d

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.92The system shall error if the rotation axis is not perpendicular to the symmetry normal

    Specification(s): non_perpendicular_axis

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.93The system shall error if the rotation angle does not describe a valid symmetry wedge

    Specification(s): non_integer_angle

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.94Spatially-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.

    Specification(s): nondim

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 1.30.95The system shall warn the user if encountering volume calculations needing instance-level granularity, since this is not available yet in OpenMC itself.

    Specification(s): warn_instances

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.96The system shall map from a stochastic volume calculation to MOOSE for repeated cell instances

    Specification(s): instances

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.97The system shall terminate the stochastic volume calculation using a relative error metric.

    Specification(s): rel_err_trigger

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.98The system shall error if an invalid bounding box is specified for volume calculations

    Specification(s): invalid_box

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.99The system shall map stochastic volumes for each OpenMC cell which maps to MOOSE.

    Specification(s): single_level

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.100The system shall map stochastic volumes for each OpenMC cell which maps to MOOSE when the Mesh is not in units of centimeters

    Specification(s): single_level_scaling

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.101The system shall error if trying to view stochastic volumes without the stochastic volume calculation having been created.

    Specification(s): missing_vol

    Collection(s): FUNCTIONALFAILURE_ANALYSIS

    Type(s): RunException

  • 1.30.102The system shall terminate the stochastic volume calculation using a relative error metric.

    Specification(s): rel_err_trigger

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 1.30.103The system shall correctly compute volumes in OpenMC when using a user-provided bounding box.

    Specification(s): user_bb

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

Usability Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

Performance Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

System Interface Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

References

No citations exist within this document.