Ray Tracing System Design Description
This template follows INL template TEM-140, "IT System Design Description."
This document serves as an addendum to Framework System Design Description and captures information for Software Design Description (SDD) specific to the Ray Tracing application.
Introduction
Frameworks are a software development construct aiming to simplify the creation of specific classes of applications through abstraction of low-level details. The main object of creating a framework is to provide an interface to application developers that saves time and provides advanced capabilities not attainable otherwise. The MOOSE, mission is just that: provide a framework for engineers and scientists to build state-of-the-art, computationally scalable finite element based simulation tools.
MOOSE was conceived with one major objective: to be as easy and straightforward to use by scientists and engineers as possible. MOOSE is meant to be approachable by non-computational scientists who have systems of PDEs they need to solve. Every single aspect of MOOSE was driven by this singular principle from the build system to the API to the software development cycle. At every turn, decisions were made to enable this class of users to be successful with the framework. The pursuit of this goal has led to many of the unique features of MOOSE:
A streamlined build system
An API aimed at extensible
Straightforward APIs providing sensible default information
Integrated, automatic, and rigorous testing
Rapid, continuous integration development cycle
Codified, rigorous path for contributing
Applications are modular and composable
Each of these characteristics is meant to build trust in the framework by those attempting to use it. For instance, the build system is the first thing potential framework users come into contact with when they download a new software framework. Onerous dependency issues, complicated, hard to follow instructions or build failure can all result in a user passing on the platform. Ultimately, the decision to utilize a framework comes down to whether or not you trust the code in the framework and those developing it to be able to support your desired use-case. No matter the technical capabilities of a framework, without trust users will look elsewhere. This is especially true of those not trained in software development or computational science.
Developing trust in a framework goes beyond utilizing "best practices" for the code developed, it is equally important that the framework itself is built upon tools that are trusted. For this reason, MOOSE relies on a well-established code base of libMesh and PETSc. The libMesh library provides foundational capability for the finite element method and provides interfaces to leading-edge numerical solution packages such as PETSc.
With these principles in mind, an open source, massively parallel, finite element, multiphysics framework has been conceived. MOOSE is an on-going project started in 2008 aimed toward a common platform for creation of new multiphysics tools. This document provides design details pertinent to application developers as well as framework developers.
Use Cases
The MOOSE Framework is targeted at two main groups of actors: Developers and Users. Developers are the main use case. These are typically students and professionals trained in science and engineering fields with some level of experience with coding but typically very little formal software development training. The other user group is Users. Those who intend to use an application built upon the framework without writing any computer code themselves. Instead they may modify or create input files for driving a simulation, run the application, and analyze the results. All interactions through MOOSE are primarily through the command-line interface and through a customizable block-based input file.
System Purpose
The Software Design Description provided here is description of each object in the system. The pluggable architecture of the framework makes MOOSE and MOOSE-based applications straightforward to develop as each piece of end-user (developer) code that goes into the system follows a well-defined interface for the underlying systems that those object plug into. These descriptions are provided through developer-supplied "markdown" files that are required for all new objects that are developed as part of the framework, modules and derivative applications. More information about the design documentation can be found in Documenting MOOSE.
System Scope
The purpose of this software is to provide several libraries that can be used to build an application based upon the framework. Additionally, several utilities are provided for assisting developers and users in end-to-end FEM analysis. A brief overview of the major components are listed here:
Component | Description |
---|---|
framework library | The base system from which all MOOSE-based applications are created |
module libraries | Optional "physics" libraries that may be used in an application to provide capability |
build system | The system responsible for creating applications for a series of libraries and applications |
test harness | The extendable testing system for finding, scheduling, running, and reporting regression tests |
"peacock" | The graphical user interface (GUI) for building input files, executing applications, and displaying results |
MooseDocs | The extendable markdown system for MOOSE providing common documentation and requirements enforcement |
"stork" | The script and templates for generating a new MOOSE-based application ready for building and testing |
examples | A set of complete applications demonstrating the use of MOOSE's pluggable systems |
tutorials | Step by step guides to building up an application using MOOSE's pluggable systems |
unit | An application for unit testing individual classes or methods of C++ code |
Dependencies and Limitations
The MOOSE platform has several dependencies on other software packages and has scope that is constantly evolving based upon funding, resources, priorities, and lab direction. However, the software is open-source and many features and even bugs can be offloaded to developers with appropriate levels of knowledge and direction from the main design team. The primary list of software dependencies is listed below. This list is not meant to be exhaustive. Individual operating systems may require specific packages to be installed prior to using MOOSE, which can be found on the Install MOOSE pages.
Software Dependency | Description |
---|---|
libMesh | Finite Element Library and I/O routines |
PETSc | Solver Package |
hypre | Multigrid Preconditioner |
MPI | A distributed parallel processing library (MPICH) |

Figure 1: A diagram of the MOOSE code platform.
References
Definitions and Acronyms
This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.
Definitions
- Pull (Merge) Request: A proposed change to the software (e.g. usually a code change, but may also include documentation, requirements, design, and/or testing). - Baseline: A specification or product (e.g., project plan, maintenance and operations (M&O) plan, requirements, or design) that has been formally reviewed and agreed upon, that thereafter serves as the basis for use and further development, and that can be changed only by using an approved change control process (NQA-1, 2009). - Validation: Confirmation, through the provision of objective evidence (e.g., acceptance test), that the requirements for a specific intended use or application have been fulfilled (24765:2010(E), 2010). - Verification: (1) The process of: evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (2) Formal proof of program correctness (e.g., requirements, design, implementation reviews, system tests) (24765:2010(E), 2010).
Acronyms
Acronym | Description |
---|---|
API | Application Programming Interface |
DOE-NE | Department of Energy, Nuclear Energy |
FE | finite element |
FEM | Finite Element Method |
GUI | graphical user interface |
HIT | Hierarchical Input Text |
HPC | High Performance Computing |
I/O | Input/Output |
INL | Idaho National Laboratory |
MOOSE | Multiphysics Object Oriented Simulation Environment |
MPI | Message Passing Interface |
PDEs | partial differential equations |
SDD | Software Design Description |
Design Stakeholders and Concerns
Design Stakeholders
Stakeholders for MOOSE include several of the funding sources including Department of Energy, Nuclear Energy (DOE-NE) and the INL. However, Since MOOSE is an open-source project, several universities, companies, and foreign governments have an interest in the development and maintenance of the MOOSE project.
Stakeholder Design Concerns
Concerns from many of the stakeholders are similar. These concerns include correctness, stability, and performance. The mitigation plan for each of these can be addressed. For correctness, MOOSE development requires either regression or unit testing for all new code added to the repository. The project contains several comparisons against analytical solutions where possible and also other verification methods such as MMS. For stability, MOOSE maintains multiple branches to incorporate several layers of testing both internally and for dependent applications. Finally, performance tests are also performed as part of the the normal testing suite to monitor code change impacts to performance.
System Design
The MOOSE framework itself is composed of a wide range of pluggable systems. Each system is generally composed of a single or small set of C++ objects intended to be specialized by a Developer to solve a specific problem. To accomplish this design goal, MOOSE uses several modern object-oriented design patterns. The primary overarching pattern is the "Factory Pattern". Users needing to extend MOOSE may inherit from one of MOOSE's systems to providing an implementation meeting his or her needs. The design of each of these systems is documented on the mooseframework.org wiki in the Tutorial section. Additionally, up-to-date documentation extracted from the source is maintained on the the mooseframework.org documentation site after every successful merge to MOOSE's stable branch. After these objects are created, the can be registered with the framework and used immediately in a MOOSE input file.
System Structure
The MOOSE framework architecture consists of a core and several pluggable systems. The core of MOOSE consists of a number of key objects responsible for setting up and managing the user-defined objects of a finite element simulation. This core set of objects has limited extendability and exist for every simulation configuration that the framework is capable of running.
Adaptivity
Adaptivity/Indicators
Adaptivity/Markers
AuxKernels
AuxKernels/MatVecRealGradAuxKernel
AuxKernels/MaterialVectorAuxKernel
AuxKernels/MaterialVectorGradAuxKernel
AuxScalarKernels
AuxVariables
AuxVariables/MultiAuxVariables
BCs
BCs/CavityPressure
BCs/CoupledPressure
BCs/InclinedNoDisplacementBC
BCs/Periodic
BCs/Pressure
Bounds
Closures
Components
Constraints
Contact
ControlLogic
Controls
CoupledHeatTransfers
Covariance
DGKernels
Dampers
Debug
Debug/MaterialDerivativeTest
DeprecatedBlock
DiracKernels
Distributions
DomainIntegral
Executioner
Executioner/Adaptivity
Executioner/Predictor
Executioner/Quadrature
Executioner/TimeIntegrator
Executioner/TimeStepper
Executors
FVBCs
FVInterfaceKernels
FVKernels
FluidPropertiesInterrogator
Functions
GeochemicalModelInterrogator
GlobalParams
GrayDiffuseRadiation
HeatStructureMaterials
ICs
ICs/PolycrystalICs
ICs/PolycrystalICs/BicrystalBoundingBoxIC
ICs/PolycrystalICs/BicrystalCircleGrainIC
ICs/PolycrystalICs/PolycrystalColoringIC
ICs/PolycrystalICs/PolycrystalRandomIC
ICs/PolycrystalICs/PolycrystalVoronoiVoidIC
ICs/PolycrystalICs/Tricrystal2CircleGrainsIC
InterfaceKernels
Kernels
Kernels/CHPFCRFFSplitKernel
Kernels/DynamicTensorMechanics
Kernels/HHPFCRFFSplitKernel
Kernels/PFCRFFKernel
Kernels/PolycrystalElasticDrivingForce
Kernels/PolycrystalKernel
Kernels/PolycrystalStoredEnergy
Kernels/PoroMechanics
Kernels/RigidBodyMultiKernel
Kernels/TensorMechanics
Materials
Mesh
Mesh/Partitioner
Modules
Modules/CompressibleNavierStokes
Modules/FluidProperties
Modules/HeatConduction
Modules/HeatConduction/ThermalContact
Modules/HeatConduction/ThermalContact/BC
Modules/IncompressibleNavierStokes
Modules/NavierStokesFV
Modules/Peridynamics
Modules/Peridynamics/Mechanics
Modules/Peridynamics/Mechanics/GeneralizedPlaneStrain
Modules/Peridynamics/Mechanics/Master
Modules/PhaseField
Modules/PhaseField/Conserved
Modules/PhaseField/DisplacementGradients
Modules/PhaseField/EulerAngles2RGB
Modules/PhaseField/GrainGrowth
Modules/PhaseField/GrandPotential
Modules/PhaseField/Nonconserved
Modules/PorousFlow
Modules/PorousFlow/BCs
Modules/TensorMechanics
Modules/TensorMechanics/CohesiveZoneMaster
Modules/TensorMechanics/DynamicMaster
Modules/TensorMechanics/GeneralizedPlaneStrain
Modules/TensorMechanics/GlobalStrain
Modules/TensorMechanics/LineElementMaster
Modules/TensorMechanics/Master
Modules/TensorMechanics/MaterialVectorBodyForce
MortarGapHeatTransfer
MultiApps
NodalKernels
NodalNormals
Outputs
PorousFlowBasicTHM
PorousFlowFullySaturated
PorousFlowUnsaturated
Postprocessors
Preconditioning
Problem
RayBCs
RayKernels
ReactionNetwork
ReactionNetwork/AqueousEquilibriumReactions
ReactionNetwork/SolidKineticReactions
Reporters
Samplers
ScalarKernels
SpatialReactionSolver
StochasticTools
Surrogates
ThermalContact
TimeDependentReactionSolver
TimeIndependentReactionSolver
Trainers
Transfers
UserObjects
Variables
Variables/CHPFCRFFSplitVariables
Variables/HHPFCRFFSplitVariables
Variables/PFCRFFVariables
Variables/PolycrystalVariables
VectorPostprocessors
XFEM
The MooseApp is the top-level object used to hold all of the other objects in a simulation. In a normal simulation a single MooseApp object is created and "run()". This object uses it's Factory objects to build user defined objects which are stored in a series of Warehouse objects and executed. The Finite Element data is stored in the Systems and Assembly object while the domain information (the Mesh) is stored in the Mesh object. A series of threaded loops are used to run parallel calculations on the objects created and stored within the warehouses.
MOOSE's pluggable systems are documented on the mooseframework.org wiki. Each of these systems has set of defined polymorphic interfaces and are designed to accomplish a specific task within the simulation. The design of these systems is fluid and is managed through agile methods and ticket request system on the Github.org website.
Data Design and Control
At a high level, the system is designed to process HIT input files to construct several objects that will constitute an FE simulation. Some of the objects in the simulation may in turn load other file-based resources to complete the simulation. Examples include meshes or data files. The system will then assemble systems of equations and solve them using the libraries of the Code Platform. The system can then output the solution in one or more supported output formats commonly used for visualization.
Human-Machine Interface Design
MOOSE is a command-line driven program. All interaction with MOOSE and MOOSE-based codes is ultimately done through the command line. This is typical for HPC applications that use the MPI interface for running on super computing clusters. Optional GUIs may be used to assist in creating input files and launching executables on the command line.
System Design Interface
All external system interaction is performed either through file Input/Output (I/O) or through local Application Programming Interface (API) calls. Neither the framework, nor the modules are designed to interact with any external system directly through remote procedure calls. Any code to code coupling performed using the framework are done directly through API calls either in a static binary or after loading shared libraries.
Security Structure
The framework does not require any elevated privileges to operate and does not run any stateful services, daemons or other network programs. Distributed runs rely on the MPI library.
Requirements Cross-Reference
- ray_tracing: AddRayBCAction
- 13.1.1The system shall throw an error when adding a RayBC and the provided RayTracingStudy
- could not be found
- or is not a RayTracingStudy.
Specification(s): provided/missing, provided/not_a_study
Design: AddRayBCAction
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.1.2The system shall throw an error when adding a RayBC and RayTracingStudy was not provided
- and multiple studies were found
- or when no studies were found.
Specification(s): not_provided/multiple, not_provided/missing
Design: AddRayBCAction
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: AddRayKernelAction
- 13.1.3The system shall throw an error when adding a RayKernel and the provided RayTracingStudy
- could not be found
- or is not a RayTracingStudy.
Specification(s): provided/missing, provided/not_a_study
Design: AddRayKernelAction
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.1.4The system shall throw an error when adding a RayKernel and RayTracingStudy was not provided
- and multiple studies were found
- or when no studies were found.
Specification(s): not_provided/multiple, not_provided/missing
Design: AddRayKernelAction
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RayTracingStudy
- 13.2.1A RayTracingObject shall return a useful error when
- the study is provided via param and is of the wrong type
- the study is provided by default and is of the wrong type
Specification(s): errors/get_study_bad_param, errors/get_study_bad_default
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.5.4The system shall support the output of the total number of rays started, the total distance traveled by rays, and the number of processor crossings the rays have encountered.
Specification(s): test
Design: RayTracingStudyResultRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.8.1The system shall support the console output of information pertaining to a Ray.
Specification(s): get_info
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): RunApp
- 13.8.2The system shall provide a method for determining the equality of rays
Specification(s): equality
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): RunApp
- 13.8.3The system shall report a reasonable error from a ray when
- checking if a ray is at its end point without an end point being set
- retrieving a ray's end point when its end point has not been set
- setting a ray's start point that has already been set
- setting a ray's starting direction multiple times without clearing it
- setting a ray's start point that is not contained within the mesh bounding box
- setting a ray's starting incoming side without setting its starting element
- setting a ray's starting incoming side to an invalid side
- setting a ray's starting incoming side to one that does not contain the starting point
- setting a ray's starting point to a point that is not contained within a given starting element
- setting a ray's starting direction before setting its starting information,
- setting a ray's starting direction to the zero vector
- setting a ray's end point before setting its start point
- setting a ray's end point to the same as its start point
- setting a ray's end point and starting direction
- setting a ray's max distance after setting its end point
- setting a ray's end point after setting its max distance
- setting a ray's end point to a point that is not within the mesh bounding box
- setting a ray's starting maximum distance before setting its start information
- setting a ray's starting maximum distance to a negative value
- setting the starting element for a ray to an inactive element
Specification(s): errors/at_end_without_set, errors/end_point_without_set, errors/set_start_again, errors/set_direction_again, errors/set_start_fail_bbox, errors/set_side_without_elem, errors/set_invalid_side, errors/set_bad_side, errors/set_bad_start, errors/set_direction_before_start, errors/set_zero_direction, errors/set_end_before_start, errors/set_end_equal_start, errors/set_end_with_direction, errors/set_distance_with_end, errors/set_end_with_distance, errors/set_end_fail_bbox, errors/set_distance_before_start, errors/set_distance_negative, errors/set_start_inactive
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.9.1The system shall be able to trace rays in a mesh that utilizes adaptiviy with the element types
- QUAD4,
- TRI3,
- HEX8,
- and EDGE2.
Specification(s): elem_tests/quad4, elem_tests/tri3, elem_tests/hex8, elem_tests/edge2
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.2The system shall support the use of side normals to cull potential exiting sides within ray tracing for
- two-dimensional meshes
- and for three-dimensional meshes.
Specification(s): dim/2d, dim/3d
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.3The system shall be able to trace rays within EDGE2 elements.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.4The system shall be able to trace rays within EDGE3 elements.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.5The system shall be able to trace rays within EDGE4 elements.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.6The system shall be able to trace rays within planar HEX20 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.7The system shall be able to trace rays within planar HEX27 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.8The system shall be able to trace rays within planar HEX8 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.9The system shall support the ending of traced rays on internal sidesets in
- one-dimensional meshes,
- two-dimensional meshes,
- and three-dimensional meshes.
Specification(s): kill/1d, kill/2d, kill/3d
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.10The system shall support the specular reflection of traced rays on internal sidesets in
- one-dimensional meshes,
- two-dimensional meshes,
- and three-dimensional meshes.
Specification(s): reflect/1d, reflect/2d, reflect/3d
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.11The system shall throw an error if RayBCs are defined on internal sidesets, but the study does not have internal sideset capability enabled.
Specification(s): internal_sidesets_disabled
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.9.12The system shall throw an error if RayBCs are defined on internal sidesets and said internal sidesets are not bounded by different subdomains.
Specification(s): not_subdomain_bounded
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.9.13The system shall be able to trace rays on 3D meshes that have nonplanar faces.
Specification(s): test
Design: RayTracingStudy
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.14The system shall by default warn that tracing on non-planar faces is an approximation.
Specification(s): warning
Design: RayTracingStudy
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.9.15The system shall be able to trace rays within planar PRISM15 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.16The system shall be able to trace rays within planar PRISM18 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.17The system shall be able to trace rays within planar PRISM6 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.18The system shall be able to trace rays within planar PYRAMID13 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.19The system shall be able to trace rays within planar PYRAMID14 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.20The system shall be able to trace rays within planar PYRAMID5 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.21The system shall be able to trace rays within planar QUAD4 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.22The system shall be able to trace rays within planar QUAD8 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.23The system shall be able to trace rays within planar QUAD9 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.24The system shall report an error when a ray hits a boundary during tracing and
- the boundary does not have any RayBCs
- and then the boundary does not have any RayBCs that change the trajectory of the ray or end the ray.
Specification(s): error/both, error/one
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.9.25The system shall be able to trace rays within planar TET10 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.26The system shall be able to trace rays within planar TET4 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from the centroids of boundary edges in the direction of all other edge centroids in the same element,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/ete, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.27The system shall be able to trace rays within planar TRI3 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.28The system shall be able to trace rays within planar TRI6 elements
- from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
- from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
- from the centroids of all boundary sides to the centroids of all other boundary elements,
- from boundary sides centroids using an angular quadrature,
- and from boundary element centroids using an angular quadrature.
Specification(s): tests/vtv, tests/ctv, tests/ctc, tests/side_aq, tests/centroid_aq
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.9.29The system shall support not setting the incoming side at the beginning of a trace.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.3The system shall be able to create additional rays during tracing with RayBCs in
- two-dimensional meshes
- and in three-dimensional meshes.
Specification(s): tests/2d, tests/3d
Design: RayBCsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.4The system shall be able to trace rays using a
- last in, first out buffer
- and with a circular buffer.
Specification(s): tests/lifo, tests/circular
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.5The RayTracingStudy shall return a useful error when
- the same ray is added to be traced multiple times,
- when local rays that have the same ID are added to be traced,
- when rays that have the same ID on different processors are added to be traced,
- when the domain is not covered with ray kernels,
- when ray names are provided to a ray tracing object and the study does not register ray names,
- when a ray name is provided to a ray tracing object and said name is not registered to a ray,
- when the study is set to execute with residual kernels and non-residual kernels,
- when the study is set to execute with residual kernels and an eigenvalue executioner,
- when the trajectory of a ray is changed after it has started tracing,
- when a ray's counters are reset when not generating rays
- when tracing in a mesh with adaptivity and an unsupported element type
- when tracing in a mesh when the average subdomain hmax is a poor approximation due to stretched elements
- when ray data is registered too late
- when ray data is registered with the same name across systems
- when requesting a ray data index for an invalid name
- when requesting a ray data name for an invalid index
- when requesting ray kernels before they are setup
- when requesting ray bcs before they are setup
- when obtaining the ray bank when banking is disabled
- when obtaining the ray bank when it is not available
- when registering a ray when ray registration is disabled
- when getting a registered ray ID when ray registration is disabled
- when getting a registered ray name when ray registration is disabled
- when requesting a registered ray ID for a ray that is not registered
- when requesting a registered ray name for a ray that is not registered
- when reserving space in the ray buffer outside of registration, and
- when requesting a subdomain hmax for an invalid subdomain
- building an element extrema edge for invalid vertices
- requesting cached element normals when element normal caching has not been setup
- getting the index of ray data when aux data with the same name exists
- getting the index of ray aux data when data with the same name exists
- registering a ray more than once with the same name
Specification(s): tests/duplicate_ray, tests/local_non_unique_id, tests/global_non_unique_id, tests/ray_kernel_coverage_check, tests/unneeded_rays, tests/ray_not_found, tests/mixed_pre_kernel_execute, tests/eigenvalue, tests/error_if_tracing, tests/reset_counters, tests/adapt_bad_type, tests/hmax_vary, tests/register_ray_data_late, tests/register_ray_data_same_name, tests/ray_data_index_bad_name, tests/ray_data_name_bad_index, tests/get_ray_kernels_early, tests/get_ray_bcs_early, tests/get_bank_disabled, tests/get_bank_bad, tests/register_ray_no_registration, tests/registered_ray_id_no_registration, tests/registered_ray_name_no_registration, tests/registered_ray_id_missing, tests/registered_ray_name_missing, tests/reserve_bad, tests/subdomain_hmax_missing, tests/elem_extrema_build_edge, tests/get_elem_normals_unimplemented, tests/ray_data_index_other_exists, tests/ray_data_aux_index_other_exists, tests/register_ray_again
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.6The system shall be able to change the trajectory of rays during tracing within RayKernels.
Specification(s): test
Design: RayKernelsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.7The system shall be able to create additional rays during tracing within RayKernels in
- two-dimensional meshes
- and in three-dimensional meshes.
Specification(s): tests/2d, tests/3d
Design: RayBCsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.8The system shall support the tracing of rays using
- an asynchronous method,
- a bulk-synchronous method,
- and the harm method.
Specification(s): tests/smart, tests/bs, tests/harm
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.9The system shall support the tracing of rays across multiple subdomains.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.10.10The system shall support the storage and manipulation of data and auxiliary data on a ray when
- sizing the Ray data on acquire
- and when not sizing the Ray data on acquire.
Specification(s): test/sized, test/unsized
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.11The system shall support the re-use of traced rays.
Specification(s): test
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.12The system shall support the failure of a trace gracefully via a warning.
Specification(s): no_bc
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.13The system shall support ending rays by a user-set maximum distance.
Specification(s): max_distance
Design: RayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: IntegralRayKernelBase
- 13.3.1The system shall support line integrals in the
- rz coordinate system
- and in the rspherical coordinate system.
Specification(s): line_integral/rz, line_integral/rspherical
Design: IntegralRayKernelBase
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: RayTracingMeshOutput
- 13.4.1The system shall support the mesh output of traced rays on meshes of element types
- QUAD4,
- TRI3,
- HEX8, and
- TET4.
Specification(s): elem_type/quad4, elem_type/tri3, elem_type/hex8, elem_type/tet4
Design: RayTracingMeshOutput
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.4.2The system shall support the mesh output of traced rays using the Nemesis format.
Specification(s): nemesis
Design: RayTracingNemesisRayTracingMeshOutput
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.4.3The system shall support the mesh output of traced rays using the fewest segments possible to represent the trace in
- Exodus format and
- in Nemesis format.
Specification(s): no_segments/exodus, no_segments/nemesis
Design: RayTracingMeshOutput
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.4.4The sytem shall support the output of ray data when outputting rays in a mesh format using
- exodus and
- nemesis formats.
Specification(s): data/exodus, data/nemesis
Design: RayTracingMeshOutput
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.4.5The system shall report an error when ouputting rays in a mesh format when
- ray data is requested to be output but it is not cached,
- aux data is requested to be output but it is not cached,
- both nodal and non-nodal data is requested to be output,
- and when nodal data is requested to be output but segment-wise information is not cached.
Specification(s): errors/no_cached_data, errors/no_cached_aux_data, errors/data_nodal_and_non_nodal, errors/nodal_no_segments
Design: RayTracingMeshOutput
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.4.6The system shall report a warning when rays are requested to be output in a mesh format but cached ray inforamtion is not found.
Specification(s): no_segments_warning
Design: RayTracingMeshOutput
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.7.20The system shall provide the ability to output the segment wise accumulated integral of a variable along a line with a 2D, finite-element diffusion problem.
Specification(s): simple_diffusion_rays
Design: VariableIntegralRayKernelRayTracingMeshOutput
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.21The system shall provide the ability to output the segment wise, linearly approximated, accumulated integral of a variable along a line with a 2D, finite-element diffusion problem.
Specification(s): simple_diffusion_rays_nodal
Design: VariableIntegralRayKernelRayTracingMeshOutput
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- ray_tracing: RayTracingNemesis
- 13.4.2The system shall support the mesh output of traced rays using the Nemesis format.
Specification(s): nemesis
Design: RayTracingNemesisRayTracingMeshOutput
Collection(s): FUNCTIONAL
Type(s): Exodiff
- ray_tracing: RayDataValue
- 13.5.1The system shall support the ability to output the data stored on a ray.
Specification(s): test
Design: RayDataValue
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.5.2The system shall report an error when ouputting a single data value stored on a ray when
- the RayTracingStudy does not support accessing rays by name,
- the RayTracingStudy does not support the banking of rays on completion,
- the named ray was not found,
- the named ray data was not found,
- the named ray aux data was not found,
- the ray with the given id was not found,
- neither an ID or name was provided, and
- both an ID and name was provided.
Specification(s): errors/no_registration, errors/no_banking, errors/ray_name_not_found, errors/data_name_not_found, errors/aux_data_name_not_found, errors/id_not_found, errors/neither_provided, errors/both_provided
Design: RayDataValue
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RayIntegralValue
- 13.5.3The system shall report an error when sampling the integrated value by a ray and
- the provided IntegralRayKernel is not an IntegralRayKernel,
- the provided IntegralRayKernel was not found,
- a Ray with the given name was not found,
- the provided study does not support Ray registration,
- or the provided study does not support Ray banking.
Specification(s): errors/not_integral_ray_kernel, errors/kernel_not_found, errors/ray_not_found, errors/no_registration, errors/no_banking
Design: RayIntegralValue
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RayTracingStudyResult
- 13.5.4The system shall support the output of the total number of rays started, the total distance traveled by rays, and the number of processor crossings the rays have encountered.
Specification(s): test
Design: RayTracingStudyResultRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: RayBCs
- 13.6.1The system shall support the dependency resolution of RayBCs.
Specification(s): test
Design: RayBCs
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.6.2The system shall throw a reasonable error when adding a dependency for a RayBC that does not exist.
Specification(s): missing
Design: RayBCs
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.6.3The system shall report an error when changing a ray direction within a RayBC when
- the ray was set to not continue by another RayBC,
- the ray already had its direction changed,
- the end point of the ray was set upon generation,
- and when the direction is changed to the zero vector.
Specification(s): change_direction/should_not_continue, change_direction/again, change_direction/end_set, change_direction/zero
Design: RayBCs
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.6.4The system shall support the specular reflection of rays on a boundary.
Specification(s): test
Design: ReflectRayBCRayBCs
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.6.5The system shall report a reasonable warning when using an approximation to reflect a ray on a side that is not planar.
Specification(s): non_planar_warning
Design: ReflectRayBCRayBCs
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.3The system shall be able to create additional rays during tracing with RayBCs in
- two-dimensional meshes
- and in three-dimensional meshes.
Specification(s): tests/2d, tests/3d
Design: RayBCsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.10.7The system shall be able to create additional rays during tracing within RayKernels in
- two-dimensional meshes
- and in three-dimensional meshes.
Specification(s): tests/2d, tests/3d
Design: RayBCsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: ReflectRayBC
- 13.6.4The system shall support the specular reflection of rays on a boundary.
Specification(s): test
Design: ReflectRayBCRayBCs
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.6.5The system shall report a reasonable warning when using an approximation to reflect a ray on a side that is not planar.
Specification(s): non_planar_warning
Design: ReflectRayBCRayBCs
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: ADRayKernel
- 13.7.1The system shall throw a reasonable error if an ADRayKernel
- is used with a coordinate system other than xyz or
- is used in an explicit manner.
Specification(s): errors/xyz_only, errors/implicit_only
Design: ADRayKernel
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: AuxRayKernel
- 13.7.2The system shall throw a reasonable error if a non-supported auxiliary variable is used with a ray aux kernel.
Specification(s): const_monomial_only
Design: AuxRayKernel
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RayKernels
- 13.7.3The system shall support the coupling of variables on rays that contribute to the residual and Jacobian.
Specification(s): test
Design: RayKernels
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.4The system shall be able to produce the exact Jacobian with coupled variables on rays.
Specification(s): test_jac
Design: RayKernels
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 13.7.5The system shall support the coupling of variables using automatic differentiation on rays that contribute to the residual and Jacobian.
Specification(s): test_ad
Design: RayKernels
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.6The system shall be able to produce the exact Jacobian using automatic differentiation on rays.
Specification(s): test_ad_jac
Design: RayKernels
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): PetscJacobianTester
- 13.7.7The system shall support the dependency resolution of RayKernels.
Specification(s): test
Design: RayKernels
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.7.8The system shall throw a reasonable error when adding a dependency for a RayKernel that does not exist.
Specification(s): missing
Design: RayKernels
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.7.9The system shall report an error when changing a ray start and/or direction within a RayKernel when
- the ray was set to not continue by another RayKernel,
- the ray was set to not continue by another RayKernel and it is at its end point,
- the ray's trajectory was already changed,
- the ray's end point has been set,
- the ray's start point is not within the current element, and
- when the ray's new direction is set to the zero vector.
Specification(s): change_direction/should_not_continue, change_direction/should_not_continue_at_end, change_direction/changed_again, change_direction/end_set, change_direction/out_of_elem, change_direction/zero_direction
Design: RayKernels
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.6The system shall be able to change the trajectory of rays during tracing within RayKernels.
Specification(s): test
Design: RayKernelsRayTracingStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: FunctionIntegralRayKernel
- 13.7.10The system shall provide the ability to compute the integral of a Function along a line.
Specification(s): test
Design: FunctionIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.7.11The system shall provide the ability to compute the average value of a Function along a line.
Specification(s): average
Design: FunctionIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: LineSourceRayKernel
- 13.7.12The system shall provide an ability to produce a source term along a line.
Specification(s): test
Design: LineSourceRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.13The system shall provide an ability to solve a 2D diffusion problem with a line source term, with
- finite elements
- and finite volumes.
Specification(s): simple_diffusion/fe, simple_diffusion/fv
Design: LineSourceRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- ray_tracing: MaterialIntegralRayKernel
- 13.7.14The system shall provide the ability to compute the integral of a material property along a line.
Specification(s): test
Design: MaterialIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.7.15The system shall provide the ability to compute the average value of a material property along a line.
Specification(s): average
Design: MaterialIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: RayDistanceAux
- 13.7.16The system shall be able to store the distance traversed by a ray in each element in an auxiliary field.
Specification(s): test
Design: RayDistanceAux
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- ray_tracing: RayKernel
- 13.7.17The system shall throw a reasonable error if a RayKernel
- is utilized with a coordinate system other than xyz or
- if the execute flag for the associated ray study is not set correctly to use the RayKernel.
Specification(s): errors/xyz_only, errors/bad_execute_on
Design: RayKernel
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: VariableIntegralRayKernel
- 13.7.18The system shall provide the ability to compute the integral of a variable along a line.
Specification(s): test
Design: VariableIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.7.19The system shall provide the ability to compute the average value of a variable along a line.
Specification(s): average
Design: VariableIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- 13.7.20The system shall provide the ability to output the segment wise accumulated integral of a variable along a line with a 2D, finite-element diffusion problem.
Specification(s): simple_diffusion_rays
Design: VariableIntegralRayKernelRayTracingMeshOutput
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.21The system shall provide the ability to output the segment wise, linearly approximated, accumulated integral of a variable along a line with a 2D, finite-element diffusion problem.
Specification(s): simple_diffusion_rays_nodal
Design: VariableIntegralRayKernelRayTracingMeshOutput
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.7.22The system shall provide the ability to compute the line integral of a variable for a 2D diffusion problem, with
- finite elements
- and finite volumes.
Specification(s): simple_diffusion/fe, simple_diffusion/fv
Design: VariableIntegralRayKernel
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): CSVDiff
- ray_tracing: Ray
- 13.8.1The system shall support the console output of information pertaining to a Ray.
Specification(s): get_info
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): RunApp
- 13.8.2The system shall provide a method for determining the equality of rays
Specification(s): equality
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): RunApp
- 13.8.3The system shall report a reasonable error from a ray when
- checking if a ray is at its end point without an end point being set
- retrieving a ray's end point when its end point has not been set
- setting a ray's start point that has already been set
- setting a ray's starting direction multiple times without clearing it
- setting a ray's start point that is not contained within the mesh bounding box
- setting a ray's starting incoming side without setting its starting element
- setting a ray's starting incoming side to an invalid side
- setting a ray's starting incoming side to one that does not contain the starting point
- setting a ray's starting point to a point that is not contained within a given starting element
- setting a ray's starting direction before setting its starting information,
- setting a ray's starting direction to the zero vector
- setting a ray's end point before setting its start point
- setting a ray's end point to the same as its start point
- setting a ray's end point and starting direction
- setting a ray's max distance after setting its end point
- setting a ray's end point after setting its max distance
- setting a ray's end point to a point that is not within the mesh bounding box
- setting a ray's starting maximum distance before setting its start information
- setting a ray's starting maximum distance to a negative value
- setting the starting element for a ray to an inactive element
Specification(s): errors/at_end_without_set, errors/end_point_without_set, errors/set_start_again, errors/set_direction_again, errors/set_start_fail_bbox, errors/set_side_without_elem, errors/set_invalid_side, errors/set_bad_side, errors/set_bad_start, errors/set_direction_before_start, errors/set_zero_direction, errors/set_end_before_start, errors/set_end_equal_start, errors/set_end_with_direction, errors/set_distance_with_end, errors/set_end_with_distance, errors/set_end_fail_bbox, errors/set_distance_before_start, errors/set_distance_negative, errors/set_start_inactive
Design: RayTracingStudyRay
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: ConeRayStudy
- 13.10.1The system shall be able to generate rays emitting from a point in a cone using angular quadrature in
- two-dimensional meshes
- and in three-dimensional meshes.
Specification(s): tests/2d, tests/3d
Design: ConeRayStudy
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): Exodiff
- 13.10.2The ConeRayStudy shall report a useful error when
- the provided directions are inconsistent in size
- the provided scaling factors are inconsistent in size
- the provided half cone angles are inconsistent in size
- the provided half cone angles are not valid angles
- the provided polar quadrature orders are inconsistent in size
- the provided azimuthal quadrature orders are inconsistent in size
- it is run with an invalid mesh dimension
Specification(s): errors/direction_size, errors/scaling_factors_size, errors/half_cone_angles_size, errors/half_cone_angles_valid, errors/polar_quad_orders_size, errors/azimuthal_quad_orders_size, errors/1d
Design: ConeRayStudy
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RepeatableRayStudy
- 13.10.14The system shall report an error when utilizing the repeatable ray study when
- both directions and points are provided,
- neither directions and points are provided,
- the number of start points provided is inconsistent,
- the number of directions provided is inconsistent,
- both end points and maximum distances are provided,
- the number of maximum distances provided is inconsistent,
- the provided maximum distance is non-positive,
- the number of end points provided is inconsistent,
- the initial data size is inconsistent with the number of rays,
- the initial data size is inconsistent with the provided data names,
- initial data is provided but data names are not provided,
- the initial aux data size is inconsistent with the number of rays,
- the initial aux data size is inconsistent with the provided aux data names,
- and aux initial data is provided but aux data names are not provided.
Specification(s): errors/directions_or_end_points, errors/neither_directions_or_end_points, errors/start_size, errors/directions_size, errors/max_distance_with_end, errors/max_distance_size, errors/max_distance_positive, errors/end_points_size, errors/initial_data_size, errors/initial_data_individual_size, errors/data_names_not_set, errors/initial_aux_data_size, errors/initial_aux_data_individual_size, errors/aux_data_names_not_set
Design: RepeatableRayStudy
Issue(s): #17030
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RepeatableRayStudyBase
- 13.10.15The RepeatableRayStudyBase shall support the
- outputting of checkpoint files and
- shall be capable of restarting from the output data.
Specification(s): test/checkpoint, test/recover
Design: RepeatableRayStudyBase
Collection(s): FUNCTIONAL
Type(s): CSVDiffRunApp
- 13.10.16The RepeatableRayStudyBase shall report a useful warning when rays are to be replicated but claiming is disabled.
Specification(s): replicated_no_claim
Design: RepeatableRayStudyBase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.17The RepeatableRayStudyBase shall return a useful error when a ray is added with a non-unique ID.
Specification(s): non_unique_id_error
Design: RepeatableRayStudyBase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.18The RepeatableRayStudyBase shall return a useful error with replicated ray functionality when
- additional rays are created in a non-replicated manner on a subset of processors,
- a ray exists with a non-replicated ID on a processor,
- a non-replicated ray exists on a processor,
- and a ray is created with starting element information when it should not.
Specification(s): replicated_errors/additional, replicated_errors/non_replicated_id, replicated_errors/non_replicated, replicated_errors/starting_elem_set
Design: RepeatableRayStudyBase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- 13.10.19The RepeatableRayStudyBase shall return a useful error after defining rays when
- no rays were defined or
- a null ray was defined.
Specification(s): define_errors/no_rays, define_errors/null_ray
Design: RepeatableRayStudyBase
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: RayTracingAngularQuadrature
- 13.11.1The system shall provide a reasonable error when using angular quadrature for ray tracing and
- the provided polar order is non-positive
- the provided azimuthal order is non-positive
- the minimum polar cosine is greater than the maximum polar cosine
- the minimum polar cosine is less than negative one
- the maximum polar cosine is greater than one
- the dimension is less than two
- the Gauss-Legendre order is non-positive
- an invalid direction index is requested
- an orthonormal vector is requested from a vector that has a zero norm
Specification(s): errors/non_positive_polar_order, errors/non_positive_azimuthal_order, errors/mu_min_larger, errors/mu_min_too_small, errors/mu_max_too_big, errors/dim1, errors/non_positive_gauss_legendre_order, errors/check_direction, errors/orthonormal_vector_zero
Design: RayTracingAngularQuadrature
Issue(s): #16028
Collection(s): FAILURE_ANALYSISFUNCTIONAL
Type(s): RunException
- ray_tracing: PerProcessorRayTracingResultsVectorPostprocessor
- 13.12.1The system shall support the output of information pretaining to the tracing of rays on a per-processor basis.
Specification(s): test
Design: PerProcessorRayTracingResultsVectorPostprocessor
Issue(s): #16028
Collection(s): FUNCTIONAL
Type(s): RunApp