Ray Tracing System Requirements Specification

System Purpose

The MOOSE is a tool for solving complex coupled Multiphysics equations using the finite element method. MOOSE uses an object-oriented design to abstract data structure management, parallelism, threading and compiling while providing an easy to use interface targeted at engineers that may not have a lot of software development experience. MOOSE will require extreme scalability and flexibility when compared to other FEM frameworks. For instance, MOOSE needs the ability to run extremely complex material models, or even third-party applications within a parallel simulation without sacrificing parallelism. This capability is in contrast to what is often seen in commercial packages, where custom material models can limit the parallel scalability, forcing serial runs in the most severe cases. When comparing high-end capabilities, many MOOSE competitors target modest-sized clusters with just a few thousand processing cores. MOOSE, however, will be required to routinely executed on much larger clusters with scalability to clusters available in the top 500 systems (top500.org). MOOSE will also be targeted at smaller systems such as high-end laptop computers.

The design goal of MOOSE is to give developers ultimate control over their physical models and applications. Designing new models or solving completely new classes of problems will be accomplished by writing standard C++ source code within the framework's class hierarchy. Scientists and engineers will be free to implement completely new algorithms using pieces of the framework where possible, and extending the framework's capabilities where it makes sense to do so. Commercial applications do not have this capability, and instead opt for either a more rigid parameter system or a limited application-specific metalanguage.

System Scope

MOOSE's scope is to provide a set of interfaces for building FEM simulations. Abstractions to all underlying libraries are provided.

Solving coupled problems where competing physical phenomena impact one and other in a significant nonlinear fashion represents a serious challenge to several solution strategies. Small perturbations in strongly-coupled parameters often have very large adverse effects on convergence behavior. These adverse effects are compounded as additional physics are added to a model. To overcome these challenges, MOOSE employs three distinct yet compatible systems for solving these types of problems.

First, an advanced numerical technique called the JFNK method is employed to solve the most fully-coupled physics in an accurate, consistent way. An example of this would be the effect of temperature on the expansion or contraction of a material. While the JFNK numerical method is very effective at solving fully-coupled equations, it can also be computationally expensive. Plus, not all physical phenomena in a given model are truly coupled to one another. For instance, in a reactor, the speed of the coolant flow may not have any direct effect on the complex chemical reactions taking place inside the fuel rods. We call such models "loosely-coupled". A robust, scalable system must strike the proper balance between the various modeling strategies to avoid performing unnecessary computations or incorrectly predicting behavior in situations such as these.

MOOSE's Multiapp system will allow modelers to group physics into logical categories where MOOSE can solve some groups fully-coupled and others loosely-coupled. The Multiapp system goes even further by also supporting a "tightly-coupled" strategy, which falls somewhere between the "fully-coupled" and "loosely-coupled" approaches. Several sets of physics can then be linked together into logical hierarchies using any one of these coupling strategies, allowing for several potential solution strategies. For instance, a complex nuclear reactor model might consist of several tightly-coupled systems of fully-coupled equations.

Finally, MOOSE's Transfers system ties all of the physics groups contained within the Multiapp system together and allows for full control over the flow of information among the various groups. This capability bridges physical phenomena from several different complementary scales simultaneously. When these three MOOSE systems are combined, myriad coupling combinations are possible. In all cases, the MOOSE framework handles the parallel communication, input, output and execution of the underlying simulation. By handling these computer science tasks, the MOOSE framework keeps modelers focused on doing research.

MOOSE innovates by building advanced simulation capabilities on top of the very best available software technologies in a way that makes them widely accessible for innovative research. MOOSE is equally capable of solving small models on common laptops and the very biggest FEM models ever attempted—all without any major changes to configuration or source code. Since its inception, the MOOSE project has focused on both developer and computational efficiency. Improved developer efficiency is achieved by leveraging existing algorithms and technologies from several leading open-source packages. Additionally, MOOSE uses several complementary parallel technologies (both the distributed-memory message passing paradigm and shared-memory thread-based approaches are used) to lay an efficient computational foundation for development. Using existing open technologies in this manner helps the developers reduce the scope of the project and keeps the size of the MOOSE code base maintainable. This approach provides users with state-of-the-art finite element and solver technology as a basis for the advanced coupling and solution strategies mentioned previously.

MOOSE's developers work openly with other package developers to make sure that cutting-edge technologies are available through MOOSE, providing researchers with competitive research opportunities. MOOSE maintains a set of objects that hide parallel interfaces while exposing advanced spatial and temporal coupling algorithms in the framework. This accessible approach places developmental technology into the hands of scientists and engineers, which can speed the pace of scientific discovery.

System Context

MOOSE is a command-line driven application. This is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all of the usage of the software is through any standard terminal program generally available on all supported operating systems. Similarly, for the purpose of interacting through the software, there is only a single user, "the user", which interacts with the software through the command-line. MOOSE does not maintain any back-end database or interact with any system daemons. It is a executable, which may be launched from the command line and writes out various result files as it runs.

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

System Functions

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

User Characteristics

• Framework Developers: These are the core developers of the framework. They will be responsible for following and enforcing the appropriate software development standards. They will be responsible for designing, implementing and maintaining the software.

• Developers: A Scientist or Engineer that utilizes the framework to build his or her own application. This user will typically have a background in modeling and simulation techniques and/or numerical analysis but may only have a limited skill-set when it comes to object-oriented coding and the C++ language. This is our primary focus group. In many cases these developers will be encouraged to give their code back to the framework maintainers.

• Analysts: These are users that will run the code and perform various analysis on the simulations they perform. These users may interact with developers of the system requesting new features and reporting bugs found and will typically make heavy use of the input file format.

Assumptions and Dependencies

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

Definitions

- Verification: (1) The process of: evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (2) Formal proof of program correctness (e.g., requirements, design, implementation reviews, system tests) (24765:2010(E), 2010).

Acronyms

Functional Requirements

• ray_tracing: Actions
• 13.1.1The system shall throw an error when adding a RayBC and the provided RayTracingStudy
  1. could not be found
  2. or is not a RayTracingStudy.
• 13.1.2The system shall throw an error when adding a RayBC and RayTracingStudy was not provided
  1. and multiple studies were found
  2. or when no studies were found.
• 13.1.3The system shall throw an error when adding a RayKernel and the provided RayTracingStudy
  1. could not be found
  2. or is not a RayTracingStudy.
• 13.1.4The system shall throw an error when adding a RayKernel and RayTracingStudy was not provided
  1. and multiple studies were found
  2. or when no studies were found.

• ray_tracing: Base
• 13.2.1A RayTracingObject shall return a useful error when
  1. the study is provided via param and is of the wrong type
  2. the study is provided by default and is of the wrong type

• ray_tracing: Coord Type
• 13.3.1The system shall support line integrals in the
  1. rz coordinate system
  2. and in the rspherical coordinate system.

• ray_tracing: Outputs
• 13.4.1The system shall support the mesh output of traced rays on meshes of element types
  1. QUAD4,
  2. TRI3,
  3. HEX8, and
  4. TET4.
• 13.4.2The system shall support the mesh output of traced rays using the Nemesis format.
• 13.4.3The system shall support the mesh output of traced rays using the fewest segments possible to represent the trace in
  1. Exodus format and
  2. in Nemesis format.
• 13.4.4The sytem shall support the output of ray data when outputting rays in a mesh format using
  1. exodus and
  2. nemesis formats.
• 13.4.5The system shall report an error when ouputting rays in a mesh format when
  1. ray data is requested to be output but it is not cached,
  2. aux data is requested to be output but it is not cached,
  3. both nodal and non-nodal data is requested to be output,
  4. and when nodal data is requested to be output but segment-wise information is not cached.
• 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.

• ray_tracing: Postprocessors
• 13.5.1The system shall support the ability to output the data stored on a ray.
• 13.5.2The system shall report an error when ouputting a single data value stored on a ray when
  1. the RayTracingStudy does not support accessing rays by name,
  2. the RayTracingStudy does not support the banking of rays on completion,
  3. the named ray was not found,
  4. the named ray data was not found,
  5. the named ray aux data was not found,
  6. the ray with the given id was not found,
  7. neither an ID or name was provided, and
  8. both an ID and name was provided.
• 13.5.3The system shall report an error when sampling the integrated value by a ray and
  1. the provided IntegralRayKernel is not an IntegralRayKernel,
  2. the provided IntegralRayKernel was not found,
  3. a Ray with the given name was not found,
  4. the provided study does not support Ray registration,
  5. or the provided study does not support Ray banking.
• 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.

• ray_tracing: Raybcs
• 13.6.1The system shall support the dependency resolution of RayBCs.
• 13.6.2The system shall throw a reasonable error when adding a dependency for a RayBC that does not exist.
• 13.6.3The system shall report an error when changing a ray direction within a RayBC when
  1. the ray was set to not continue by another RayBC,
  2. the ray already had its direction changed,
  3. the end point of the ray was set upon generation,
  4. and when the direction is changed to the zero vector.
• 13.6.4The system shall support the specular reflection of rays on a boundary.
• 13.6.5The system shall report a reasonable warning when using an approximation to reflect a ray on a side that is not planar.

• ray_tracing: Raykernels
• 13.7.1The system shall throw a reasonable error if an ADRayKernel
  1. is used with a coordinate system other than xyz or
  2. is used in an explicit manner.
• 13.7.2The system shall throw a reasonable error if a non-supported auxiliary variable is used with a ray aux kernel.
• 13.7.3The system shall support the coupling of variables on rays that contribute to the residual and Jacobian.
• 13.7.4The system shall be able to produce the exact Jacobian with coupled variables on rays.
• 13.7.5The system shall support the coupling of variables using automatic differentiation on rays that contribute to the residual and Jacobian.
• 13.7.6The system shall be able to produce the exact Jacobian using automatic differentiation on rays.
• 13.7.7The system shall support the dependency resolution of RayKernels.
• 13.7.8The system shall throw a reasonable error when adding a dependency for a RayKernel that does not exist.
• 13.7.9The system shall report an error when changing a ray start and/or direction within a RayKernel when
  1. the ray was set to not continue by another RayKernel,
  2. the ray was set to not continue by another RayKernel and it is at its end point,
  3. the ray's trajectory was already changed,
  4. the ray's end point has been set,
  5. the ray's start point is not within the current element, and
  6. when the ray's new direction is set to the zero vector.
• 13.7.10The system shall provide the ability to compute the integral of a Function along a line.
• 13.7.11The system shall provide the ability to compute the average value of a Function along a line.
• 13.7.12The system shall provide an ability to produce a source term along a line.
• 13.7.13The system shall provide an ability to solve a 2D diffusion problem with a line source term, with
  1. finite elements
  2. and finite volumes.
• 13.7.14The system shall provide the ability to compute the integral of a material property along a line.
• 13.7.15The system shall provide the ability to compute the average value of a material property along a line.
• 13.7.16The system shall be able to store the distance traversed by a ray in each element in an auxiliary field.
• 13.7.17The system shall throw a reasonable error if a RayKernel
  1. is utilized with a coordinate system other than xyz or
  2. if the execute flag for the associated ray study is not set correctly to use the RayKernel.
• 13.7.18The system shall provide the ability to compute the integral of a variable along a line.
• 13.7.19The system shall provide the ability to compute the average value of a variable along a line.
• 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.
• 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.
• 13.7.22The system shall provide the ability to compute the line integral of a variable for a 2D diffusion problem, with
  1. finite elements
  2. and finite volumes.

• ray_tracing: Raytracing
• 13.8.1The system shall support the console output of information pertaining to a Ray.
• 13.8.2The system shall provide a method for determining the equality of rays
• 13.8.3The system shall report a reasonable error from a ray when
  1. checking if a ray is at its end point without an end point being set
  2. retrieving a ray's end point when its end point has not been set
  3. setting a ray's start point that has already been set
  4. setting a ray's starting direction multiple times without clearing it
  5. setting a ray's start point that is not contained within the mesh bounding box
  6. setting a ray's starting incoming side without setting its starting element
  7. setting a ray's starting incoming side to an invalid side
  8. setting a ray's starting incoming side to one that does not contain the starting point
  9. setting a ray's starting point to a point that is not contained within a given starting element
  10. setting a ray's starting direction before setting its starting information,
  11. setting a ray's starting direction to the zero vector
  12. setting a ray's end point before setting its start point
  13. setting a ray's end point to the same as its start point
  14. setting a ray's end point and starting direction
  15. setting a ray's max distance after setting its end point
  16. setting a ray's end point after setting its max distance
  17. setting a ray's end point to a point that is not within the mesh bounding box
  18. setting a ray's starting maximum distance before setting its start information
  19. setting a ray's starting maximum distance to a negative value
  20. setting the starting element for a ray to an inactive element

• ray_tracing: Traceray
• 13.9.1The system shall be able to trace rays in a mesh that utilizes adaptiviy with the element types
  1. QUAD4,
  2. TRI3,
  3. HEX8,
  4. and EDGE2.
• 13.9.2The system shall support the use of side normals to cull potential exiting sides within ray tracing for
  1. two-dimensional meshes
  2. and for three-dimensional meshes.
• 13.9.3The system shall be able to trace rays within EDGE2 elements.
• 13.9.4The system shall be able to trace rays within EDGE3 elements.
• 13.9.5The system shall be able to trace rays within EDGE4 elements.
• 13.9.6The system shall be able to trace rays within planar HEX20 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.7The system shall be able to trace rays within planar HEX27 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.8The system shall be able to trace rays within planar HEX8 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.9The system shall support the ending of traced rays on internal sidesets in
  1. one-dimensional meshes,
  2. two-dimensional meshes,
  3. and three-dimensional meshes.
• 13.9.10The system shall support the specular reflection of traced rays on internal sidesets in
  1. one-dimensional meshes,
  2. two-dimensional meshes,
  3. and three-dimensional meshes.
• 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.
• 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.
• 13.9.13The system shall be able to trace rays on 3D meshes that have nonplanar faces.
• 13.9.14The system shall by default warn that tracing on non-planar faces is an approximation.
• 13.9.15The system shall be able to trace rays within planar PRISM15 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.16The system shall be able to trace rays within planar PRISM18 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.17The system shall be able to trace rays within planar PRISM6 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.18The system shall be able to trace rays within planar PYRAMID13 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.19The system shall be able to trace rays within planar PYRAMID14 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.20The system shall be able to trace rays within planar PYRAMID5 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.21The system shall be able to trace rays within planar QUAD4 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from boundary sides centroids using an angular quadrature,
  5. and from boundary element centroids using an angular quadrature.
• 13.9.22The system shall be able to trace rays within planar QUAD8 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from boundary sides centroids using an angular quadrature,
  5. and from boundary element centroids using an angular quadrature.
• 13.9.23The system shall be able to trace rays within planar QUAD9 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from boundary sides centroids using an angular quadrature,
  5. and from boundary element centroids using an angular quadrature.
• 13.9.24The system shall report an error when a ray hits a boundary during tracing and
  1. the boundary does not have any RayBCs
  2. and then the boundary does not have any RayBCs that change the trajectory of the ray or end the ray.
• 13.9.25The system shall be able to trace rays within planar TET10 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.26The system shall be able to trace rays within planar TET4 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from the centroids of boundary edges in the direction of all other edge centroids in the same element,
  5. from boundary sides centroids using an angular quadrature,
  6. and from boundary element centroids using an angular quadrature.
• 13.9.27The system shall be able to trace rays within planar TRI3 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from boundary sides centroids using an angular quadrature,
  5. and from boundary element centroids using an angular quadrature.
• 13.9.28The system shall be able to trace rays within planar TRI6 elements
  1. from boundary vertices on boundary sides in the direction of the vertices on the other side of the same boundary element,
  2. from the centroids of boundary sides in the direction of all other vertices in the same boundary element,
  3. from the centroids of all boundary sides to the centroids of all other boundary elements,
  4. from boundary sides centroids using an angular quadrature,
  5. and from boundary element centroids using an angular quadrature.
• 13.9.29The system shall support not setting the incoming side at the beginning of a trace.

• ray_tracing: Userobjects
• 13.10.1The system shall be able to generate rays emitting from a point in a cone using angular quadrature in
  1. two-dimensional meshes
  2. and in three-dimensional meshes.
• 13.10.2The ConeRayStudy shall report a useful error when
  1. the provided directions are inconsistent in size
  2. the provided scaling factors are inconsistent in size
  3. the provided half cone angles are inconsistent in size
  4. the provided half cone angles are not valid angles
  5. the provided polar quadrature orders are inconsistent in size
  6. the provided azimuthal quadrature orders are inconsistent in size
  7. it is run with an invalid mesh dimension
• 13.10.3The system shall be able to create additional rays during tracing with RayBCs in
  1. two-dimensional meshes
  2. and in three-dimensional meshes.
• 13.10.4The system shall be able to trace rays using a
  1. last in, first out buffer
  2. and with a circular buffer.
• 13.10.5The RayTracingStudy shall return a useful error when
  1. the same ray is added to be traced multiple times,
  2. when local rays that have the same ID are added to be traced,
  3. when rays that have the same ID on different processors are added to be traced,
  4. when the domain is not covered with ray kernels,
  5. when ray names are provided to a ray tracing object and the study does not register ray names,
  6. when a ray name is provided to a ray tracing object and said name is not registered to a ray,
  7. when the study is set to execute with residual kernels and non-residual kernels,
  8. when the study is set to execute with residual kernels and an eigenvalue executioner,
  9. when the trajectory of a ray is changed after it has started tracing,
  10. when a ray's counters are reset when not generating rays
  11. when tracing in a mesh with adaptivity and an unsupported element type
  12. when tracing in a mesh when the average subdomain hmax is a poor approximation due to stretched elements
  13. when ray data is registered too late
  14. when ray data is registered with the same name across systems
  15. when requesting a ray data index for an invalid name
  16. when requesting a ray data name for an invalid index
  17. when requesting ray kernels before they are setup
  18. when requesting ray bcs before they are setup
  19. when obtaining the ray bank when banking is disabled
  20. when obtaining the ray bank when it is not available
  21. when registering a ray when ray registration is disabled
  22. when getting a registered ray ID when ray registration is disabled
  23. when getting a registered ray name when ray registration is disabled
  24. when requesting a registered ray ID for a ray that is not registered
  25. when requesting a registered ray name for a ray that is not registered
  26. when reserving space in the ray buffer outside of registration, and
  27. when requesting a subdomain hmax for an invalid subdomain
  28. building an element extrema edge for invalid vertices
  29. requesting cached element normals when element normal caching has not been setup
  30. getting the index of ray data when aux data with the same name exists
  31. getting the index of ray aux data when data with the same name exists
  32. registering a ray more than once with the same name
• 13.10.6The system shall be able to change the trajectory of rays during tracing within RayKernels.
• 13.10.7The system shall be able to create additional rays during tracing within RayKernels in
  1. two-dimensional meshes
  2. and in three-dimensional meshes.
• 13.10.8The system shall support the tracing of rays using
  1. an asynchronous method,
  2. a bulk-synchronous method,
  3. and the harm method.
• 13.10.9The system shall support the tracing of rays across multiple subdomains.
• 13.10.10The system shall support the storage and manipulation of data and auxiliary data on a ray when
  1. sizing the Ray data on acquire
  2. and when not sizing the Ray data on acquire.
• 13.10.11The system shall support the re-use of traced rays.
• 13.10.12The system shall support the failure of a trace gracefully via a warning.
• 13.10.13The system shall support ending rays by a user-set maximum distance.
• 13.10.14The system shall report an error when utilizing the repeatable ray study when
  1. both directions and points are provided,
  2. neither directions and points are provided,
  3. the number of start points provided is inconsistent,
  4. the number of directions provided is inconsistent,
  5. both end points and maximum distances are provided,
  6. the number of maximum distances provided is inconsistent,
  7. the provided maximum distance is non-positive,
  8. the number of end points provided is inconsistent,
  9. the initial data size is inconsistent with the number of rays,
  10. the initial data size is inconsistent with the provided data names,
  11. initial data is provided but data names are not provided,
  12. the initial aux data size is inconsistent with the number of rays,
  13. the initial aux data size is inconsistent with the provided aux data names,
  14. and aux initial data is provided but aux data names are not provided.
• 13.10.15The RepeatableRayStudyBase shall support the
  1. outputting of checkpoint files and
  2. shall be capable of restarting from the output data.
• 13.10.16The RepeatableRayStudyBase shall report a useful warning when rays are to be replicated but claiming is disabled.
• 13.10.17The RepeatableRayStudyBase shall return a useful error when a ray is added with a non-unique ID.
• 13.10.18The RepeatableRayStudyBase shall return a useful error with replicated ray functionality when
  1. additional rays are created in a non-replicated manner on a subset of processors,
  2. a ray exists with a non-replicated ID on a processor,
  3. a non-replicated ray exists on a processor,
  4. and a ray is created with starting element information when it should not.
• 13.10.19The RepeatableRayStudyBase shall return a useful error after defining rays when
  1. no rays were defined or
  2. a null ray was defined.

• ray_tracing: Utils
• 13.11.1The system shall provide a reasonable error when using angular quadrature for ray tracing and
  1. the provided polar order is non-positive
  2. the provided azimuthal order is non-positive
  3. the minimum polar cosine is greater than the maximum polar cosine
  4. the minimum polar cosine is less than negative one
  5. the maximum polar cosine is greater than one
  6. the dimension is less than two
  7. the Gauss-Legendre order is non-positive
  8. an invalid direction index is requested
  9. an orthonormal vector is requested from a vector that has a zero norm

• ray_tracing: Vector Postprocessors
• 13.12.1The system shall support the output of information pretaining to the tracing of rays on a per-processor basis.

Usability Requirements

Performace Requirements

System Interfaces

System Operations

System Modes and States

MOOSE applications normally run in normal execution mode when an input file is supplied. However there are a few other modes that can be triggered with various command line flags as indicated here:

Phyisical Characteristics

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

Environmental Conditions

Not Applicable

System Security

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

Information Management

The core framework in its entirety will be made publicly available on an appropriate repository hosting site. Backups and security services will be provided by the hosting service.

Polices and Regulations

MOOSE-based applications must comply with all export control restrictions.

System Life Cycle Sustainment

MOOSE-based development follows various agile methods. The system is continuously built and deployed in a piecemeal fashion since objects within the system are more or less independent. Every new object requires a test, which in turn requires an associated requirement and design description. Some MOOSE-based development teams follow the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing MOOSE source code. However, some MOOSE-based applications maybe be export controlled in which case all export control restrictions must be adhered to when packaging and shipping media.