MOOSE System Requirements Specification

Introduction

System Purpose

The Multiphysics Object Oriented Simulation Environment (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 Finite Element Method (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 Jacobian-Free Newton-Krylov (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 Overview

System Context

error:Missing Template Item "system-context"help_outline

Describe at a general level the major elements of the system including user roles and how they interact. The system overview includes appropriate diagrams and narrative to provide the context of the system, defining all significant interfaces crossing the system’s boundaries.

System Functions

error:Missing Template Item "system-functions"help_outline

Provide a summary of the major use cases or functions, conditions, and constraints. For example, a specification for an accounting program may use this part to address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the product. Note that for the sake of clarity:

  1. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time.

  2. Textual or graphical methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among variables.

Example

Use Case: Submit Timesheet

Brief Description: The Employee enters hourly data for the week and submits for approval.

Initial Step-By-Step Description:

Before entering their timesheet, the employee must select the "ETS" or "ETS with Login Prompt" menu option from Nucleus and be logged into the Human Resource application.

  1. The system presents the timesheet data entry interface to the employee with any previously saved data.

  2. The employee enters charge No., TRC, and hours for each work day.

  3. The employee may click “Save for Later,” exit, and return at a later time to complete timesheet OR the employee may click “Submit” to submit timesheet.

  4. Following submittal, the system verifies the information (e.g., 40 hours). If information is not correct or complete, the employee will receive a warning; otherwise, the employee will be provided a confirmation that the time sheet was submitted with date and time.

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 software should be designed with the fewest possible constraints. Ideally the software should run on a wide variety of evolving hardware so it should follow well-adopted standards and guidelines. The software should run on any Portable Operating System Interface (POSIX) compliant system. The software will also make use FEM and numerical libraries that run on POSIX systems as well. The main interface for the software will be command line based with no assumptions requiring advanced terminal capabilities such as coloring and line control.

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[BibTeX]
  2. D. F. Griffiths. The `No Boundary Condition' outflow boundary condition. International Journal of Numerical Methods in Fluids, 24(4):393–411, 1997. URL: http://tinyurl.com/y77au2k.[BibTeX]
  3. ASME NQA-1. ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications. first edition, August 31 2009.[BibTeX]

Definitions and Acronyms

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

AcronymDescription
MOOSEMultiphysics Object Oriented Simulation Environment
FEMFinite Element Method
POSIXPortable Operating System Interface
JFNKJacobian-Free Newton-Krylov

System Requirements

under construction

The creation of the requirements for MOOSE is an ongoing progress. The Functional Requirements are being generated from source code and soon all requirements should follow this format.

  • A POSIX compliant Unix including the two most recent versions of MacOS and most current versions of Linux.

  • 4 GB of RAM for optimized compilation (8 GB for debug compilation), 2 GB per core execution

  • 100 GB disk space

  • C++11 compatible compiler (GCC, Clang, or Intel)

  • Python 2.6+

  • Git

Functional Requirements

  • Time Integrators
  • F1.1

    Multi-stage time integrators shall check convergence for all stages

  • Dirackernels
  • F2.1

    The DiracKernel system shall allow for source locations to be set by a coupled UserObject.

  • F2.2

    The DiracKernel system shall allow material properties to be utilized.

  • F2.3

    DiracKernel objects shall report an error if a material property from a previous timestep is requested.

  • F2.4

    DiracKernel objects shall report an error if a material property from two previous timesteps is requested.

  • F2.5

    MOOSE shall support the coupling of scalar aux variables for the purpose of sharing data and reporting values.

  • F2.6

    The DiracKernel system shall allow for duplicate source locations to be defined.

  • F2.7

    DiracKernel objects shall support the computation of off diagonal Jacobian terms.

  • F2.8

    The DiracKernel system shall support source location caching using element ids.

  • F2.9

    The DiracKernel system shall report an error if a location does not correspond with the supplied element id.

  • F2.10

    The DiracKernel system shall support source location caching using element ids with uniform mesh refinement.

  • F2.11

    The DiracKernel system shall support source location caching using element ids with mesh refinement.

  • F2.12

    The DiracKernel system shall support source location caching using element ids with a displaced mesh.

  • F2.13

    MOOSE shall have the ability to set the value of point source from a function.

  • F2.14

    MOOSE shall support a constant point source implemented as a Dirac function in 2D.

  • F2.15

    MOOSE shall support a constant point source implemented as a Dirac function in 1D.

  • F2.16

    MOOSE shall support a constant point source implemented as a Dirac function in 3D.

  • Variables
  • F3.1

    Coupleable shall provide an interface that allows providing default values for a vector of coupled variables

  • F3.2

    Coupleable shall provide an interface that allows providing default values for a vector of coupled variables

  • F3.3

    The system shall report an error when users couple constant values and variables together

  • F3.4

    The system shall report an error when requested default vector value is out of range.

  • F3.5

    The system shall report an error when requested default vector value is out of range.

  • Misc
  • F4.1

    The compiled application shall be capable of returning the name used for registering objects.

  • F4.2

    The system shall report an error if users try to get nodal values of non-nodal variables.

  • F4.3

    The system shall report an error if users try to get old nodal values of non-nodal variables.

  • F4.4

    The system shall report an error if users try to get older nodal values of non-nodal variables.

  • F4.5

    The system shall have an integrity check that ensures an Executioner object exists in the system.

  • F4.6

    The maximum number of degrees of freedom for a single variable on a 1D EDGE2 elem shall be 2

  • F4.7

    The maximum number of degrees of freedom for a single variable on a 2D QUAD4 elem shall be 4

  • F4.8

    The maximum number of degrees of freedom for a single variable on a 2D QUAD9 elem shall be 9

  • F4.9

    The maximum number of degrees of freedom for a single variable on a 2D TRI3 elem shall be 3

  • F4.10

    The maximum number of degrees of freedom for a single variable on a 2D TRI6 elem shall be 6

  • F4.11

    The maximum number of degrees of freedom for a single variable on a 3D HEX8 elem shall be 8

  • Actions
  • F5.1

    The system shall be capable of reporting Action object dependencies.

  • F5.2

    The system shall be capable of reporting Action object task information.

  • F5.3

    The Action system shall allow the creation of Action objects with multiple tasks.

  • F5.4

    The Action system shall allow Action objects to create other Action objects.

  • F5.5

    The Postprocessor data shall be initialized by the SetupPostprocessorDataAction object and the PostprocessorInterface::hasPostprocessor shall return true when called with a defined postprocessor name.

  • F5.6

    The system PostprocessorInterface::hasPostprocessor method shall return false when called with an undefined postprocessor name.

  • F5.7

    The system shall be able to retrieve other Action objects from within another Action object.

  • Controls
  • F6.1

    The Control system shall be capable of activating or deactivating DGKernel objects with time.

  • F6.2

    The Control system shall support explicitly defined dependencies.

  • F6.3

    The Control system shall support the modification of a single parameter using the objects base class name, object name, and parameter name.

  • F6.4

    The Control system shall support the modification of multiple parameters using the objects base class and the parameter name.

  • F6.5

    The Control system shall be capable of activating or deactivating AuxKernel objects with time.

  • F6.6

    The Control system shall be capable of activating or deactivating NodalBC objects with time.

  • F6.7

    The Control system shall be capable of activating or deactivating IntegratedBC objects with time.

  • F6.8

    The Control system shall be capable of activating or deactivating MultiApp objects with time.

  • F6.9

    The Control system shall allow multiple parameters to be changed by the parameter name alone using input syntax format.

  • F6.10

    The Control system shall allow multiple parameters to be changed given the object and parameter names using input syntax format.

  • F6.11

    The Control system shall allow for a single parameter to be changes given the input syntax, object name, and parameter name.

  • F6.12

    The Control system shall allow for multiple parameters to be changed given input syntax and a parameter name.

  • F6.13

    The Control system shall be capable of activating or deactivating Constraint objects with time.

  • F6.14

    The MOOSE control system shall allow parameters from differing objects, with differing names to be associated and changed together.

  • F6.15

    The MOOSE control system shall allow parameters from objects to be assigned aliases for the purpose of changing the value.

  • F6.16

    The Control system shall allow a scalar parameter to be controlled with a function.

  • F6.17

    The Control system shall allow multiple scalar parameters to be controlled with a function.

  • F6.18

    The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given identical start end times.

  • F6.19

    The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given differing start end times.

  • F6.20

    The Control system shall be capable of activating or deactivating NodalKernel objects with time.

  • F6.21

    The Control system shall be capable of activating or deactivating Transfer objects with time.

  • F6.22

    The Control system shall be capable of activating or deactivating Kernel objects with time.

  • F6.23

    MOOSE shall support the disabling an object using an input parameter.

  • F6.24

    MOOSE shall support the enabling an object using an input parameter.

  • F6.25

    The Control system shall be capable of activating or deactivating Damper objects with time.

  • F6.26

    The Control system shall be capable of activating or deactivating UserObject objects with time.

  • F6.27

    The Control system shall include a means to output information regarding the controlled parameters.

  • F6.28

    The Control system shall include a means to output information regarding the controlled parameters, including only showing information regarding a parameter if it has changed since the last output.

  • F6.29

    MOOSE shall include a command line flag for displaying controllable parameter information.

  • F6.30

    The Control system shall include a means to output information regarding the objects with controllable parameters.

  • F6.31

    The Control system shall be capable of activating or deactivating DiracKernel objects with time.

  • F6.32

    The TimePeriod object shall error when used with a steady state problem.

  • F6.33

    The TimePeriod object shall error when the start and end time parameters are not the same length.

  • F6.34

    The TimePeriod object shall error when start and end time parameters differ in length than the supplied object list.

  • F6.35

    The TimePeriod object shall error when a list of objects to control is omitted.

  • F6.36

    The TimePeriod object shall error when start time is greater than the end time.

  • F6.37

    The Control system shall error if an attempt to alter a non-controllable parameter is performed.

  • F6.38

    The Control system shall error if multiple controllable parameters exists, but only a single parameter is expected to be controlled.

  • F6.39

    The Control system shall error if an unknown parameter is supplied for control.

  • F6.40

    The Control system shall error if a thread id greater than the number of threads available is supplied when retrieving a Control object.

  • F6.41

    The Control system shall error if an attempt is made to disable the Executioner.

  • F6.42

    The Control system shall error if an invalid control name is supplied to the Control dependency resolution procedure.

  • F6.43

    The Control system shall allow multiple parameters to be changed by the parameter name alone using a tag.

  • F6.44

    The Control system shall allow multiple parameters to be changed given a tag and parameter names, given a tag assigned across input blocks.

  • F6.45

    The Control system shall allow for a single parameter to be changes given a tag and parameter name, given a tag assigned to a single object.

  • F6.46

    The Control system shall allow for multiple parameters to be changed given a tag and a parameter name, given a tag assigned within a single input block on multiple objects.

  • Adaptivity
  • F7.1

    The Adaptivity system shall be capable of restricting the element refinement level.

  • F7.2

    The Adaptivity system shall allow for Marker objects to be recomputed with each adaptivity cycle.

  • F7.3

    The Adaptivity system shall allow for multiple mesh adaptivity steps per timestep.

  • F7.4

    The Adaptivity system shall support marking elements for refinement during initial setup using a different marker than used during execution.

  • F7.5

    The Adaptivity system shall support mesh adaptivity during initial setup.

  • Executioners
  • F8.1

    MOOSE shall support adaptive solves for steady-state execution.

  • F8.2

    MOOSE shall be able to detect steady state conditions during execution.

  • F8.3

    MOOSE shall be capable of solving a steady state diffusion problem.

  • F8.4

    MOOSE shall be capable of solving a transient diffusion problem.

  • F8.5

    Executioner objects shall be capable of coupling to Postprocessor values.

  • F8.6

    MOOSE shall support controlling what objects are executing based on start and end times.

  • F8.7

    MOOSE shall compute the solution of rank-deficient linear equations if the right hand side is within the range of the linear operator.

  • F8.8

    MOOSE shall compute the solution of rank-deficient linear equations if the right hand side has components that are orthogonal to the range of the linear operator.

  • F8.9

    The Executioner system shall support the ability to create custom objects with custom execution callbacks.

  • F8.10

    MOOSE shall support explicit definition of execution times.

  • F8.11

    MOOSE shall support output using a time interval.

  • F8.12

    MOOSE shall support solving an Eigen value problem using the inverse power method.

  • F8.13

    MOOSE shall support solving an Eigen value problem using Newton's method.

  • F8.14

    MOOSE shall support solving an Eigen value problem using Newton's method in parallel.

  • F8.15

    MOOSE shall support the use of material properties during an Eigen problem solve.

  • F8.16

    MOOSE shall be capable of solving a diffusion problem using an Eigen value solver.

  • F8.17

    MOOSE shall be capable of solving a nonlinear diffusion problem using an Eigen value solver.

  • F8.18

    MOOSE shall be capable of solving a coupled nonlinear diffusion problem using an Eigen value solver.

  • F8.19

    The EigenKernel object shall be capable of using coupled variables.

  • F8.20

    The Executioner system shall support the creation of custom objects with arbitrary execution flags.

  • Kernels
  • F9.1

    Coupled variable gradient Jacobian entries generated with AD shall be accurate

  • F9.2

    Coupled variable value Jacobian entries generated with AD shall be accurate

  • F9.3

    Jacobian entries generated with AD shall match hand-coded Jacobian entries as measured through save-in values

  • F9.4

    Jacobian entries generated with AD for a simple diffusion problem shall be accurate

  • F9.5

    MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions.

  • F9.6

    MOOSE shall provide an ability to solve a 2D diffusion problem with Neumann boundary conditions.

  • F9.7

    MOOSE shall provide a diffusion kernel that obtains the diffusion coefficient from a material property

  • F9.8

    MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term.

  • F9.9

    MOOSE shall provide a tester that checks hand-coded Jacobian against finite difference Jacobian using -snes_type=test option.

  • F9.10

    MOOSE shall force the solver to take at least one iteration regardless of the initial residual norm when the snes_force_iteration option is specified.

  • F9.11

    MOOSE should not compute an extra residual if the linear solver is used

  • F9.12

    Time kernel requires a transient executioner

  • F9.13

    The kernel can be only assigned to the existing vector tags in the system

  • F9.14

    The kernel can be only assigned to the existing matrix tags in the system

  • Functions
  • F10.1

    The Function object shall support the ability to couple Postprocessor values.

  • F10.2

    MOOSE shall include an InitialCondition object capable of setting values base on a supplied function.

  • F10.3

    The LinearCombinationFunction shall report an error if the parameters listing the functions differs in size than the list of coefficients.

  • F10.4

    The LinearCombinationFunction shall be capable of computing the sum of function values, each multiplied by a scale factor.

  • F10.5

    The LinearCombinationFunction shall be capable of computing the sum of function gradients, each multiplied by a scale factor.

  • F10.6

    The LinearCombinationFunction shall be capable of computing the sum of vector functions, each multiplied by a scale factor.

  • F10.7

    The Function system shall include an object that creates a function based on x- and y-data pairs and returns an explicit value from the supplied data when queried (i.e., linear interpolation is not performed).

  • F10.8

    The Function system shall include the ability to read comma or space separated data and perform linear interpolation using the supplied data.

  • F10.9

    The SolutionFunction object shall be capable of evaluating a solution read from XDA mesh and solution files.

  • F10.10

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file with temporal interpolation.

  • F10.11

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file.

  • F10.12

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the z-axis.

  • F10.13

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the y-axis.

  • F10.14

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 90 degrees about the z-axis and 45 degress about the x-axis.

  • F10.15

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the z-axis for a 2D domain.

  • F10.16

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and scaled by a factor in the x and y directions as well as translated in the x-direction.

  • F10.17

    The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and scaled by a factor of two in the x and y directions.

  • F10.18

    The SolutionFunction object shall error if a variable that does not exist is requested.

  • F10.19

    The 'functions/solution_function/solution_function_grad_p1' test shall create an output for the 'solution_function_grad_p2' test.

  • F10.20

    The SolutionFunction object shall be capable of evaluating the gradient of a solution read from an Exodus file.

  • F10.21

    The Function system shall support the creation of objects that execute a function defined within the input file.

  • F10.22

    The ParsedFunction object shall be capable of defining function within the input file for use with the method of manufactured solutions.

  • F10.23

    The Function system shall support the creation of objects that execute a vector function defined within the input file.

  • F10.24

    The Function system shall support the creation of objects that execute a function defined within the input file that includes a scalar variable.

  • F10.25

    The ParsedFunction object shall support the use of other functions specified by their names in its expression.

  • F10.26

    The ParsedFunction object shall support the use of functions, scalar values and postprocessor values specified by their names in its expression at the same time.

  • F10.27

    The PiecewiseMultilinear object will error if the supplied file fails to open.

  • F10.28

    The PiecewiseMultiInterpolation object shall error if the supplied data is not monotonically increasing.

  • F10.29

    The PiecewiseMultiInterpolation object shall error if the number of requested functions differ than the number available from the file.

  • F10.30

    The PiecewiseMultiInterpolation errors if the axes supplied are not independent.

  • F10.31

    The PiecewiseMultilinear shall error if the axis lines are not located in the supplied data.

  • F10.32

    The PiecewiseMultilinear object shall perform interpolation on a 1D domain.

  • F10.33

    The PiecewiseMultilinear object shall perform interpolation on a 1D domain that compares to an equivalent known function.

  • F10.34

    The PiecewiseMultilinear object shall perform interpolation of time-dependent data.

  • F10.35

    The PiecewiseMultilinear object shall perform interpolation on a 2D domain.

  • F10.36

    The PiecewiseMultilinear object shall perform interpolation on a 2D domain that compares to an equivalent known function.

  • F10.37

    The PiecewiseMultilinear object shall perform constant interpolation on a 2D domain.

  • F10.38

    The PiecewiseMultilinear object shall perform interpolation on a 3D domain with time-dependent data.

  • F10.39

    The Function system shall include a constant function.

  • F10.40

    The Function object shall include a callback executed during each timestep.

  • F10.41

    The VectorPostprocessorFunction shall be capable of linear interpolating data generated by a VectorPostprocessor object.

  • F10.42

    MOOSE shall include the ability to define a function based on a 2D image and initialize a nodal variable.

  • F10.43

    MOOSE shall include the ability to define a function based on a 2D image and initialize a elemental variable.

  • F10.44

    MOOSE shall include the ability to define a function based on a stack of images and initialize a nodal variable.

  • F10.45

    MOOSE shall include the ability to define a function based on a subset stack of images and initialize a nodal variable.

  • F10.46

    The ImageFunction object shall allow the image data to be set as one of two values based on a threshold value.

  • F10.47

    MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data.

  • F10.48

    MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data, in parallel.

  • F10.49

    MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data, in parallel and produce Nemesis output files.

  • F10.50

    The ImageFunction object shall be capable of limiting the supplied data to a single component of the RGB image data.

  • F10.51

    The ImageFunction object shall be capable of shifting and scaling the supplied data.

  • F10.52

    The ImageFunction object shall be capable of operating on domains that are larger than the image size.

  • F10.53

    The ImageFunction object shall be capable of flipping the data along the vertical axis.

  • F10.54

    The ImageFunction object shall be capable of flipping the data along vertical axis and shifting the origin.

  • F10.55

    The ImageFunction object shall be capable of flipping the data along vertical and horizontal axis.

  • F10.56

    The ImageFunction object shall be capable of operating on domains that are smaller than the image size.

  • F10.57

    The ImageMesh object shall be capable of generating a 3D mesh based on a stack of 2D images.

  • F10.58

    The ImageMesh object shall be capable of generating a 2D mesh based on an image.

  • F10.59

    The ImageFunction shift and scale options shall operate independently.

  • F10.60

    The Material system shall support defining properties within the input file that are associated with functions.

  • F10.61

    The Function system shall include the ability to set default values for input parameters expecting a function name.

  • Relationship Managers
  • F11.1

    MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager

  • F11.2

    MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager and using DistributedMesh

  • F11.3

    MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh

  • F11.4

    MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh with 3D

  • F11.5

    MOOSE shall ghost additional neighboring elements without also supplying solution information when a developer registers a RelationshipManager with an optional second argument to restrict functionality

  • F11.6

    MOOSE shall ghost additional neighboring elements without also supplying solution information when a developer registers a RelationshipManager with an optional second argument to restrict functionality in 3D

  • DGKernel Objects
  • F12.1

    MOOSE shall support solving 2D diffusion using the discontinuous Galerkin method.

  • F12.2

    DGKernels shall coexist with stateful material properties

  • F12.3

    The DGCoupledDiffusion object shall compute the correct Jacobian.

  • F12.4

    MOOSE shall support solving 3D diffusion using the discontinuous Galerkin method.

  • F12.5

    Adaptivity shall work with dg kernels as long as stateful properties are not used.

  • F12.6

    The system shall error if the triad of dg kernels, adaptivity, and stateful properties are used together.

  • F12.7

    The DGKernel system shall operate with displaced meshes.

  • F12.8

    MOOSE shall be able to solve the advection diffusion equation using the discontinuous Galerkin method.

  • F12.9

    MOOSE shall compute the correct Jacobian for the advection diffusion equation using the discontinuous Galerkin method.

  • F12.10

    MOOSE shall support solving 1D advection using the discontinous Galerkin method.

  • F12.11

    The DGKernel system shall support restriction to subdomains, in 1D.

  • F12.12

    The DGKernel system shall support restriction to subdomains, in 2D.

  • Checkpoint
  • F13.1

    MOOSE shall support output suitable for restarting an application.

  • F13.2

    MOOSE shall be capable of restarting a simulation from previously exported data.

  • Materials
  • F14.1

    The system shall provide material properties in boundary restricted objects acting on nodal variables.

  • F14.2

    The system shall provide material properties in boundary restricted objects acting on elemental variables.

  • F14.3

    The Jacobian from a material property declared as AD and gotten as AD shall be accurate

  • F14.4

    The Jacobian from a material property declared as regular and gotten as AD shall be inaccurate

  • F14.5

    The Jacobian from a material property declared as AD and gotten as regular shall be inaccurate

  • F14.6

    The Jacobian from a material property declared as regular and gotten as regular shall be inaccurate

  • F14.7

    AD shall work with stateful material properties and the Jacobian shall be beautiful

  • F14.8

    The time evolution of the stateful diffusivity property shall show that AD works with stateful material properties

  • Geomsearch
  • F15.1

    The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable.

  • F15.2

    The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable in 1D.

  • F15.3

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D.

  • F15.4

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using second order elements.

  • F15.5

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

  • F15.6

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

  • F15.7

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D.

  • F15.8

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D with second order elements.

  • F15.9

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D using a tangential tolerance for the distance.

  • F15.10

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 2D using a tangential tolerance for the distance and second order elements.

  • F15.11

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D.

  • F15.12

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D and second order elements.

  • F15.13

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

  • F15.14

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

  • F15.15

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using normal smoothing for the distance.

  • F15.16

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using normal smoothing for the distance and second order elements.

  • F15.17

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using nodal normal based smoothing for the distance.

  • F15.18

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 2D using nodal normal based smoothing for the distance and second order elements.

  • F15.19

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D.

  • F15.20

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using second order elements.

  • F15.21

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance.

  • F15.22

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using a tangential tolerance of for the distance and second order elements.

  • F15.23

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using normal smoothing for the distance.

  • F15.24

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using normal smoothing for the distance and second order elements.

  • F15.25

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using nodal normal based smoothing.

  • F15.26

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 2D using nodal normal based smoothing and second order elements.

  • F15.27

    The 'geomsearch/2d_moving_penetration/restart' shall create the necessary files for testing restart of the PenetrationAux object.

  • F15.28

    The PenetrationAux object shall be capable of restarting from a previous simulation.

  • F15.29

    The PenetrationAux object shall compute the distance between two boundaries in 3D that overlap.

  • F15.30

    The PenetrationAux object shall compute, in parallel, the distance between two boundaries in 3D that overlap.

  • F15.31

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces in 3D.

  • F15.32

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces in 2D with tetrahedron elements.

  • F15.33

    MOOSE shall support a means for updating the geometric search patch dynamically that may be disabled.

  • F15.34

    MOOSE shall support a means for updating the geometric search patch dynamically that automatically determines when an update to the patch shall occur.

  • F15.35

    MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each solve.

  • F15.36

    MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each iteration.

  • F15.37

    The MOOSE penetration locator system shall error if penetration is not detected.

  • F15.38

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces in 2D.

  • F15.39

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces in 2D with triangular elements.

  • F15.40

    MOOSE shall be capable of computing the distance between two disjoint boundaries on a 1D domain.

  • F15.41

    The NearestNodeDistanceAux object shall compute the shortest distance between nodes on two overlapping boundaries using a constant monomial auxiliary variable.

  • F15.42

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D.

  • F15.43

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using second order elements.

  • F15.44

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance.

  • F15.45

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance and second order elements.

  • F15.46

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D.

  • F15.47

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D with second order elements.

  • F15.48

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D using a tangential tolerance for the distance.

  • F15.49

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two parallel, overlapping surfaces of a moving interface in 3D using a tangential tolerance for the distance and second order elements.

  • F15.50

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D.

  • F15.51

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D and second order elements.

  • F15.52

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and convex disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance and second order elements.

  • F15.53

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D.

  • F15.54

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D using second order elements.

  • F15.55

    The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between a flat and concave disjoint surfaces of a moving interface in 3D using a tangential tolerance of for the distance.

  • F15.56

    MOOSE shall be capable of computing the distance as well as transfer data between interior boundaries on a 2D domain.

  • F15.57

    The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries.

  • F15.58

    The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries with adaptivity.

  • F15.59

    The NearestNodeDistanceAux object shall be capable of computing the shortest distance between a boundary and subdomain.

  • InterfaceKernel Objects
  • F16.1

    The InterfaceKernel system shall operate with coupled variables in 2D. This uses a penalty implementation that is optimally convergent.

  • F16.2

    The Jacobian evaluation for InterfaceKernel objects in 2D shall be analytically correct.

  • F16.3

    The finite difference preconditioner shall work in parallel.

  • F16.4

    The InterfaceKernel system shall operate with coupled variables in 3D. This uses a penalty implementation that is optimally convergent.

  • F16.5

    Adaptivity shall work with interface kernels as long as stateful properties are not used.

  • F16.6

    The system shall error if the triad of interface kernels, adaptivity, and stateful properties are used together.

  • F16.7

    Interface kernels shall provide integrated conditions between subdomains, and shall work with boundary restricted materials with stateful properties.

  • F16.8

    The interface diffusion penalty method should reproduce the analytic solution

  • F16.9

    Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side a (block 0) of the interface.

  • F16.10

    Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side b (block 1) of the interface.

  • Ics
  • F17.1

    MOOSE shall generate parallel agnostic random initial conditions

  • F17.2

    MOOSE shall generate threaded agnostic random initial conditions

  • Mesh Modifiers
  • F18.1

    check the results of BreakMeshByBlock for a 3D case

  • F18.2

    compare results obtained with the manual autoamtic mesh splitprocedure matches for the 3D Case

  • F18.3

    same as 3D3BlocksBreakMeshAuto_test but with the prameter split_interface=true

  • F18.4

    For a 3D case, the MeshModifier should break the mesh into multiple unconnected grains and create an interface on all grain boundaries

  • F18.5

    same as 3D3BlocksBreakMeshManualSplitInterface_test but with the prameter split_interface=true

  • F18.6

    MOOSE shall allow the smoothing of existing meshes to improve mesh quality

  • F18.7

    check the results of BreakMeshByBlock for a 2D case

  • F18.8

    compare results obtained with the manual autoamtic mesh splitprocedure matches for the 2D Case

  • F18.9

    same as 2D4ElementJunctionBreakMeshAuto_test but with the prameter split_interface=true

  • F18.10

    For a 2D case, the MeshModifier should break the mesh into multiple unconnected grains and create an interface on all grain boundaries

  • F18.11

    same as 2D4ElementJunctionBreakMeshtingCompare_test but with the prameter split_interface=true

  • F18.12

    A LowerDBlockFromSideset mesh modifier shall create a lower dimensional element block from a list of sidesets

  • F18.13

    A LowerDBlockFromSideset mesh modifier shall create a second order lower dimensional block from second order parents

  • Multiapps
  • F19.1

    Multiapps shall be able to be restored when a subapp encounters a solve failure.

  • F19.2

    CSV file writing should remain unaffected when a subapp encounters a solve failure.

  • Auxkernels
  • F20.1

    AuxKernel objects shall be capable of coupling to VectorPostprocessor objects.

  • F20.2

    Kernel objects shall be capable of coupling to an auxiliary variable.

  • F20.3

    AuxKernel object dependencies shall be resolved automatically.

  • F20.4

    AuxKernel objects shall operate on higher-order monomial basis functions.

  • F20.5

    AuxKernel objects shall operate on first-order L2 basis functions.

  • F20.6

    AuxKernel object dependencies shall be resolved between block and non-block restricted variables.

  • F20.7

    MOOSE shall include the ability to compute the linear combination of variables as an auxiliary variable.

  • F20.8

    MOOSE shall support the ability to compute the quotient of two variables.

  • F20.9

    MOOSE shall include the ability to access the normal of a coupled variable within an AuxKernel object.

  • F20.10

    MOOSE shall include the ability to compute the integral of a variable over time.

  • F20.11

    MOOSE shall include the ability to set the value of a scalar variable using a function.

  • F20.12

    MOOSE shall include the ability to compute the shortest distance from a nodes across boundaries.

  • F20.13

    Execution of a UserObject shall occur after the execution of the AuxKernel objects if the former depends on the latter.

  • F20.14

    The AuxScalarKernel system shall automatically resolve dependencies between objects.

  • F20.15

    MOOSE shall include the ability to limit the execution of an AuxKernel object to initial setup.

  • F20.16

    MOOSE shall include the ability to couple auxiliary variables.

  • F20.17

    MOOSE shall be capable of resolving dependencies between AuxKernel objects regardless of input file order.

  • F20.18

    The AuxKernel objects shall be capable of coupling to multiple variables.

  • F20.19

    The MOOSE auxiliary system shall be capable of updating multiple auxiliary variables within a single AuxKernel object.

  • F20.20

    The MOOSE auxiliary system shall be capable of coupling to nonlinear variables at the end of a timestep.

  • F20.21

    MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap.

  • F20.22

    MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap for a block restricted variable.

  • F20.23

    The DiffusionFluxAux object shall compute the components of the flux vector for diffusion problems.

  • F20.24

    MOOSE shall be capable of populating an auxiliary variable from VectorPostprocessor data sized to the number of processors.

  • F20.25

    The 'auxkernels/solution_aux/build' test shall create an output file for testing the 'SolutionAux' object.

  • F20.26

    The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution.

  • F20.27

    The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution using a direct degree-of-freedom copy for identical meshes.

  • F20.28

    The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file.

  • F20.29

    The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file with a custom extension (e.g., *.e-s003).

  • F20.30

    The SolutionAux object shall be capable of reading elemental data for the largest timestep.

  • F20.31

    The SolutionAux object shall be capable of reading elemental data for a specific timestep.

  • F20.32

    The SolutionAux object shall be capable of restricting reading to a single elemental variable.

  • F20.33

    The SolutionAux object shall be capable of initializing an auxiliary variable from an existing ExodusII file using a direct degree-of-freedom copy for identical meshes.

  • F20.34

    The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation.

  • F20.35

    The 'auxkernels/solution_aux/exodus_interp_restart1' shall create a restart file for subsequent tests.

  • F20.36

    The SolutionAux object shall be capable of restart.

  • F20.37

    The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation using a direct degree-of-freedom copy for identical meshes.

  • F20.38

    The SolutionAux object shall be capable of accessing specific variables from a SolutionUserObject.

  • F20.39

    The SolutionAux object shall produce an error if the 'from_variable' parameter is not set and the supplied UserObject has multiple variables.

  • F20.40

    The SolutionUserObject object shall be capable of scaling and translating the supplied data.

  • F20.41

    The SolutionAux object shall error if data for the supplied variable is not found in the SolutionUserObject data.

  • F20.42

    The 'auxkernels/solution_aux/aux_nonlinear_solution' test shall create an XDA and XDR output file for testing the 'SolutionAux' object with auxiliary variables.

  • F20.43

    The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file.

  • F20.44

    The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDR file.

  • F20.45

    The 'auxkernels/solution_aux/aux_nonlinear_solution_adapt' test shall create an XDA output file for testing the 'SolutionAux' object with adaptivity.

  • F20.46

    The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file with adaptivity.

  • F20.47

    The SolutionAux object shall be capable to reading auxiliary variables when operating on multiple threads.

  • F20.48

    MOOSE shall include an AuxKernel object capable of computing values from a functional expression.

  • F20.49

    MOOSE shall include an AuxKernel object for returning the element length.

  • F20.50

    MOOSE shall have the ability to restrict AuxKernel objects with coupled variables to a boundary.

  • F20.51

    MOOSE shall allow objects that depend on each other but have differing execution flags to run without error.

  • F20.52

    The variable data created by a MaterialRealAux object shall support being limited to boundaries.

  • F20.53

    AuxKernel objects shall support the use of material properties from the previous two timesteps.

  • F20.54

    The ConstantScalarAux object shall set the value of an scalar auxiliary variable to a constant value.

  • F20.55

    MOOSE shall include the ability to normalize a variable based on a Postprocessor value.

  • F20.56

    MOOSE shall support the computation of a single value per element within the auxiliary system.

  • F20.57

    MOOSE shall include the ability to compute the Euclidean norm of three coupled variables.

  • F20.58

    MOOSE shall include the ability to compute the Lp, L2, and H1 error norms for each element.

  • F20.59

    MOOSE shall be able to compute and visualize element quality metrics

  • F20.60

    Kernel objects shall be able to couple to the time derivative of an auxiliary variable.

  • F20.61

    AuxKernel objects shall be able to couple to the time derivative of a nonlinear variable.

  • F20.62

    Error an AuxKernel object attemps to couple to the time derivative of an auxiliary variable.

  • F20.63

    MOOSE shall include the ability to extract a component of a linear Largrange variable gradient as an auxiliary variable.

  • F20.64

    MOOSE shall include the ability to extract a component of a first order monomial variable gradient as an auxiliary variable.

  • F20.65

    MOOSE shall support auxiliary calculations for scalar variables at nodes.

  • Dampers
  • F21.1

    MOOSE shall include the ability to reduce the change in nonlinear residual based on a constant value.

  • F21.2

    MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on nodes.

  • F21.3

    MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on nodes.

  • F21.4

    The Damper system shall use the minimum of NodalDamper and ElementDamper, when the later computes the minimum.

  • F21.5

    The Damper system shall use the minimum of NodalDamper and ElementDamper, when the former computes the minimum.

  • F21.6

    MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on elements.

  • F21.7

    MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on elements.

  • F21.8

    The Damper system shall be capable of reducing the change in non linear residual based on an allowable increment on elements using an absolute increment.

  • F21.9

    The Damper system shall be capable of reducing the change in non linear residual based on an allowable increment on elements using an fractional increment.

  • F21.10

    The BoundingValueNodalDamper object shall report if the minimum value is greater than the maximum value.

  • F21.11

    The BoundingValueElementDamper object shall report if the minimum value is greater than the maximum value.

  • F21.12

    The Damper system shall error if the damping value is below a minimum.

  • Fixedbugs
  • F22.1

    The Material objects provided on all subdomains shall satisfy requests for objects on all subdomains.

  • Problems
  • F23.1

    MOOSE shall have a capability to dump the equivalent input file syntax for all objects added by a given action.

  • F23.2

    MOOSE shall support an code coupling interface that can trigger external solves.

  • F23.3

    MOOSE shall support an code coupling interface that can trigger external solves for transient simulations.

  • F23.4

    The system shall allow the creation of a custom problem through a user-defined Action.

  • F23.5

    The system shall support the creation of a custom problem with parameters in Problem block.

  • F23.6

    The system shall error out when Problem block type is not specified.

  • F23.7

    The system shall support the creation of a custom problem through Problem block with type specified.

  • Partitioners
  • F24.1

    Make MOOSE support ptscotch via PETSc

  • F24.2

    ptscotch shall support element-weighted graphs for balancing workload

  • F24.3

    ptscotch shall support side-weighted graphs for minimizing communication

  • F24.4

    ptscotch shall take both side weights and element weights into consideration

  • F24.5

    Make MOOSE support parmetis via PETSc

  • F24.6

    Parmetis shall support element-weighted graphs for balancing workload

  • F24.7

    Parmetis shall support side-weighted graphs for minimizing communication

  • F24.8

    Parmetis shall take side weights and element weights into consideration

  • F24.9

    MOOSE shall support a serial partitioner Chaco

  • F24.10

    MOOSE shall support a serial partitioner party

  • F24.11

    MOOSE shall provide a simple regular grid-based partitioner

  • F24.12

    MOOSE shall error if the GridPartitioner is run on an incompatible number of processors

  • Postprocessors
  • F25.1

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.2

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.3

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.4

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.5

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.6

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.7

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.8

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.9

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.10

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.11

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.12

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.13

    Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.

  • F25.14

    The NumNodes Postprocessor shall report the number of nodes (replicated or distributed) in the simulation.

  • F25.15

    The NumNodes Postprocessor shall report the number of nodes in the simulation when using distributed (pre-split) mesh.

  • F25.16

    The NumVars Postprocessor shall report the number of variables from one or more equation systems in the simulation.

  • F25.17

    The system shall support sampling a specific quantity integrated over a single element.

  • F25.18

    MOOSE shall have the abililty to pull time from the PerfGrahp into a Postprocessor

  • F25.19

    MOOSE shall provide a postprocessor to measure physical and virtual memory usage and the major page fault count, depending on the operating system's ability to make those values available

  • F25.20

    The system shall contain a Postprocessor that computes the average value of a variable.

  • F25.21

    The AreaPostprocessor shall compute the "area" or dimension - 1 "volume" of sides.

  • F25.22

    The NumDOFs Postprocessor shall report the number of degrees of freedom (DOFS) from one or more equations systems in the simulation.

  • F25.23

    The NumElems Postprocessor shall report the number of elements (active or total) in the simulation.

  • F25.24

    The NumElems Postprocessor shall report the number of elements (active or total) in the simulation when using distributed (pre-split) mesh.

  • F25.25

    The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors.

  • F25.26

    The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors while maintaining vector history.

  • F25.27

    The TableOutput object shall allow the user to override tolerance checks when determining whether new rows should be added (independent variable delta)

  • Coord Type
  • F26.1

    MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction.

  • F26.2

    MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction.

  • F26.3

    MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction with discontinous Galkerin and integrated boundary conditions.

  • F26.4

    MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction with discontinous Galkerin and integrated boundary conditions.

  • Transfers
  • F27.1

    MultiAppUserObjectTransfer shall generate an error if a master node/element is not contained within any sub application domains.

  • Outputs
  • F28.1block

    Disabling Console objects should result in no output to the screen.

  • F28.2

    The Nemesis Ouput object shall support writing elemental variables.

  • F28.3

    The Nemesis Ouput object shall support writing elemental variables.

  • F28.4

    Nemesis output shall work

  • F28.5

    GMV output shall work

  • F28.6

    We shall be able to dump YAML data

  • F28.7

    Executioner output shall only be given once

  • F28.8

    Tecplot output shall work

  • F28.9

    If tecplot api is available, tecplot output will be given in tecplot binary format

  • F28.10

    If tecplot api is not available, tecplot output will be given in ASCII format

  • F28.11

    We shall be able to dump the possible input file syntax for a given MOOSE application

  • F28.12

    We shall be able to generate gnuplot postscript output

  • F28.13

    We shall be able to generate gnuplot png output

  • F28.14

    We shall be able to generate gnuplot gif output

  • F28.15

    If a postprocessor utilizes the "outputs" parameter, but postprocessor output is disable for the console object, we shall warn the user

  • F28.16

    –show-input shall print parameters

  • F28.17

    Solution history output shall work

  • F28.18

    MOOSE shall support XDR output

  • F28.19

    We shall be able to convert input file syntax into JSON syntax

  • F28.20

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExistsIn

  • F28.21

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ChildAtLeastOne

  • F28.22

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ValEnums

  • F28.23

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check active parameter

  • F28.24

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check normal_sub

  • F28.25

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check type_sub

  • F28.26

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check default type

  • F28.27

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check MinValInc

  • F28.28

    MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExpressionsAreOkay

  • F28.29

    The variables specified in an Output object's 'hide = ' list shall not appear in the output file.

  • F28.30

    MOOSE shall have the ability to output a detailed performance log

  • F28.31

    The Output system shall be capable of applying displacements directly to the outputted mesh for steady problems.

  • F28.32

    The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems with Kernels using the displaced configuration.

  • F28.33

    The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems.

  • F28.34

    If the user requested the output of a displaced problem and there is none present, the system shall fallback to using the non-displaced problem.

  • Markers
  • F29.1

    It shall not be possible to specify Markers to run on the displaced mesh.

  • F29.2

    The adaptivity system shall create an auxiliary field variable that marks elements for refinement within a rectangular region.

  • F29.3

    The adaptivity system shall adapt the mesh within a rectangular region.

  • Mesh
  • F30.1

    A mesh can be split into a specified number of files using command line options.

  • F30.2

    A mesh can be pre-split properly and used to generate equivalent results to running a simulation with the unsplit mesh.

  • F30.3

    Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode

  • F30.4

    Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode

  • F30.5

    The mesh splitter will throw an error when an attempt is made to split a "DistributedMesh".

  • F30.6

    The mesh splitter capability will honor geometric RelationshipManager objects.

  • F30.7

    Meshes that are pre-split with active RelationshipManager objects work the same as if using an online DistributedMesh.

  • F30.8

    MOOSE shall allow writing out the mesh

  • F30.9

    MOOSE shall print out information about the mesh when writing out the mesh

  • F30.10

    MOOSE shall warn when using –mesh-only and there is no clear filename to use

  • F30.11

    DistributedGeneratedMesh shall allow mesh biasing

  • F30.12

    MOOSE shall support writing out a solution in a parallel file format (domain decomposition solution files).

  • F30.13

    MOOSE shall generate a structured mesh on a Cartesian domain.

  • F30.14

    MOOSE shall generate first-order, structured meshes with biasing in the x, y, and z directions.

  • F30.15

    MOOSE shall generate second-order, structured meshes with biasing in the x, y, and z directions.

  • F30.16

    MOOSE's annular mesh generator shall throw an error if the min radius is larger than the max radius.

  • F30.17

    MOOSE's annular mesh generator shall throw an error if the min angle is >= the max angle.

  • F30.18

    MOOSE's annular mesh generator shall throw an error if the angle separation is larger than 2*pi.

  • F30.19

    MOOSE's annular mesh generator shall throw an error if the number of elements in the angular direction is too small.

  • F30.20

    MOOSE's annular mesh generator shall throw an error if the number of elements in the angular direction is too small.

  • F30.21

    MOOSE's annular mesh generator shall throw an error if the quadrilateral and triangular subdomain ids are the same.

  • F30.22

    MOOSE shall have an algorithm for quad meshing an annulus.

  • F30.23

    MOOSE shall have an algorithm for quad meshing an annular sector.

  • F30.24

    MOOSE shall have an algorithm for quad meshing a circular region, including the origin.

  • F30.25

    MOOSE shall have an algorithm for quad meshing a circular sector, including the origin.

  • F30.26

    MOOSE shall have an algorithm for meshing an annular region with triangular elements.

  • F30.27

    MOOSE shall have an algorithm for generating triangular and quadrilateral meshes for the Ringleb problem.

  • F30.28

    MOOSE shall be able to build a 1D mesh in parallel

  • F30.29

    MOOSE shall be able to build a 2D mesh in parallel

  • F30.30

    MOOSE shall be able to build a 3D mesh in parallel

  • Vectorpostprocessors
  • F31.1

    The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 1D mesh

  • F31.2

    The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 2D mesh

  • F31.3

    The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 3D mesh

  • F31.4

    Line sampling shall account for floating point precision error.

  • F31.5

    MOOSE shall provide VectorPostprocessor results to all processors as scattered data

  • F31.6

    MOOSE shall provide VectorPostprocessor results to all processors as replicated data

  • F31.7

    The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 1D mesh

  • F31.8

    The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 2D mesh

  • F31.9

    The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 3D mesh

  • F31.10

    The VectorPostprocessor system takes a parameter "contains_complete_history" which guarentees the vector state is left alone between invocations resulting in a single CSV output file.

  • Constraints
  • F32.1

    MOOSE shall support the ability to constrain nodal values.

  • F32.2

    MOOSE shall support the ability to constrain nodal values using a displaced mesh.

  • F32.3

    MOOSE shall include the ability to constrain the values on a boundary to a value at a prescribed node.

  • F32.4

    MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface using Lagrange multipliers.

  • F32.5

    MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface.

  • F32.6

    MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.

  • F32.7

    MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a penalty formulation.

  • F32.8

    MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.

  • F32.9

    MOOSE shall support embedded constraints between a 1D and 3D subdomain, using a penalty formulation.

  • F32.10

    MOOSE shall support embedded constraints between 2D subdomains, using a kinematic formulation.

  • F32.11

    MOOSE shall support embedded constraints between 2D subdomains, using a penalty formulation.

  • F32.12

    MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a kinematic formulation.

  • F32.13

    MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a penalty formulation.

  • F32.14

    MOOSE shall support embedded constraints between 3D subdomains, using a kinematic formulation.

  • F32.15

    MOOSE shall support embedded constraints between 3D subdomains, using a penalty formulation.

  • Bcs
  • F33.1

    MOOSE shall support the creation of BoundaryCondition objects that support conditional activation.

  • F33.2

    MOOSE shall support periodic boundary conditions with transforms defined as functions.

  • F33.3

    MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions.

  • F33.4

    MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions using a non-generated mesh.

  • F33.5

    The PeriodicDistanceAux object shall produce an error when a point is provided that is outside the mesh domain.

  • F33.6

    MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x', 'y', and 'z' directions.

  • F33.7

    MOOSE shall support periodic boundary conditions on orthogonal boundaries with transforms defined as functions.

  • F33.8

    MOOSE shall support periodic boundary conditions on parallel boundaries with transforms defined as functions.

  • F33.9block

    MOOSE shall support periodic boundary conditions on subdomain restricted variables.

  • F33.10

    MOOSE shall support periodic boundary conditions with mesh adaptivity.

  • F33.11

    MOOSE shall support periodic boundary conditions with transforms prescribed as a translation.

  • F33.12

    MOOSE shall support periodic boundary conditions with displacements.

  • F33.13

    MOOSE shall support periodic boundary conditions on a trapezoid domain with transforms prescribed as functions.

  • F33.14

    Calls to periodic distance and bounds methods on the mesh shall work when periodic boundary conditions are not used.

  • F33.15

    MOOSE shall support periodic boundary conditions on a wedge domain with transforms prescribed as functions.

  • F33.16

    MOOSE shall support periodic boundary conditions for a single variable on a wedge domain with transforms prescribed as functions.

  • F33.17

    MOOSE shall support periodic boundary conditions for input meshes that have repeated element ids.

  • F33.18

    The Periodic Boundary system shall not attempt to add periodic boundary conditions to scalar variables.

  • F33.19

    MOOSE shall be capable of computing the nodal normals for triangle elements.

  • F33.20

    MOOSE shall be capable of computing the nodal normals for quadrilateral elements.

  • F33.21

    MOOSE shall be capable of computing the nodal normals for first order hexahedron elements.

  • F33.22

    MOOSE shall be capable of computing the nodal normals for second order hexahedron elements.

  • F33.23

    MOOSE shall be capable of computing the first order nodal normals for second order hexahedron elements.

  • F33.24

    MOOSE shall be capable of computing the nodal normals for quadrilateral elements on a square domain.

  • F33.25

    MOOSE shall support Dirichlet type boundary conditions defined by a function.

  • F33.26

    BoundaryCondition objects shall support retrieval of VectorPostprocessor data.

  • F33.27

    MOOSE shall support setting Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.

  • F33.28

    MOOSE shall support setting Dirichlet type boundary conditions directly to the solution vector prior to the solve.

  • F33.29

    MOOSE shall include the ability to apply a Neumann boundary condition according to a sin function.

  • F33.30

    MOOSE shall include the ability to apply a Dirichlet boundary condition according to a sin function.

  • F33.31

    MOOSE shall support the creation of BoundaryCondition objects that couple to nonlinear variables.

  • F33.32

    MOOSE shall support Neumann type boundary conditions for a 1D problem.

  • F33.33

    MOOSE shall support Neumann type boundary conditions for a 1D problem using an imported mesh.

  • F33.34

    MOOSE shall support the ability to create convective flux boundary conditions.

  • F33.35

    MOOSE shall support a vacuum boundary condition for neutron diffusion on the boundary.

  • F33.36

    MOOSE shall support Neumann type boundary conditions where the specified value is defined as the value of a vector, , in the direction of the boundary outward facing normal, (i.e., ).

  • F33.37

    MOOSE shall support the 'no boundary condition' type boundary condition (Griffiths, 1997).

  • F33.38

    MOOSE shall support creating sidesets from nodesets for hexahedron elements to use with Boundary Condition objects.

  • F33.39

    MOOSE shall support creating sidesets from nodesets for tetrahedron elements to use with Boundary Condition objects.

  • F33.40

    MOOSE shall properly compute second derivatives within BoundaryCondition objects.

  • F33.41

    MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method.

  • F33.42

    MOOSE shall support the application of Dirichlet type boundary conditions, defined by a function, using the penalty method.

  • F33.43

    MOOSE shall support the application of a Neumann boundary condition computed via Postprocessor object.

  • F33.44

    MOOSE shall support matching variable values on a boundary.

Usability Requirements

  • U1.0

    The system will be command-line and input file driven.

  • U1.1

    The system shall return usage messages when unidentified arguments or incorrectly used arguments are passed.

  • U1.2

    The system shall provide diagnostics when the input file fails to parse, or the format is incorrect.

  • U1.3

    The system will provide on screen information about the simulation and performance characteristics of the solves under normal operating conditions.

Performace Requirements

  • P1.0

    The system will support multi-process distributed memory execution.

  • P1.1

    The system will support multi-process shared memory execution.

  • P1.2

    The system will support execution on Unix-based laptops.

  • P1.3

    The system will support execution on Unix-based workstation systems.

  • P1.4

    The system will support execution on large Unix-based cluster systems.

System Interfaces

  • S1.0

    The system shall support POSIX compliant systems.

  • S1.1

    The system shall support the Message Passing Interface (MPI) standard.

  • S1.2

    The system shall support POSIX pthreads''.

  • S1.3

    The system shall support Intel Threaded Building Blocks (TBB) interface.

  • S1.4

    The system shall support the OpenMP threading interface.

System Operations

Human System Integration Requirements

error:Missing Template Item "human-system-integration"help_outline

Reference applicable documents and specify any special or unique requirements (e.g., constraints on allocation of functions to personnel and communications and personnel/equipment interactions). This should include accessibility requirements related to the ability of disabled individuals to access the information or service provided by the system.

Define any specific areas, stations, or equipment that would require concentrated human engineering attention due to the sensitivity of the operation or criticality of the task (i.e., those areas where the effects of human error would be particularly serious).

Maintainablity

  • The latest working version (defined as the version that passes all tests in the current regression test suite) shall be publicly available at all times through the repository host provider.

  • Flaws identified in the system shall be reported and tracked in a ticket or issue based system. The technical lead will determine the severity and priority of all reported issues and assign resources at his or her discretion to resolve identified issues.

  • The software maintainers will entertain all proposed changes to the system in a timely manner (within two business days).

  • The core framework in its entirety will be made publicly available under the GNU Library General Public License (LGPL) version 2.0 license.

Reliability

The regression test suite will cover at least 80% of all lines of code at all times. Known regressions will be recorded and tracked (see Maintainablity) to an independent and satisfactory resolution.

System Modes and States

error:Missing Template Item "system-modes"help_outline

If the system can exist in various modes or states define these and, as appropriate, use diagrams.

note

The mode of a system refers to a collection of states.

Phyisical Characteristics

error:Missing Template Item "physical-characteristics"help_outline

Include constraints on weight, volume and dimension. Include the construction characteristics of where the system will be installed, requirements for materials to be used in the item or service covered by this specification, and requirements covering nameplates and system markings, interchangeability of equipment, and workmanship.

Environmental Conditions

error:Missing Template Item "environmental-conditions"help_outline

Include environmental conditions to be encountered by the system. The following areas should be addressed: natural environment (e.g., wind, rain, temperature, flora, fauna, fungus, mold, sand, salt spray, dust, radiation, chemical, and immersion); induced environment (e.g., motion, shock, noise, electromagnetic, thermal); electromagnetic signal environment; self-induced environment (e.g., motion, shock, noise, electromagnetic, thermal); threat; and cooperative environment. Consideration should also be given to legal/regulatory, political, economic, social, and business environment.

System Security

error:Missing Template Item "system-security"help_outline

Define the system security requirements related to the environment that houses the system and operational security requirements of the system itself. Examples of such requirements are data privacy, user access, user privilege, export control, system configuration, event logging and communications.

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

error:Missing Template Item "policies-and-regulations"help_outline

Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements, or constraints imposed by normal business practices. Examples of requirements include multilingual support, labor policies, protection of personnel information, and reports to a regulatory agency.

Specify health and safety criteria, including those basic to the design of the system, with respect to equipment characteristics, methods of operation, and environmental influences such as toxic systems and electromagnetic radiation.

System Life Cycle Sustainment

error:Missing Template Item "system-life-cycle"help_outline

Outline quality activities, such as review, and measurement collection and analysis, to help realize a quality system. Life cycle sustainment also includes provision of facilities needed to provide operational- and depot-level support, spares, sourcing and supply, provisioning, technical documentation and data, support-personnel training, initial cadre training, and initial contractor-logistics support.

Packaging, Handling, Shipping and Transportation

error:Missing Template Item "packaging"help_outline

Define requirements imposed on the system to ensure that it can be packaged, handled, shipped, and transported within its intended operational context.

Verification

The regression test suite will employ several verification tests using comparison against known analytical solutions, the method of manufactured solutions, and convergence rate analysis.