Framework System Requirements Specification

Introduction

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

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

ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.

@manual{ISO-systems-software,
    author = "24765:2010(E), ISO/IEC/IEEE",
    title = "Systems and software engineering---Vocabulary",
    edition = "First",
    year = "2010",
    month = "December 15"
}

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.

@article{griffiths1997noboundary,
    author = "Griffiths, D. F.",
    title = "{The `No Boundary Condition' outflow boundary condition}",
    journal = "International Journal of Numerical Methods in Fluids",
    year = "1997",
    volume = "24",
    number = "4",
    pages = "393--411",
    url = "http://tinyurl.com/y77au2k"
}

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.

@manual{ASME-NQA-1-2008,
    author = "NQA-1, ASME",
    title = "ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications",
    orginization = "American Socieity of Mechanical Engineers",
    year = "2009",
    month = "August 31",
    edition = "First"
}

Definitions and Acronyms

This section defines, or provides the definition of, all terms and acronyms required to properly understand this specification.

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

Acronym	Description
FEM	Finite Element Method
JFNK	Jacobian-Free Newton-Krylov
LGPL	GNU Lesser General Public License
MOOSE	Multiphysics Object Oriented Simulation Environment
NQA-1	Nuclear Quality Assurance Level 1
POSIX	Portable Operating System Interface

System Requirements

The creation of the requirements for MOOSE is an ongoing progress as new objects are added. The Functional Requirements are generated from test specifications, which are required with each addition to the MOOSE framework or its modules.

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)
Python 3.6+
Git

Functional Requirements

framework: Actions
1.1.1The system shall error if the supplied order of scalar auxiliary variable is of an unknown order.
1.1.2The system shall support calculations with an auxiliary scalar variable represented with a 21st order monomial function.
1.1.3The system shall be capable of reporting Action object dependencies.
1.1.4The system shall be capable of reporting Action object task information.
1.1.5The system shall support the detailed on-screen output of all of the Reporters that were declared and requested, including type, producer, context, and consumers.
1.1.6The system shall be able to retrieve other Action objects from within another Action object.
1.1.7The Action system shall allow Action objects to create other Action objects.
1.1.8The Action system shall allow the creation of Action objects with multiple tasks.

framework: Adaptivity
1.2.1The Adaptivity system shall allow for multiple mesh adaptivity steps per timestep.
1.2.2The Adaptivity system shall support mesh adaptivity during initial setup.
1.2.3The Adaptivity system shall support marking elements for refinement during initial setup using a different marker than used during execution.
1.2.4The Adaptivity system shall support execution at every n timestep.
1.2.5The Adaptivity system shall be capable of restricting the element refinement level.
1.2.6The Adaptivity system shall allow for Marker objects to be recomputed with each adaptivity cycle.

framework: Auxkernels
1.3.1MOOSE shall include the ability to set the value of an array variable using a function.
1.3.2MOOSE shall provide a way to convert a component of an array variable to a standard variable.
1.3.3MOOSE shall support auxiliary calculations for scalar variables at nodes.
1.3.4The AuxScalarKernel system shall automatically resolve dependencies between objects.
1.3.5The system shall include the ability to compute a field variable with a constant upper and lower bounds.
1.3.6The system shall error if a variational inequalities (VI) solver is not found when BoundsAux is provided.
1.3.7The system shall include the ability to compute a field variable with a lower bound given by variable's old value.
1.3.8The system shall support the copy the values of standard variables into the component fields of an array variable.
1.3.9
The system shall report a reasonable error when copying standard variables into the components of an array variable when
1. the variables have inconsistent sizes or
2. when the variables have inconsistent types.
1.3.10The ConstantScalarAux object shall set the value of an scalar auxiliary variable to a constant value.
1.3.11The system shall make current boundary id available in objects evaluated on boundaries.
1.3.12The DiffusionFluxAux object shall compute the components of the flux vector for diffusion problems.
1.3.13The DiffusionFluxAux object shall compute the normal component of the flux vector for diffusion problems.
1.3.14The variable data created by a MaterialRealAux object shall support being limited to boundaries.
1.3.15MOOSE shall support boundary restricted auxiliary elemental variables with high order shape functions.
1.3.16MOOSE shall error if a boundary restricted elemental auxiliary kernel is evaluated on an element with multiple boundary sides
1.3.17The system shall allow a boundary restricted elemental auxiliary kernel to be evaluated on an element with multiple boundary sides by setting an input parameter.
1.3.18Kernel objects shall be capable of coupling to an auxiliary variable.
1.3.19AuxKernel object dependencies shall be resolved automatically.
1.3.20AuxKernel objects shall operate on higher-order monomial basis functions.
1.3.21AuxKernel objects shall operate on first-order L₂ basis functions.
1.3.22AuxKernel object dependencies shall be resolved between block and non-block restricted variables.
1.3.23MOOSE shall include an AuxKernel object for returning the element length.
1.3.24MOOSE shall be able to compute and visualize element quality metrics
1.3.25MOOSE shall support the computation of a single value per element within the auxiliary system.
1.3.26MOOSE shall include the ability to compute the L^p, L², and H¹ error norms for each element.
1.3.27MOOSE shall allow objects that depend on each other but have differing execution flags to run without error.
1.3.28MOOSE shall include the ability to access the normal of a coupled variable within an AuxKernel object.
1.3.29MOOSE shall include the ability to set the value of a scalar variable using a function.
1.3.30MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap.
1.3.31MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap for a block restricted variable.
1.3.32
The system shall support viewing the elements that would be ghosted
1. to specific processors and
2. include local elements.
1.3.33MOOSE shall utilize the minimum of ghosting necessary for the problem
1.3.34MOOSE shall include the ability to extract a component of a linear Largrange variable gradient as an auxiliary variable.
1.3.35MOOSE shall include the ability to extract a component of a first order monomial variable gradient as an auxiliary variable.
1.3.36MOOSE shall allow visualization of the MPI processes mapping to compute nodes
1.3.37MOOSE shall include the ability to compute the linear combination of variables as an auxiliary variable.
1.3.38MOOSE shall include the ability to use extra element integers.
1.3.39MOOSE shall include the ability to use extra element integers on element faces.
1.3.40MOOSE shall include the ability to compute the shortest distance from a nodes across boundaries.
1.3.41MOOSE shall have the ability to restrict AuxKernel objects with coupled variables to a boundary.
1.3.42MOOSE shall include the ability to limit the execution of an AuxKernel object to initial setup.
1.3.43MOOSE shall include the ability to couple auxiliary variables.
1.3.44MOOSE shall be capable of resolving dependencies between AuxKernel objects regardless of input file order.
1.3.45The AuxKernel objects shall be capable of coupling to multiple variables.
1.3.46The MOOSE auxiliary system shall be capable of updating multiple auxiliary variables within a single AuxKernel object.
1.3.47The MOOSE auxiliary system shall be capable of coupling to nonlinear variables at the end of a timestep.
1.3.48MOOSE shall include the ability to normalize a variable based on a Postprocessor value.
1.3.49MOOSE shall include the ability to normalize and shift a variable based on a Postprocessor value.
1.3.50AuxKernel objects shall support the use of material properties from the previous two timesteps.
1.3.51MOOSE shall include an AuxKernel object capable of computing values from a functional expression.
1.3.52The parsed expression AuxKernel in MOOSE shall expose quadrature/nodal point coordinates and time if requested by the user.
1.3.53Execution of a UserObject shall occur after the execution of the AuxKernel objects if the former depends on the latter.
1.3.54Execution of a FunctionValuePostprocessor that depends on a Function which depends on a second PostProcessor is construction order dependent.
1.3.55Implicit dependencies of FunctionValuePostprocessors may be declared to resolve execution order independently of construction order.
1.3.56MOOSE shall support the ability to compute the quotient of two variables.
1.3.57
The system shall be capable of initializing an auxiliary variable from an existing solution
1. from data generated by a simulation
2. and loaded using location,
3. using a direct degree-of-freedom copy for identical meshes,
4. with scaling the supplied data,
5. and that errors if data for the supplied variable is not found.
1.3.58The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file.
1.3.59The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file with a custom extension (e.g., *.e-s003).
1.3.60The SolutionAux object shall be capable of reading elemental data for the largest timestep.
1.3.61The SolutionAux object shall be capable of reading elemental data for a specific timestep.
1.3.62The SolutionAux object shall be capable of restricting reading to a single elemental variable.
1.3.63The 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.
1.3.64The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation.
1.3.65
The system shall be capable of initializing an auxiliary variable from an existing solution that
1. is created in a simulation and
2. used to restart another.
1.3.66The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation using a direct degree-of-freedom copy for identical meshes.
1.3.67The SolutionAux object shall be capable of accessing specific variables from a SolutionUserObject.
1.3.68The SolutionAux object shall produce an error if the 'from_variable' parameter is not set and the supplied UserObject has multiple variables.
1.3.69
The systems object shall be capable of setting values using an auxiliary variable
1. from a simulation using
2. an ASCII file and
3. a binary file.
1.3.70
The system shall be capable of setting values using an auxiliary variable
1. create4d from a simulation with adaptivity
2. from an ASCII file
3. with multiple threads.
1.3.71
The system shall read a scalar variable from an Exodus file and use its value
1. from data generated by simulation
2. and loaded by another.
1.3.72Kernel objects shall be able to couple to the time derivative of an auxiliary variable.
1.3.73AuxKernel objects shall be able to couple to the time derivative of a nonlinear variable.
1.3.74Error an AuxKernel object attemps to couple to the time derivative of an auxiliary variable.
1.3.75MOOSE shall include the ability to compute the integral of a variable over time.
1.3.76MOOSE shall resolve the dependency of auxiliary kernels on user objects including the objects that the aux kernels indirectly depend on.
1.3.77MOOSE shall include the ability to set the components of a vector auxiliary variable using a function defined within the input file.
1.3.78MOOSE shall include the ability to compute the Euclidean norm of three coupled variables.
1.3.79The system shall be able to output vector auxiliary variables based on the values of vector material properties, regardless of whether the material properties are computed using automatic differentiation or not.
1.3.80MOOSE shall be capable of populating an auxiliary variable from VectorPostprocessor data sized to the number of processors.
1.3.81MOOSE shall include the ability to compute auxiliary quantities at the nodes of elements based on the values of a LAGRANGE_VEC variable.
1.3.82AuxKernel objects shall be capable of coupling to VectorPostprocessor objects.

framework: Bcs
1.4.1MOOSE shall support Neumann type boundary conditions for a 1D problem.
1.4.2MOOSE shall support Neumann type boundary conditions for a 1D problem using an imported mesh.
1.4.3
The system shall support Neumann type boundary conditions using automatic differentiation for a 1D problem
1. using a generated mesh.
2. and shall be able to produce the exact Jacobian
3. using an imported mesh.
1.4.4MOOSE shall support setting AD Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.
1.4.5MOOSE shall support setting AD Dirichlet type boundary conditions directly to the solution vector prior to the solve.
1.4.6MOOSE shall support setting AD Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve and have perfect Jacobians.
1.4.7MOOSE shall support setting AD Dirichlet type boundary conditions directly to the solution vector prior to the solve and have perfect Jacobians.
1.4.8We shall be able to produce the expected result using ADKernel, ADNodalBC, and ADIntegratedBC
1.4.9We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a first order variable
1.4.10We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a second order variable
1.4.11We shall be able to produce the expected result using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC
1.4.12We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a first order variable
1.4.13We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a second order variable
1.4.14The system shall be able to couple a lower-dimensional variable into a boundary condition for a higher-dimensional variable.
1.4.15
The system shall support Dirichlet type boundary conditions defined by a function
1. using automatic differentiation.
2. using automatic differentiation and shall be able to produce the exact Jacobian.
1.4.16
The system shall support Neumann type boundary conditions defined by a function
1. using automatic differentiation.
2. using automatic differentiation and shall be able to produce the exact Jacobian.
1.4.17
The system shall support the application of Dirichlet type boundary conditions using the penalty method using the AD system
1. with a constant value on the boundary.
2. with a constant value on the boundary and shall be able to produce the exact Jacobian.
3. with a value on the boundary set by a function.
4. with a value on the boundary set by a function and shall be able to produce the exact Jacobian.
1.4.18MOOSE shall provide array vacuum boundary condition.
1.4.19MOOSE shall support setting Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.
1.4.20MOOSE shall support setting Dirichlet type boundary conditions directly to the solution vector prior to the solve.
1.4.21MOOSE shall support the creation of BoundaryCondition objects that support conditional activation.
1.4.22MOOSE shall support the creation of BoundaryCondition objects that couple to nonlinear variables.
1.4.23MOOSE shall support coupled Neumann type boundary conditions.
1.4.24The system shall enable scaling of the Neumann type boundary conditions.
1.4.25The system shall be able to determine if a non-scalable algorithm is being used for ghosting boundaries.
1.4.26The system shall make sure that boundaries are actually distributed.
1.4.27The system shall support periodic boundary conditions in a parallel generated 2D mesh.
1.4.28The system shall support periodic boundary conditions in a parallel generated 3D mesh.
1.4.29The system shall support periodic boundary conditions in a parallel generated 1D mesh.
1.4.30MOOSE shall support Dirichlet type boundary conditions defined by a function.
1.4.31The system shall support applying a function of space-time as a Neumann boundary condition.
1.4.32MOOSE shall support matching variable values on a boundary.
1.4.33MOOSE shall support the ability to create convective flux boundary conditions.
1.4.34MOOSE shall support a vacuum boundary condition for neutron diffusion on the boundary.
1.4.35MOOSE shall support Neumann type boundary conditions where the specified value is defined as the value of a vector, $var element = document.getElementById("moose-equation-3cda0d03-1283-48ec-bdc7-117437e1b817");katex.render("v", element, {displayMode:false,throwOnError:false,macros:{"\\pf":"\\frac{\\partial #1}{\\partial #2}"}});$ , in the direction of the boundary outward facing normal, $var element = document.getElementById("moose-equation-1d06ba29-931b-431c-ab84-805adbe7c5e9");katex.render("\\hat{n}", element, {displayMode:false,throwOnError:false,macros:{"\\pf":"\\frac{\\partial #1}{\\partial #2}"}});$ (i.e., $var element = document.getElementById("moose-equation-eafbe84a-78b6-4494-8ab9-751a9dc5c843");katex.render("v\\cdot\\hat{n}", element, {displayMode:false,throwOnError:false,macros:{"\\pf":"\\frac{\\partial #1}{\\partial #2}"}});$ ).
1.4.36MOOSE shall support the 'no boundary condition' type boundary condition (Griffiths, 1997).
1.4.37MOOSE shall be capable of computing the nodal normals for triangle elements.
1.4.38MOOSE shall be capable of computing the nodal normals for quadrilateral elements.
1.4.39MOOSE shall be capable of computing the nodal normals for first order hexahedron elements.
1.4.40MOOSE shall be capable of computing the nodal normals for second order hexahedron elements.
1.4.41MOOSE shall be capable of computing the first order nodal normals for second order hexahedron elements.
1.4.42MOOSE shall be capable of computing the nodal normals for quadrilateral elements on a square domain.
1.4.43MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method.
1.4.44MOOSE shall support the application of Dirichlet type boundary conditions, defined by a function, using the penalty method.
1.4.45MOOSE shall support periodic boundary conditions with transforms defined as functions.
1.4.46MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions.
1.4.47MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions using a non-generated mesh.
1.4.48The PeriodicDistanceAux object shall produce an error when a point is provided that is outside the mesh domain.
1.4.49MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x', 'y', and 'z' directions.
1.4.50MOOSE shall support periodic boundary conditions on orthogonal boundaries with transforms defined as functions.
1.4.51MOOSE shall support periodic boundary conditions on parallel boundaries with transforms defined as functions.
1.4.52MOOSE shall support periodic boundary conditions with mesh adaptivity.
1.4.53MOOSE shall support periodic boundary conditions with transforms prescribed as a translation.
1.4.54MOOSE shall support periodic boundary conditions with displacements.
1.4.55MOOSE shall support periodic boundary conditions on a trapezoid domain with transforms prescribed as functions.
1.4.56Calls to periodic distance and bounds methods on the mesh shall work when periodic boundary conditions are not used.
1.4.57MOOSE shall support periodic boundary conditions on a wedge domain with transforms prescribed as functions.
1.4.58MOOSE shall support periodic boundary conditions for a single variable on a wedge domain with transforms prescribed as functions.
1.4.59MOOSE shall support periodic boundary conditions for input meshes that have repeated element ids.
1.4.60The Periodic Boundary system shall not attempt to add periodic boundary conditions to scalar variables.
1.4.61MOOSE shall support the application of a Neumann boundary condition computed via Postprocessor object.
1.4.62MOOSE shall properly compute second derivatives within BoundaryCondition objects.
1.4.63MOOSE shall support creating sidesets from nodesets for hexahedron elements to use with Boundary Condition objects.
1.4.64MOOSE shall support creating sidesets from nodesets for tetrahedron elements to use with Boundary Condition objects.
1.4.65MOOSE shall include the ability to apply a Neumann boundary condition according to a sin function.
1.4.66MOOSE shall include the ability to apply a Dirichlet boundary condition according to a sin function.
1.4.67BoundaryCondition objects shall support retrieval of VectorPostprocessor data.

framework: Constraints
1.5.1MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface using Lagrange multipliers.
1.5.2MOOSE shall include the ability to constrain the values on a boundary to a value at a prescribed node.
1.5.3MOOSE shall be able to enforce the equal value boundary constraint in parallel with adaptivity.
1.5.4
The system shall support embedded constraints between using a kinematic formulation between
1. 1D and 2D;
2. 1D and 3D;
3. 2D;
4. 2D and 3D; and
5. 3D subdomains.
1.5.5
The system shall support embedded constraints between using a penalty formulation between
1. 1D and 2D;
2. 1D and 3D;
3. 2D;
4. 2D and 3D; and
5. 3D subdomains.
1.5.6MOOSE shall support the ability to constrain nodal values.
1.5.7MOOSE shall support the ability to constrain nodal values using a displaced mesh.
1.5.8MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface.

framework: Controls
1.6.1The Control system shall allow a boolean parameter to be controlled with a function.
1.6.2The Control system shall be capable of activating or deactivating MOOSE objects using a conditional function.
1.6.3The MOOSE control system shall allow parameters from differing objects, with differing names to be associated and changed together.
1.6.4The MOOSE control system shall allow parameters from objects to be assigned aliases for the purpose of changing the value.
1.6.5The system shall allow controlling piecewise functions and material properties.
1.6.6The Control system shall support explicitly defined dependencies.
1.6.7The Control system shall error if an attempt to alter a non-controllable parameter is performed.
1.6.8The Control system shall error if multiple controllable parameters exists, but only a single parameter is expected to be controlled.
1.6.9The Control system shall error if an unknown parameter is supplied for control.
1.6.10The Control system shall error if a thread id greater than the number of threads available is supplied when retrieving a Control object.
1.6.11The Control system shall error if an attempt is made to disable the Executioner.
1.6.12The Control system shall error if an invalid control name is supplied to the Control dependency resolution procedure.
1.6.13The Control system shall support the modification of a single parameter using the objects base class name, object name, and parameter name.
1.6.14The Control system shall support the modification of multiple parameters using the objects base class and the parameter name.
1.6.15The Control system shall include a means to output information regarding the controlled parameters.
1.6.16The 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.
1.6.17MOOSE shall include a command line flag for displaying controllable parameter information.
1.6.18The Control system shall include a means to output information regarding the objects with controllable parameters.
1.6.19
The Control system shall be able to control an input parameter to make a postprocessor match a target value,
1. using the principle of Proportional Integral Derivative control,
2. using a input postprocessor in lieu of an input parameter,
3. with integral windup control, resetting the integral term if the error crosses zero,
4. keeping the PID process within a single timestep,
5. and resetting the PID process correctly if the solver fails during a Picard/coupling iteration.
1.6.20The Control system shall allow a scalar parameter to be controlled with a function.
1.6.21The Control system shall allow multiple scalar parameters to be controlled with a function.
1.6.22The MOOSE control system shall be capable of restricting parameters to be controlled for specific execution flags.
1.6.23The Control system shall allow multiple parameters to be changed by the parameter name alone using input syntax format.
1.6.24The Control system shall allow multiple parameters to be changed given the object and parameter names using input syntax format.
1.6.25The Control system shall allow for a single parameter to be changes given the input syntax, object name, and parameter name.
1.6.26The Control system shall allow for multiple parameters to be changed given input syntax and a parameter name.
1.6.27The Control system shall allow multiple parameters to be changed by the parameter name alone using a tag.
1.6.28The Control system shall allow multiple parameters to be changed given a tag and parameter names, given a tag assigned across input blocks.
1.6.29The 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.
1.6.30The 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.
1.6.31The Control system shall be capable of activating or deactivating AuxKernel objects with time.
1.6.32The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given identical start end times.
1.6.33The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given differing start end times.
1.6.34
The system shall be capable of activating and/or deactivating boundary contributions to the residual with time
1. for contributions from finite element nodes,
2. for contributions integrated over a finite element side,
3. for contributions from automatic differentiation, and
4. perform the activation/deactivation with a single control.
1.6.35The Control system shall be capable of activating or deactivating Constraint objects with time.
1.6.36MOOSE shall support the disabling an object using an input parameter.
1.6.37MOOSE shall support the enabling an object using an input parameter.
1.6.38The Control system shall be capable of activating or deactivating Damper objects with time.
1.6.39The Control system shall be capable of activating or deactivating DGKernel objects with time.
1.6.40The Control system shall be capable of activating or deactivating DiracKernel objects with time.
1.6.41The TimePeriod object shall error when used with a steady state problem.
1.6.42The TimePeriod object shall error when the start and end time parameters are not the same length.
1.6.43The TimePeriod object shall error when start and end time parameters differ in length than the supplied object list.
1.6.44The TimePeriod object shall error when a list of objects to control is omitted.
1.6.45The TimePeriod object shall error when start time is greater than the end time.
1.6.46
The system shall be capable of activating or deactivating volume residual contributions with time:
1. for non-automatic differentiation and
2. automatic differentiation terms.
1.6.47The Control system shall be capable of activating or deactivating MultiApp objects with time.
1.6.48The Control system shall be capable of activating or deactivating NodalKernel objects with time.
1.6.49The Control system shall be capable of activating or deactivating ScalarKernel objects with time.
1.6.50The Control system shall be capable of activating or deactivating Transfer objects with time.
1.6.51The Control system shall be capable of activating or deactivating UserObject objects with time.

framework: Coord Type
1.7.1MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction.
1.7.2MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction.
1.7.3MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction with discontinous Galkerin and integrated boundary conditions.
1.7.4MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction with discontinous Galkerin and integrated boundary conditions.

framework: Dampers
1.8.1MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on elements.
1.8.2MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on elements.
1.8.3MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on nodes.
1.8.4MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on nodes.
1.8.5MOOSE shall include the ability to reduce the change in nonlinear residual based on a constant value.
1.8.6The Damper system shall use the minimum of NodalDamper and ElementDamper, when the later computes the minimum.
1.8.7The Damper system shall use the minimum of NodalDamper and ElementDamper, when the former computes the minimum.
1.8.8The Damper system shall be capable of reducing the change in non linear residual based on an allowable increment on elements using an absolute increment.
1.8.9The Damper system shall be capable of reducing the change in non linear residual based on an allowable increment on elements using an fractional increment.
1.8.10The BoundingValueNodalDamper object shall report if the minimum value is greater than the maximum value.
1.8.11The BoundingValueElementDamper object shall report if the minimum value is greater than the maximum value.
1.8.12The Damper system shall error if the damping value is below a minimum.

framework: DGKernel Objects
1.9.1MOOSE shall support solving 1D advection using the discontinous Galerkin method.
1.9.2MOOSE shall support solving 2D diffusion using the discontinuous Galerkin method.
1.9.3DGKernels shall coexist with stateful material properties
1.9.4The system shall not perform memory allocation automatic scaling when computing values using discontinuous finite element methods.
1.9.5When objects that need one layer of coupling (like DGKernels) are added via action, we shall ensure that we have added a proper relationship manager and thus incur no mallocs during calls to MatSetValues. We will not apply algebraic ghosting nor reinitialize system vectors in serial, but we will reinitialize the matrix sparsity
1.9.6When objects that need one layer of coupling (like DGKernels) are added via action, we shall ensure that we have added a proper relationship manager and thus incur no mallocs during calls to MatSetValues. We will also apply algebraic ghosting in parallel which will require reinitializing the system; the sparsity pattern will also have to be reinitialized
1.9.7If a RelationshipManager with sufficient coverage has already been added through a MooseObjectAction, then the CouplingFunctorCheck action shall not add any relationship managers, avoiding reinitialization of system vectors and the system matrix
1.9.8This test shall have one more rm than its replicated counter part because of the geometric-only GhostPointNeighbors rm, also demonstrating no mallocs. Sparsity will be reinitialized but not vectors
1.9.9This test shall have one more rm than its replicated counter part because of the geometric-only GhostPointNeighbors rm, also demonstrating no mallocs. Sparsity and vectors will both be reinitialized
1.9.10This test shall have one more rm than its replicated counter part because of the geometric-only GhostPointNeighbors rm, also demonstrating no addition of rms by the CouplingFunctorCheckAction
1.9.11MOOSE shall support solving 3D diffusion using the discontinuous Galerkin method.
1.9.12We shall be able to use constant monomials with AD
1.9.13MOOSE should support AD in DG Kernels
1.9.14Adaptivity shall work with dg kernels as long as stateful properties are not used.
1.9.15The system shall error if the triad of dg kernels, adaptivity, and stateful properties are used together.
1.9.16MOOSE shall be able to solve the advection diffusion equation using the discontinuous Galerkin method.
1.9.17MOOSE shall compute the correct Jacobian for the advection diffusion equation using the discontinuous Galerkin method.
1.9.18The DGKernel system shall support restriction to subdomains, in 1D.
1.9.19The DGKernel system shall support restriction to subdomains, in 2D.
1.9.20The DGKernel system shall operate with displaced meshes.
1.9.21The DGCoupledDiffusion object shall compute the correct Jacobian.

framework: Dirackernels
1.10.1The system shall support the coupling of scalar aux variables for the purpose of sharing data and reporting values.
1.10.2The system shall support block restricted dirac kernels.
1.10.3
The system shall behave accordingly if the added point is not found, when point_not_found_behavior is set to
1. ERROR or
2. WARNING.
1.10.4
The system shall support a constant point source implemented as a Dirac function:
1. in 1D,
2. in 2D,
3. in 3D,
4. and with finite volume variables.
1.10.5The system shall allow for source locations to be set by a user-defined object.
1.10.6The system shall have the ability to set the value of point source from a function.
1.10.7The system shall allow point sources originating from the evaluation of material properties.
1.10.8
DiracKernel objects shall report an error if a material property from a previous time step is requested:
1. one step back, and
2. two steps back.
1.10.9The DiracKernel system shall allow for duplicate source locations to be defined.
1.10.10The system shall support the computation of off diagonal Jacobian terms for residual terms defined with a Dirac delta function.
1.10.11
The system shall support source location caching using element ids:
1. on a static mesh with no adaptivity,
2. with uniform mesh refinement,
3. with adaptive mesh refinement, and
4. with displaced mesh.
1.10.12The DiracKernel system shall report an error if a location does not correspond with the supplied element id.
1.10.13The system shall support point sources with locations and values given by a VectorPostprocessor in a steady state 2D problem, reproducing the constantPointSource.
1.10.14The system shall support point sources with locations and values referenced by name from the input file given by a VectorPostprocessor in steady state 3D problem, reproducing the constantPointSource.
1.10.15The system shall support point sources with locations and values given by a vector postProcessor in a transient problem with the vpp source value changing as the vpp changes.

framework: Executioners
1.11.1The Executioner system shall support the ability to create custom objects with custom execution callbacks.
1.11.2The Executioner system shall support the creation of custom objects with arbitrary execution flags.
1.11.3MOOSE shall support solving an Eigen value problem using the inverse power method.
1.11.4MOOSE shall support solving an Eigen value problem using Newton's method.
1.11.5MOOSE shall support solving an Eigen value problem using Newton's method in parallel.
1.11.6MOOSE shall support the use of material properties during an Eigen problem solve.
1.11.7MOOSE shall be capable of solving a diffusion problem using an Eigen value solver.
1.11.8MOOSE shall be capable of solving a nonlinear diffusion problem using an Eigen value solver.
1.11.9MOOSE shall be capable of solving a coupled nonlinear diffusion problem using an Eigen value solver.
1.11.10The EigenKernel object shall be capable of using coupled variables.
1.11.11MOOSE shall support adaptive solves for steady-state execution.
1.11.12MOOSE shall be able to detect steady state conditions during execution.
1.11.13MOOSE shall be capable of solving a steady state diffusion problem.
1.11.14MOOSE shall be capable of solving a transient diffusion problem.
1.11.15MOOSE shall print automatic scaling factors if specified.
1.11.16MOOSE shall not print automatic scaling factors if not specified.
1.11.17
MOOSE shall provide a cability to solve a problem iteratively with a tagged residual vector for
1. linear and
2. nonlinear problems.
1.11.18
MOOSE shall provide a capability to solve a problem iteratively with a tagged solution vector being coupled in
1. kernels and/or
2. materials.
1.11.19MOOSE shall correctly compute Jacobians when boundary conditions are disabled.
1.11.20The Executioner system shall support the PETSc non-linear divergence tolerance.
1.11.21The system shall consider a nonlinear solve diverged if the nonlinear residual exceeds the absolute divergence tolerance while iterating
1.11.22The system shall perform n non linear iterations before checking for non linear divergence
1.11.23MOOSE shall force the prescribed number of non linear iterations even if convergence tolerance is already satisfied.
1.11.24The system shall consider a nonlinear solve diverged if the nonlinear residual oscillates by a user-controlled number of times.
1.11.25MOOSE shall compute the solution of rank-deficient linear equations if the right hand side is within the range of the linear operator.
1.11.26MOOSE 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.
1.11.27Executioner objects shall be capable of coupling to Postprocessor values.
1.11.28MOOSE shall correctly evaluate Jacobians with coupled problems and the LINEAR solve type
1.11.29MOOSE shall not change the system time during steady-state execution.
1.11.30MOOSE shall be able to set the system time for steady-state execution.
1.11.31MOOSE shall support controlling what objects are executing based on start and end times.
1.11.32MOOSE shall support explicit definition of execution times.
1.11.33MOOSE shall support output using a time interval.

framework: Fixedbugs
1.12.1The Material objects provided on all subdomains shall satisfy requests for objects on all subdomains.

framework: Functions
1.13.1Generate the fine tabulated function data for the coarsened_piecewise_linear test
1.13.2The Function system shall include an object that creates a function based on x- and y-data pairs, reduces the number of data points based on a user supplied cut-off and returns a linearly interpolated value from the coarsened data.
1.13.3The Function system shall include a constant function.
1.13.4The Function system shall include the ability to set default values for input parameters expecting a function name.
1.13.5The Function system shall include the ability to read comma or space separated data and perform linear interpolation using the supplied data.
1.13.6MOOSE shall include an InitialCondition object capable of setting values base on a supplied function.
1.13.7The Function object shall include a callback executed during each timestep.
1.13.8The Material system shall support defining properties within the input file that are associated with functions.
1.13.9The system shall allow for piecewise functions to directly set the x and y data internally.
1.13.10
The system shall include the ability to create functions from image files that errors if
1. an unsupported file type is provided;
2. if an invalid component value is supplied;
3. if an invalid filename is provided; and
4. the system is not configured with the correct dependencies.
1.13.11MOOSE shall include the ability to define a function based on a 2D image and initialize a nodal variable.
1.13.12MOOSE shall include the ability to define a function based on a 2D image and initialize a elemental variable.
1.13.13MOOSE shall include the ability to define a function based on a stack of images and initialize a nodal variable.
1.13.14MOOSE shall include the ability to define a function based on a subset stack of images and initialize a nodal variable.
1.13.15The ImageFunction object shall allow the image data to be set as one of two values based on a threshold value.
1.13.16MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data.
1.13.17MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data, in parallel.
1.13.18MOOSE 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.
1.13.19The ImageFunction object shall be capable of limiting the supplied data to a single component of the RGB image data.
1.13.20The ImageFunction object shall be capable of shifting and scaling the supplied data.
1.13.21The ImageFunction object shall be capable of operating on domains that are larger than the image size.
1.13.22The ImageFunction object shall be capable of flipping the data along the vertical axis.
1.13.23The ImageFunction object shall be capable of flipping the data along vertical axis and shifting the origin.
1.13.24The ImageFunction object shall be capable of flipping the data along vertical and horizontal axis.
1.13.25The ImageFunction object shall be capable of operating on domains that are smaller than the image size.
1.13.26The ImageMesh object shall be capable of generating a 3D mesh based on a stack of 2D images.
1.13.27The ImageMesh object shall be capable of generating a 2D mesh based on an image.
1.13.28The ImageFunction shift and scale options shall operate independently.
1.13.29The LinearCombinationFunction shall report an error if the parameters listing the functions differs in size than the list of coefficients.
1.13.30The LinearCombinationFunction shall be capable of computing the sum of function values, each multiplied by a scale factor.
1.13.31The LinearCombinationFunction shall be capable of computing the sum of function gradients, each multiplied by a scale factor.
1.13.32The LinearCombinationFunction shall be capable of computing the sum of vector functions, each multiplied by a scale factor.
1.13.33The Function system shall support the creation of objects that execute a function defined within the input file.
1.13.34The ParsedFunction object shall be capable of defining function within the input file for use with the method of manufactured solutions.
1.13.35The Function system shall support the creation of objects that execute a vector function defined within the input file.
1.13.36The Function system shall support the creation of objects that execute a function defined within the input file that includes a scalar variable.
1.13.37The ParsedFunction object shall support the use of other functions specified by their names in its expression.
1.13.38The ParsedFunction object shall support the use of functions, scalar values and postprocessor values specified by their names in its expression at the same time.
1.13.39The Function system shall support the creation of objects that execute a curl of a vector function defined within the input file.
1.13.40The ParsedFunction object shall fail with a human readable error if a vals entry is supplied that is neither a valid postprocessor, scalar variable, function, or real number.
1.13.41The 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).
1.13.42The PiecewiseMultilinear object will error if the supplied file fails to open.
1.13.43The PiecewiseMultiInterpolation object shall error if the supplied data is not monotonically increasing.
1.13.44The PiecewiseMultiInterpolation object shall error if the number of requested functions differ than the number available from the file.
1.13.45The PiecewiseMultiInterpolation errors if the axes supplied are not independent.
1.13.46The PiecewiseMultilinear shall error if the axis lines are not located in the supplied data.
1.13.47The PiecewiseMultilinear object shall perform interpolation on a 1D domain.
1.13.48The PiecewiseMultilinear object shall perform interpolation on a 1D domain that compares to an equivalent known function.
1.13.49The PiecewiseMultilinear object shall perform interpolation of time-dependent data.
1.13.50The PiecewiseMultilinear object shall perform interpolation on a 2D domain.
1.13.51The PiecewiseMultilinear object shall perform interpolation on a 2D domain that compares to an equivalent known function.
1.13.52The PiecewiseMultilinear object shall perform constant interpolation on a 2D domain.
1.13.53The PiecewiseMultilinear object shall perform interpolation on a 3D domain with time-dependent data.
1.13.54The Function object shall support the ability to couple Postprocessor values.
1.13.55The SolutionFunction object shall be capable of evaluating a solution read from XDA mesh and solution files.
1.13.56The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file with temporal interpolation.
1.13.57The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file.
1.13.58The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the z-axis.
1.13.59The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the y-axis.
1.13.60The 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.
1.13.61The 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.
1.13.62The 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.
1.13.63The 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.
1.13.64The SolutionFunction object shall error if a variable that does not exist is requested.
1.13.65
The system shall be capable of evaluating the gradient of a solution
1. created in a simulation
2. and read from another.
1.13.66The VectorPostprocessorFunction shall be capable of linear interpolating data generated by a VectorPostprocessor object.
1.13.67The VectorPostprocessorFunction shall be capable of linear interpolating data generated by a VPP with respect to time.

framework: Fvbcs
1.14.1The system shall run a simple 1D diffusion problem with a Neumann BC value.
1.14.2The system shall error out if a finite volume flux boundary condition, in this case a finite volume Neumann boundary condition, is used inside the domain.
1.14.3The system shall error out if a finite volume flux boundary condition is used on a mesh element face that is not connected to an element with the corresponding finite volume variable.
1.14.4The system shall run a simple 1D diffusion problem with a Dirichlet BC value set by a postprocessor.

framework: Fviks
1.15.1The system shall error if a user specified variable on the 1st side of an interface does not actually exist on the 1st side.
1.15.2The system shall error if a user specified variable on the 2nd side of an interface does not actually exist on the 2nd side.
1.15.3The system shall error if a user does not specify a variable on the 2nd side of an interface, leading the system to assume that the variable on the 1st side of the interface should be used on the 2nd side, and the variable on the 1st side does not exist on the 2nd side.
1.15.4
The system shall be able to solve a diffusion problem with finite volumes with the domain split in half and show first order convergence due to its treatment of coefficient discontinuities both
1. with an interfacing object
2. without an interfacing object

framework: Fvkernels
1.16.1The system shall support block restriction of finite volume variables and kernels, and shall properly handle material evaluation in block-restricted settings, in a one-dimensional example.
1.16.2The system shall return a warning in non-optimized modes if a user supplies a material property with the same name from different block-restricted materials on neighboring subdomains when there are different sets of finite volume flux kernels on those same neighboring subdomains. This is because we have to support ghosting of material properties for block restricted finite volume flux kernels.
1.16.3The system shall support simultaneous block restriction of finite volume and finite element variables and have coupling of the finite volume variables into the finite element equations.
1.16.4The system shall compute a perfect Jacobian when coupling block-restricted finite volume variables into block-restricted finite element calculations.
1.16.5The system shall allow different materials to define the same material property name on different sides of an interface when the finite volume physics is the same on both sides of the interface.
1.16.6The system shall compute a perfect Jacobian when different materials define the same material property on different sides of a interface and the finite volume physics are the same on both sides of the interface.
1.16.7The system shall error if a user attempts to couple both finite volume and finite element variables into the same material.
1.16.8The system shall support coupling of a finite volume variable into a finite element calculation.
1.16.9The system shall compute a perfect Jacobian when coupling a finite volume variable into a finite element calculation.
1.16.10The system shall error in non-optimized modes if material dependencies for finite volume computations are not satisfied.
1.16.11The system shall suggest that the user add a finite volume variable if a finite volume object cannot retrieve one
1.16.12The system shall be able to perform finite volume simulations with adaptivity and give correct results
1.16.13The system shall display first order convergence when there is significant skewness in the mesh due to mismatch between cell levels.
1.16.14The system shall be able to solve the Burgers equation in 1D using the FV method
1.16.15The system shall run a 2D linear advection problems using the finite volume method a regular mesh.
1.16.16
The system shall be able to produce correct mathematical results for a coupled-reaction problem
1. using both finite element and finite volume discretizations with
2. the correct Jacobian entries.
1.16.17The system shall be able to couple variables at faces when using the finite volume method.
1.16.18The system shall have an accurate Jacobian when coupling variables at faces and using the finite volume method.
1.16.19The system shall run a simple 2D linear diffusion problem using the finite volume method with Dirichlet boundary conditions on a regular mesh.
1.16.20The system shall run a simple 2D linear diffusion problem in RZ coordinates using the finite volume method with Dirichlet boundary conditions on a regular mesh.
1.16.21The system shall be able to compute a full Jacobian matrix when performing finite volume computations
1.16.22The system shall run a simple 2D linear diffusion problem using the finite volume method with Neumann and Dirichlet boundary conditions on a regular mesh.
1.16.23The system shall run a simple 2D transient linear diffusion problem using the finite volume method with Dirichlet boundary conditions on a regular mesh.
1.16.24
The system shall be able to solve a finite-volume-only problem
1. on an unrefined mesh
2. and on a mesh that has been refined to have the same amount of elements and achieve identical results
1.16.25The system shall be able solve a three-dimensional diffusion problem using the finite volume method.
1.16.26The system shall be able solve a one-dimensional diffusion problem using the finite volume method.
1.16.27The system shall correctly account for differences between gradient and divergence operators in cylindrical coordinates.
1.16.28The system shall be able to to solve an advection-diffusion equation with a dirichlet condition on the left boundary and a zero gradient condition on the right boundary and display second order convergence with the finite volume method.
1.16.29The system shall, while using an advective outflow boundary condition, demonstrate second order convergence if a two term Taylor series is used to approximate the face value and first order convergence if a one term Taylor series is used.
1.16.30The system shall be able to do one-term and two-term Taylor expansions for extrapolating finite volume solutions to boundary faces, and these extrapolations should be usable by flux kernels at inflow/outflow boundaries to produce first and second order accurate solutions respectively as measured by an L2 norm.
1.16.31The system shall be able to solve the diffusion equation in 2D axisymmetric coordinates using the finite volume method, and display a second order convergence rate.
1.16.32The system shall be able to solve a pure advection problem in 1D cylindrical coordinates using the finite volume method, and display a second order convergence rate.
1.16.33The system shall be able to solve a advection-reaction problem in 2D axisymmetric coordinates using the finite volume method, and display a second order convergence rate.
1.16.34The system shall be able to solve a advection-diffusion-reaction problem in 2D axisymmetric coordinates using the finite volume method, and display a second order convergence rate.
1.16.35The system shall be able to implement advection through an element based kernel, that leverages the system's ability to reconstruct gradients, and demonstrate second order convergence on a cartesian coordinate system.
1.16.36The system shall be able to retrieve and usefinite volume variable gradients in materials using a coupling interface and reproduce element-based advection results based on direct use of the variable gradient in a Cartesian coordinate system.
1.16.37The system shall be able to implement advection through an element based kernel, that leverages the system's ability to reconstruct gradients, and demonstrate second order convergence in an axisymmetric coordinate system.
1.16.38The system shall be able to retrieve and usefinite volume variable gradients in materials using a coupling interface and reproduce element-based advection results based on direct use of the variable gradient in an axisymmetric coordinate system.
1.16.39The system shall be able to implement advection through an element based kernel, that leverages the system's ability to reconstruct gradients using an extended stencil based on point-neighbors, and demonstrate second order convergence in a cartesian coordinate system.
1.16.40The system shall be able to solve a coupled mass and momentum-type two equation system, which includes advection and diffusion, using the finite volume method, and display second order convergence for both variables.
1.16.41The system shall display second order convergence, when using face side neighbors to compute face midpoint values during gradient reconstruction.
1.16.42The system shall display 1.5 order convergence, when using face vertex neighbors to compute face midpoint values during gradient reconstruction.
1.16.43The system shall be able to solve a diffusion problem with the finite volume method and display second order convergence.
1.16.44The system shall be able to solve a advection-diffusion problem with the finite volume method and display second order convergence.
1.16.45The system shall be able to solve a advection-diffusion problem with the finite volume method, using a velocity supplied by a material, and display second order convergence.
1.16.46The system shall be able to solve a advection problem with the finite volume method and display second order convergence.
1.16.47The system shall be able to solve a advection problem with the finite volume method, using a velocity supplied by a material, and display second order convergence.
1.16.48The system shall be able to solve a advection-diffusion problem with the finite volume method and display first order convergence with an upwind scheme for the advection operator.
1.16.49The system shall be able to solve a advection problem with the finite volume method and display first order convergence with an upwind scheme.
1.16.50The system shall be able to identify and show when a matrix is ill conditioned.
1.16.51The system shall be able to condition a system automatically through variable scaling factors.
1.16.52The system shall be able to condition a system manually through variable scaling factors.
1.16.53The system shall be able to sequentially apply manual and automatic scaling and in the case of poor manual scaling, restore the condition number automatically.
1.16.54The system shall be able to run a flux boundary condition and a flux kernel for different variables on the same boundary and calculate correct function and Jacobian values.

framework: Geomsearch
1.17.1MOOSE shall be capable of computing the distance between two disjoint boundaries on a 1D domain.
1.17.2MOOSE shall be capable of computing the distance as well as transfer data between interior boundaries on a 2D domain.
1.17.3The 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.
1.17.4The 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.
1.17.5The 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.
1.17.6The 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.
1.17.7The 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.
1.17.8The 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.
1.17.9The 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.
1.17.10The 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.
1.17.11The 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.
1.17.12The 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.
1.17.13The 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.
1.17.14The 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.
1.17.15The 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.
1.17.16The 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.
1.17.17The 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.
1.17.18The 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.
1.17.19The 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.
1.17.20The 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.
1.17.21The 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.
1.17.22The 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.
1.17.23The 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.
1.17.24The 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.
1.17.25The 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.
1.17.26The 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.
1.17.27
The systems shall be capable of performing simulations with geometric penetration
1. computed within one simulation
2. that are restarted from a another.
1.17.28The 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.
1.17.29The 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.
1.17.30The 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.
1.17.31The 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.
1.17.32The 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.
1.17.33The 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.
1.17.34The 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.
1.17.35The 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.
1.17.36The 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.
1.17.37The 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.
1.17.38The 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.
1.17.39The 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.
1.17.40The 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.
1.17.41The 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.
1.17.42The 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.
1.17.43The 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.
1.17.44
The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two disjoint surfaces:
1. with nodal normal based smoothing;
2. with nodal normal based smoothing and a specified tangential tolerance;
3. with a specified normal smoothing distance;
4. with a specified normal smoothing distance and a specified tangential tolerance;
5. with second-order elements and third-order quadrature; and
6. with second-order elements and third-order quadrature and a specified tangential tolerance.
1.17.45
The PenetrationAux object shall be capable of computing the distance, tangential distance, normal, closest point, side id, and element id between two overlapping surfaces:
1. with nodal normal based smoothing;
2. with nodal normal based smoothing and a specified tangential tolerance;
3. with a specified normal smoothing distance;
4. with a specified normal smoothing distance and a specified tangential tolerance;
5. with second-order elements and third-order quadrature; and
6. with second-order elements and third-order quadrature and a specified tangential tolerance.
1.17.46The 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.
1.17.47The 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.
1.17.48The NearestNodeDistanceAux object shall be capable of computing the shortest distance between a boundary and subdomain.
1.17.49The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries.
1.17.50The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries with adaptivity.
1.17.51MOOSE shall support a means for updating the geometric search patch dynamically that may be disabled.
1.17.52MOOSE shall support a means for updating the geometric search patch dynamically that automatically determines when an update to the patch shall occur.
1.17.53MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each solve.
1.17.54MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each iteration.
1.17.55The MOOSE penetration locator system shall error if penetration is not detected.
1.17.56The system shall be able to perform patch updates on every non-linear iteration while performing uniform coarsening and refinement from grid sequencing
1.17.57The PenetrationAux object shall compute the distance between two boundaries in 3D that overlap.
1.17.58The PenetrationAux object shall compute, in parallel, the distance between two boundaries in 3D that overlap.
1.17.59The nonlinear system shall be able to augment its sparsity based on constraints when we have a quadrature nearest-node locator.
1.17.60The NearestNodeDistanceAux object shall compute the shortest distance between nodes on two overlapping boundaries using a constant monomial auxiliary variable.
1.17.61Volumetric AD assembly data shall be properly sized when reinitializing faces
1.17.62The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable.
1.17.63The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable in 1D.

framework: Globalparams
1.18.1The system shall include an input file syntax that supports defining global options.

framework: Ics
1.19.1The system shall allow to set initial conditions for an array variable based on functions.
1.19.2The system shall support setting initial conditions on boundaries.
1.19.3Generates a rectangular IC
1.19.4BoundingBoxIC shall have a diffuse interface option.
1.19.5The system shall report an error when multiple initial conditions are applied to the same boundary.
1.19.6The system shall report an error when multiple initial conditions are applied to the same subdomain.
1.19.7The system shall report an error when a global initial conditions overlap on the same variable.
1.19.8The system shall report an error when a global and subdomain restricted initial conditions overlap on the same variable.
1.19.9The system shall support setting different values for each coefficient of higher-order scalar values.
1.19.10The system shall support setting initial conditions of field variables to a constant value.
1.19.11The system shall support setting initial conditions of subdomain restricted field variables to a constant value.
1.19.12The system shall provide current node or element pointers when possible when evaluating initial conditions at a point in the domain.
1.19.13The system shall allow setting field initial condition from an user object
1.19.14The system shall allow setting scalar initial condition from an user object
1.19.15The system shall allow nodal initial condition objects to couple to other nodal variables for computing values for the current variable.
1.19.16The system shall allow elemental initial condition objects to couple to other elemental variables for computing values for the current variable.
1.19.17The system shall write output files containing nodal solutions in ExodusII format suitable for restart.
1.19.18The system shall be able to populate nodal initial conditions from a previous solution file in ExodusII format.
1.19.19The system shall write output files containing elemental solutions in ExodusII format suitable for restart.
1.19.20The system shall be able to populate elemental initial conditions from a previous solution file in ExodusII format.
1.19.21The system shall write output files containing elemental array variable solutions in ExodusII format suitable for restart.
1.19.22The system shall be able to populate elemental array variable initial conditions from a previous solution file in ExodusII format.
1.19.23The system shall write output files containing nodal array variable solutions in ExodusII format suitable for restart.
1.19.24The system shall be able to populate nodal array variable initial conditions from a previous solution file in ExodusII format.
1.19.25The system shall support setting gradient values for shape functions that support them.
1.19.26The system shall support using a spline function to set both value and gradient values in an initial condition.
1.19.27The system shall support setting a scalar initial condition by evaluating a function.
1.19.28The system shall support setting initial conditions for the Hermite set of shape functions.
1.19.29The system shall support initial conditions on second order Lagrange variables in 3D space.
1.19.30MOOSE shall allow initial conditions to retrieve post-processor values.
1.19.31MOOSE shall generate parallel agnostic random initial conditions
1.19.32MOOSE shall generate threaded agnostic random initial conditions
1.19.33The system shall allow to set constant vector-valued initial conditions.
1.19.34The system shall allow to set constant vector-valued initial conditions when adding vector variables.
1.19.35The system shall allow vector-valued initial conditions be set using a vector function.
1.19.36The system shall allow vector-valued initial conditions be set using a function by components.
1.19.37The system shall error if the 'function' and 'function_x' parameters are both set within the VectorFunctionIC object.
1.19.38The system shall error if the 'function' and 'function_y' parameters are both set within the VectorFunctionIC object.
1.19.39The system shall error if the 'function' and 'function_z' parameters are both set within the VectorFunctionIC object.
1.19.40The system should supply a special convenience "zero" variable that can be indexed like a normal coupled variable.

framework: Indicators
1.20.1The system shall include the ability to compute the square of the difference between a solution variable and an analytical function for the purpose of performing automatic mesh adaptivity.
1.20.2The system shall include the ability to compute the square of the difference between a FV solution variable and an analytical function for the purpose of performing automatic mesh adaptivity.
1.20.3The system shall include the ability to compute the square of the change in the gradient of a variable across element boundaries for the purpose of performing automatic mesh adaptivity.
1.20.4
The system shall include the ability to compute the square of the change in the Laplacian of a variable across element boundaries for the purpose of performing automatic mesh adaptivity:
1. with a penalty based flux boundary condition;
2. with a weakly imposed flux boundary condition; and
3. for transient calculations.
1.20.5The system shall include the ability to compute the square of the change in a variable across element boundaries for the purpose of performing automatic mesh adaptivity:
1.20.6The system shall include the ability to compute the square of the change in a FV variable across element boundaries for the purpose of performing automatic mesh adaptivity:

framework: InterfaceKernel Objects
1.21.1Interface kernels shall provide integrated conditions between subdomains, and shall work with boundary restricted materials with stateful properties.
1.21.2The interface diffusion penalty method should reproduce the analytic solution
1.21.3The InterfaceKernel system shall use with interface material in 1D.
1.21.4The system shall support the evaluation of neighboring quantities on elements containing different shape functions.
1.21.5The system shall produce correct Jacobians for coupled flux on an interface.
1.21.6The system shall support produce correct Jacobians when evaluating neighboring quantities on elements containing different shape functions.
1.21.7The system shall produce correct Jacobians for single variable coupled flux on an interface.
1.21.8Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side a (block 0) of the interface.
1.21.9Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side b (block 1) of the interface.
1.21.10The interface reaction kernel should reproduce the analytic solution
1.21.11The interface reaction kernel should work with interface diffusion kernel
1.21.12The solution should be discontinued at the interface due to the reaction taking place
1.21.13The Jacobian from InterfaceReaction shall be perfect
1.21.14The system shall ensure that interfacial materials are sorted such that consumers execute after producers.
1.21.15The InterfaceKernel system shall operate with coupled variables in 2D. This uses a penalty implementation that is optimally convergent.
1.21.16Allow the interface to impose the same time derivative on two neighboring variables. This uses a penalty implementation that is optimally convergent.
1.21.17The InterfaceKernel system shall use with interface material in 2D.
1.21.18The Jacobian evaluation for InterfaceKernel objects in 2D shall be analytically correct.
1.21.19The finite difference preconditioner shall work in parallel.
1.21.20The InterfaceKernel system shall support Vector Finite Elements in 2D.
1.21.21The system shall not perform memory allocation for automatic scaling when computing values.
1.21.22The InterfaceKernel system shall operate with coupled variables in 3D. This uses a penalty implementation that is optimally convergent.
1.21.23The InterfaceKernel system shall support Vector Finite Elements in 3D.
1.21.24The InterfaceKernel system shall use with interface material in 3D.
1.21.25The system shall be able to solve a simple interfacial source problem using automatic differentiation in which the slope on the left-hand side of the interface has a slope greater by two than the slope on the right-hand side.
1.21.26The system shall be able to couple variables at interfaces and have an accurate Jacobian provided through automatic differentiation.
1.21.27The system shall be able to solve a simple interfacial source problem using automatic differentiation and vector variables in which the slope on the left-hand side of the interface has a slope greater by two than the slope on the right-hand side.
1.21.28The system shall be able to couple vector variables at interfaces and have an accurate Jacobian provided through automatic differentiation.
1.21.29Adaptivity shall work with interface kernels as long as stateful properties are not used.
1.21.30The system shall error if the triad of interface kernels, adaptivity, and stateful properties are used together.
1.21.31The system shall be able to execute interfacial conditions on sidesets generated by gmsh.
1.21.32When computing residuals and jacobians on an interface, the system shall be able to use element information from the displaced mesh when requested
1.21.33When computing residuals and jacobians on an interface, the system shall be able to use element information from the reference mesh
1.21.34During mesh displacement, the system shall be able to compute different element Jacobians for different sides of an interface.

framework: Interfaces
1.22.1The system shall build a bijective map between variable numbers and their couple variable indices.
1.22.2
The system shall report a reasonable error when requesting a Postprocessor from a parameter when
1. the parameter is not found,
2. the parameter does not represent a Postprocessor,
3. the parameter is a single Postprocessor value and a greater index than zero is requested,
4. and the parameter is a single Postprocessor value and a greater index than zero is requested.
1.22.3The system shall report a reasonable error when requesting a Postprocessor name from a parameter in which the postprocessor is a default value and not a name.
1.22.4
The system shall report a reasonable error when it is too early to request if a postprocesor exists
1. by parameter name and
2. by Postprocessor name.
1.22.5
The system shall report a reasonable error when requesting a Postprocessor value
1. by parameter and the Postprocessor does not exist and
2. by Postprocessor name and the Postprocessor does not exist.
1.22.6The system shall produce parallel-agnostic random number fields on a single processor.
1.22.7The system shall produce parallel-agnostic random number fields on two or more processors.
1.22.8The system shall produce parallel-agnostic random number fields on two or more threads.
1.22.9The system shall produce a parallel field without repeating patterns on distributed meshes.
1.22.10The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system.
1.22.11The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system on two or more processors.
1.22.12The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system on two or more threads.
1.22.13The system shall produce a parallel field without repeating patterns via the user defined (UserObject) system.
1.22.14The system shall produce a parallel-agnostic random number via the material system.
1.22.15The system shall produce a parallel-agnostic random number via the material system on two or more processors.
1.22.16
The system shall report a reasonable error when requesting a Reporter value from a parameter when
1. the parameter is not found and
2. the parameter does not represent a Reporter
1.22.17The system shall report a reasonable error when requesting a Reporter value when a Reporter with the same name exists with a different type.
1.22.18
The system shall report a reasonable error when requesting a Reporter value
1. by parameter and the Reporter value does not exist and
2. by Reporter name and the Reporter value does not exist.
1.22.19
The system shall report a reasonable error when it is too early to request if a Reporter value exists
1. by parameter name and
2. by Reporter name.
1.22.20
The system shall report a reasonable error when requesting a UserObject when
1. getting the name from a parameter and the parameter is not found,
2. getting the name from a parameter and the parameter does not represent a name,
3. getting the name from a parameter and the user object is not found,
4. getting the UserObject by name and the user object is not found,
5. getting the name from a paremeter and the provided object is not of the correct type, and
6. getting the UserObject by name and the provided object is not of the correct type.
1.22.21
The system shall report a reasonable error when requesting a VectorPostprocessor value from a parameter when
1. the parameter is not found and
2. the parameter does not represent a VectorPostprocessor.
1.22.22
The system shall report a reasonable error when it is too early to request if a VectorPostprocessor exists
1. by vector name and parameter name,
2. by vector name and VectorPostprocessor name,
3. by parameter name, and
4. and by VectorPostprocessor name.
1.22.23
The system shall report a reasonable error when requesting a VectorPostprocessor value
1. by parameter and the VectorPostprocessor does not exist,
2. by parameter and the VectorPostprocessor exists but the requested vector does not,
3. by VectorPostprocessor name and the VectorPostprocessor does not exist, and
4. by VectorPostprocessor name and the VectorPostprocessor exists but the requested vector does not.

framework: Kernels
1.23.1MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions.
1.23.2MOOSE shall provide an ability to solve a 2D diffusion problem with Neumann boundary conditions.
1.23.3MOOSE shall provide a diffusion kernel that obtains the diffusion coefficient from a material property
1.23.4MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term.
1.23.5MOOSE shall provide a tester that checks hand-coded Jacobian against finite difference Jacobian using -snes_type=test option.
1.23.6MOOSE shall force the solver to take at least one iteration regardless of the initial residual norm when the snes_force_iteration option is specified.
1.23.7MOOSE should not compute an extra residual if the linear solver is used
1.23.8
MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions using
1. automatic differentiation and
2. compute the correct Jacobian matrix.
1.23.9
MOOSE shall provide an ability to solve a 2D diffusion problem Neumann boundary conditions using
1. automatic differentiation and
2. compute the correct Jacobian matrix.
1.23.10
MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term using
1. automatic differentiation and
2. compute the correct Jacobian matrix.
1.23.11Coupled variable gradient Jacobian entries generated with AD shall be accurate
1.23.12Coupled variable value Jacobian entries generated with AD shall be accurate
1.23.13We shall be able to get aux variable values through adCoupledValue with the knowledge that the derivatives will always be zero
1.23.14Getting a constant aux variable through adCoupledValue shall not destroy our Jacobian
1.23.15We shall be able to get dot aux variable values through adCoupledValue with the knowledge that the time derivatives will always be zero
1.23.16The system will output the required number of derivative entries needed for automatic differentiation calculations
1.23.17The system shall automatically generate a full coupling matrix when doing global AD indexing such that there are no new matrix memory allocations.
1.23.18The system shall automatically generate a full coupling matrix when doing global AD indexing, resulting in a perfect Jacobian even when the user has not requested full coupling.
1.23.19The system shall allow the user to override the automated generation of a full coupling matrix when doing global AD indexing, which for this test results in a new nonzero allocation because there is off-diagonal coupling.
1.23.20Jacobians calculated by ADTimeDerivative and ADBodyForce shall be perfect.
1.23.21
The system shall solve a one-dimensional Diffusion problem with a material property diffusivity and match a known solution.
1. without and
2. with automatic differentiation including
3. the correct Jacobian matrix.
1.23.22
The system shall solve a two-dimenional Diffusion problem with a material property diffusivity and match a known solution.
1. without and
2. with automatic differentiation including
3. the correct Jacobian matrix.
1.23.23The system will error and tell the user if they use derivative storage that is too small
1.23.24Jacobian entries generated with AD for a simple diffusion problem shall be accurate
1.23.25
The system shall be able to solve a transient diffusion problem with
1. automatic differentiation and
2. compute the correct Jacobian matrix.
1.23.26
The system shall be able to solve a transient diffusion problem with vector variables
1. automatic differentiation and
2. compute the correct Jacobian matrix.
1.23.27Jacobian entries generated with AD shall match hand-coded Jacobian entries as measured through save-in values
1.23.28The system shall provide a generic kernel object that allows for easy switching between hand-coded and automatic computation of the Jacobian, and encourages maximum kernel code-reuse.
1.23.29The system shall support coupling of variables with automatic differentiation and vector values.
1.23.30The system shall support coupling to the gradient of variables with automatic differentiation and vector values.
1.23.31The system shall support coupling of default values for variables with automatic differentiation and vector values.
1.23.32
The system shall run a coupled diffusion-advection problem with higher-order variables on a non-regular mesh domain:
1. in a steady-state calculation, and
2. in a transient calculation.
1.23.33The system shall support direct tensor-vector products and vector dot products to maintain dimension agnostic formulations where possible.
1.23.34MOOSE shall provide array diffusion kernels on an array variable.
1.23.35MOOSE shall provide array reaction kernels on an array variable.
1.23.36MOOSE shall provide array DG diffusion kernels on an elemental array variable.
1.23.37MOOSE shall provide coupling of standard variables in array kernels.
1.23.38MOOSE shall provide coupling of array variables in standard kernels.
1.23.39
MOOSE shall provide residual save-in and Jacobian diagonal save-in for
1. array and
2. standard variables.
1.23.40MOOSE shall provide array time derivative kernels on an array variable.
1.23.41MOOSE shall provide array body-force kernels on an array variable.
1.23.42We shall be able to show that without automatic scaling, this system is singular
1.23.43We shall be able to show that with automatic scaling, this system is non-singular
1.23.44We shall be able to show that with automatic scaling we can run this problem successfully in parallel
1.23.45
The system shall support the ability to apply a kernel to a subset of the domain
1. through a subdomain restriction on the kernel, and
2. through a subdomain restriction on the variable.
1.23.46The system shall support scaling the computed time derivative by a scalar coefficient.
1.23.47
The system shall include the ability to compute the residual contribution from the conservative form of the advection operator
1. without upwinding in 3D,
2. with upwinding in 3D,
3. without upwinding in 1D,
4. with upwinding in 1D,
5. without upwinding in 2D,
6. with upwinding in 2D,
7. with upwinding and an outflow boundary condition, and
8. without any outflow boundary conditions.
1.23.48A coupled time derivative kernel shall be provided
1.23.49A coupled time derivative kernel with forward mode automatic differentiation shall be provided
1.23.50A coupled time derivative kernel compatible with vector variables with hand-coded jacobians shall be provided
1.23.51The Jacobian from VectorCoupledTimeDerivative shall be perfect
1.23.52The SMP Jacobian for a problem with a hanging-node shall be non-singular
1.23.53The colored finite difference Jacobian for a problem with a hanging-node shall be non-singular
1.23.54The standard finite difference Jacobian for a problem with a hanging-node shall be non-singular
1.23.55A matrix-free operator shall be able to solve the hanging-node problem, indicating it is non-singular
1.23.56The SMP Jacobian shall be perfect for the hanging-node problem
1.23.57The system shall compute a perfect Jacobian via automatic differentiation for a hanging-node problem and simultaneously handle automatic differentiation objects that do not actually have nonlinear variable dependence.
1.23.58The system shall support applying a function of space-time as a forcing function to the mesh domain.
1.23.59The system shall report an error when a parsed function expression contains quote characters.
1.23.60The system shall support hybrid finite element method (HFEM) calculations with Dirichlet boundary conditions using standard variables.
1.23.61The system shall support hybrid finite element method (HFEM) calculations with Dirichlet boundary conditions using array variables.
1.23.62The system shall support hybrid finite element method (HFEM) calculations with Neumann boundary conditions using standard variables.
1.23.63The system shall support hybrid finite element method (HFEM) calculations with Neumann boundary conditions using array variables.
1.23.64The system shall support hybrid finite element method (HFEM) calculations with Robin boundary conditions using standard variables.
1.23.65The system shall support hybrid finite element method (HFEM) calculations with Robin boundary conditions using array variables.
1.23.66The system shall support hybrid finite element method (HFEM) calculations with high order shape functions.
1.23.67The system shall support hybrid finite element method (HFEM) calculations with Robin boundary conditions through Lagrange multipliers.
1.23.68The system shall support hybrid finite element method (HFEM) calculations with displaced meshes.
1.23.69The system shall issue an error for unsupported mesh adaptation with hybrid finite element method (HFEM) calculations.
1.23.70The system shall support hybrid finite element method (HFEM) calculations with Dirichlet boundary conditions with boundary values specified by variables.
1.23.71The system shall issue an error for not fully supported distributed mesh with hybrid finite element method (HFEM) calculations.
1.23.72We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements
1.23.73We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements
1.23.74We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a cylindrical geometry
1.23.75We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a cylindrical geometry
1.23.76We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a spherical geometry
1.23.77We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a spherical geometry
1.23.78MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out.
1.23.79MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out in the automatic differentiation system.
1.23.80The Jacobian for the automatic differentiation problem shall be perfect
1.23.81The system shall support the ability to use mass lumping for time derivative terms.
1.23.82The system shall verify that the Jacobian terms when using mass lumping for time derivative terms are computed correctly.
1.23.83The system shall support a kernel for coupling the sum of several products of material properties with variables and constant coefficients
1.23.84The system shall have the ability to declare the derivatives of material properties.
1.23.85The system shall have the ability to verify individual Jacobian contributions before they are scaled by other finite element factors in the system.
1.23.86The system shall support solving Ordinary Differential Equations in explicit form.
1.23.87The system shall support solving Ordinary Differential Equations in implicit form.
1.23.88The system shall support solving ODEs specified within the input file through parsed function syntax.
1.23.89The system support coupling of postprocessor values in the parsed function ODE kernel.
1.23.90The system shall support solving Coupled Ordinary Differential Equations.
1.23.91The system shall allow scalar variable initial condition to be loaded from a file mesh
1.23.92The system shall allow auxscalar variable initial condition to be loaded from a file mesh
1.23.93MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach.
1.23.94MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach when displacements are active.
1.23.95MOOSE shall support the ability to set Dirichlet boundary conditions using the Lagrange multiplier approach.
1.23.96The system shall support retrieving a vector of values in a kernel object for the purpose of computing a residual statement.
1.23.97The system shall run a simple 2D linear diffusion problem with Dirichlet boundary conditions on a regular mesh.
1.23.98MOOSE shall be able to run a transient diffusion problem
1.23.99MOOSE shall not do any mallocs in MatSetValues for simple kernels
1.23.100We shall not be able to solve a problem where the physics Jacobians are very large compared to the jacobian from a Dirichlet BC (unity)
1.23.101We shall be able to solve an initially poorly scaled problem by using MOOSE's automatic scaling feature
1.23.102We shall be able to solve an initially poorly scaled problem by using MOOSE's automatic scaling feature in parallel
1.23.103We shall not be able to solve a problem where the physics has large changes over time if we only scale once
1.23.104We shall be able to solve a problem where the physics has large changes over time if we scale on every time step
1.23.105We shall be able to solve a problem where the physics has large changes over time if we scale on every time step in parallel
1.23.106The system shall error if the volumetric residual calculation is not assigned an associated vector within the numerical solving routine.
1.23.107Time kernel requires a transient executioner
1.23.108The kernel can be only assigned to the existing vector tags in the system
1.23.109The kernel can be only assigned to the existing matrix tags in the system
1.23.110The system shall be able to reproduce the simple_transient_diffusion test with VectorTimeDerivative (hand-coded Jacobian).
1.23.111The Jacobian from VectorTimeDerivative shall be perfect
1.23.112The system shall compute second-order time derivatives for vector variables
1.23.113MOOSE shall be able to solve a curl-curl problem using NEDELEC_ONE elements
1.23.114MOOSE shall be able to couple a vector variable into a standard kernel
1.23.115MOOSE shall be able to assign a default value for a vector variable from the source file
1.23.116MOOSE shall warn when assigning a default value with number of components less than LIBMESH_DIM and it shall be able to assign the default value from the input file
1.23.117MOOSE shall be able to assign a default value for a vector variable from the input file and still have the correct jacobian
1.23.118MOOSE shall be able to solve multi-dimensional problems with LAGRANGE_VEC variables
1.23.119MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables
1.23.120MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables and produce the correct Jacobian
1.23.121MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and reproduce the hand-coded result
1.23.122MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and have a perfect Jacobian
1.23.123MOOSE shall be able to couple a vector variable into a standard kernel and produced the correct Jacobian
1.23.124MOOSE shall be able to couple a standard variable into a vector kernel. Additionally, MOOSE shall be able to calculate time derivatives of variable gradients.
1.23.125MOOSE shall be able to compute the correct Jacobian when coupling a standard variable into a vector kernel and taking time derivatives of variable gradients.
1.23.1261) MOOSE shall be able to assign dirichlet boundary conditions for LAGRANGE_VEC variables 2) MOOSE shall be able to obtain coupled vector variable gradients 3) MOOSE shall correctly initialize both volume and face curl shape functions when the curl of a variable is requested
1.23.127The system shall error if the 'function' and 'function_x' parameters are both set when defining a vector function Dirichlet boundary condition.
1.23.128The system shall error if the 'function' and 'function_x' parameters are both set within the ADVectorFunctionDirichletBC object.

framework: Markers
1.24.1The system shall include the ability to mark a mesh subdomain for uniform refinement.
1.24.2The adaptivity system shall create an auxiliary field variable that marks elements for refinement adjacent to a boundary.
1.24.3The adaptivity system shall create an auxiliary field variable that marks elements for refinement within a given distance of a boundary.
1.24.4The adaptivity system shall create an auxiliary field variable that marks elements for refinement within a rectangular region.
1.24.5The adaptivity system shall adapt the mesh within a rectangular region.
1.24.6The system shall include the ability to combine multiple mesh refinement markers into a single value.
1.24.7The system shall include the ability to mark elements within a subdomain to be unchanged for mesh adaptivity.
1.24.8The system shall include a means for setting mesh refinement flags based on percent of error for a sorted vector of error values computed for each finite element.
1.24.9The system shall include the ability to use the same error extremes during all calculations of error fraction values during mesh adaptivity.
1.24.10The system shall include a means for setting mesh refinement flags based on percent of error for a sorted vector of error values computed for each finite element using FV variables
1.24.11The system shall include a means for computing mesh refinement flags based on an absolute values of error.
1.24.12The system shall include a means for performing mesh adaptivity based on an absolute values of error.
1.24.13It shall not be possible to specify Markers to run on the displaced mesh.
1.24.14The system shall support the ability to mark elements for mesh adaptivity based on a bounding box with arbitrary orientation.
1.24.15The system shall support access to finite element quadrature point locations during the calculation of refinement marker flags.
1.24.16
The system shall support the capability of creating a tool for marking finite elements for mesh refinement, for example:
1. adding elements within the intersection of two circles;
2. adding elements within the intersection of two circles and removing elements outside the circles; and
3. performing adaptivity when a non-uniform initial condition is defined.
1.24.17The system shall support marking the entire finite element mesh for refinement.
1.24.18The system shall include the ability to mark elements within a finite element mesh for adaptivity based on if the value of a variable is within a specific range.
1.24.19The system shall include the ability to mark elements within a finite element mesh for adaptivity based on if the value of a variable is above or below a threshold.

framework: Materials
1.25.1The Jacobian from a material property declared as AD and gotten as AD shall be accurate
1.25.2The Jacobian from a material property declared as regular and gotten as regular shall be inaccurate
1.25.3AD shall work with stateful material properties and the Jacobian shall be beautiful
1.25.4The time evolution of the stateful diffusivity property shall show that AD works with stateful material properties
1.25.5We shall be able to set default values for AD material properties
1.25.6We shall have a perfect Jacobian when using default values for an AD material property
1.25.7For a given dual number, the system shall be able to construct a map from global degree of freedom index to the corresponding derivative
1.25.8ADPiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable
1.25.9PiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable and perform approriate scaling
1.25.10ADPiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation and extrapolation of a variable
1.25.11ADPiecewiseLinearInterpolationMaterial shall throw an error if x, y, and xy_data are all specified
1.25.12ADPiecewiseLinearInterpolationMaterial shall throw an error if x and xy_data are both specified
1.25.13ADPiecewiseLinearInterpolationMaterial shall throw an error if x and y vectors are different lengths
1.25.14ADPiecewiseLinearInterpolationMaterial shall throw an error if xy_data vector is not a multiple of two
1.25.15ADPiecewiseLinearInterpolationMaterial shall calculate perfect Jacobians
1.25.16The system shall provide material properties in boundary restricted objects acting on nodal variables.
1.25.17The system shall provide material properties in boundary restricted objects acting on elemental variables.
1.25.18The system shall provide location dependent boundary material property evaluations with finite volume variables.
1.25.19The system shall issue an error when multiple materials properties with the same name are declared on the same block.
1.25.20
The system shall be capable of producing analytic derivatives of material properties:
1. defined by function expressions,
2. involving chain rules of material properties defined by function expressions, and
3. for the free energy Allen-Cahn Bulk material function.
1.25.21
The system shall support late binding of derivative material properties:
1. so that construction order does not influence the outcome of the tests, and
2. so that construction order does not influence the outcome of the tests when using automatic differentiation, and
3. so that they may be retrieved before being declared.
1.25.22The system shall support supplying a constant literal in place of a property name for material property derivative consumers.
1.25.23The system shall support optional coupling where materials that do not exist are returned as valid objects containing zero.
1.25.24The system shall issue an error when required derivative materials that are retrieved are never declared.
1.25.25
The system shall handle a bad evaluation by
1. passing a silent nan.
2. throwing a warning and passing a silent nan.
3. throwing an error.
4. throwing an exception.
1.25.26
The system shall be capable of couplimng postprocessor values in
1. ParsedMaterial
2. DerivativeParsedMaterialParsedMaterial
3. ADParsedMaterial
4. ADDerivativeParsedMaterial
1.25.27
The system shall be capable of producing analytic derivatives of material properties using dual numbers:
1. returning an exact jacobian.
2. returning an exact jacobian in derivative materials.
3. defined by function expressions,
4. involving chain rules of material properties defined by function expressions, and
1.25.28The system shall create AD material properties even if the derivatives are zero
1.25.29
The system shall support late binding of derivative material properties:
1. so that they may be retrieved before being declared.
1.25.30The system shall support supplying a constant literal in place of a property name for material property derivative consumers that require dual numbers.
1.25.31The system shall support optional coupling where materials that do not exist are returned as valid objects containing zero, supporting dual numbers.
1.25.32The system shall issue an error when required dual number derivative materials that are retrieved are never declared.
1.25.33
The system shall provide a method for summing multiple DerivativeParsedMaterialsand compare exact to a single DerivativeParsedMaterial
1. validating coupling
2. without validating coupling
3. validating coupling using automatic differentiation
4. without validating coupling using automatic differentiation
1.25.34
The system shall support the ability for materials to force immediate execution of other (discrete) materials:
1. for a simple monomial expression, and
2. for a simple polynomial expression.
1.25.35The system shall not calculate materials that are meant to be controlled by other materials (discrete) materials.
1.25.36The system shall issue a warning when a "discrete" material object is retrieved for use in a controlling material but it is set to auto-execute.
1.25.37
The system shall verify that a material being retrieved is defined everywhere that the retrieving material is defined:
1. on compatible blocks, and
2. on compatible boundaries.
1.25.38The system shall issue a warning when a "discrete" material's "reset" method is not defined.
1.25.39
The system shall be able to produce a valid Real material object on the fly for use in calculations requiring material properties
1. computed at each quadrature point.
2. with a single value per element for efficiency that is made available to all quadrature points in a coupled calculation.
1.25.40
The system shall shall be able to compute a RankTwoTensor material object
1. with constant values.
2. with constant values using automatic differentiation.
3. with values determined by functions.
4. with values determined by functions using automatic differentiation.
1.25.41
The system shall report the retrieval of material properties by names:
1. on boundaries,
2. on blocks,
3. on the all mesh boundaries, and
4. on the all mesh blocks.
1.25.42The system shall support retrieving a single property (name) supplied by different materials on different mesh blocks.
1.25.43The system shall report an error if a material property is needed on the entire domain but is only supplied on a subset of the subdomains.
1.25.44The system shall report that a material property is available when it is defined on a subdomain.
1.25.45The system shall support retrieving a boundary restricted material property for performing a calculation on a boundary.
1.25.46The system shall report and error when a boundary restricted material is not defined on the same boundary as a boundary restricted object using that property in a calculation.
1.25.47The system shall be able to grab face and neighboring face variable values and material properties in a single material object that lives on an interface
1.25.48The system shall be able to grab face and neighboring face variable values and material properties in a single material object that lives on an interface when the mesh is split
1.25.49The system shall be able to calculate stateful material properties in an interface material object
1.25.50The system shall evaluate interface materials such that they can be used in boundary restricted elemental auxiliary kernels
1.25.51
The system shall support material property calculations that depend on other material properties:
1. with one level of dependencies,
2. with two levels of dependencies,
3. with three levels of dependencies, and
4. with differing values across mesh subdomains.
1.25.52The system shall support material property calculations for used with discontinuous Galerkin finite element method.
1.25.53The system shall support material property calculations that are restricted to boundaries on the mesh.
1.25.54The system shall error if material property calculations result in a cyclic dependency.
1.25.55The system shall error is a material property is requested on a subdomain on which it is not defined.
1.25.56The system shall support material property calculations that operate on auxiliary systems and during volume and surface residual calculations.
1.25.57The system shall error if material properties are not computed on all subdomains.
1.25.58
The system shall include that ability to handle C++ exceptions during material property calculation routines:
1. on a single process,
2. from processor 1 during a parallel calculation with 4 processes,
3. from processor 0 during a parallel calculation with 4 processes.
1.25.59The system shall support the calculation of material properties that vary at numerical integration quadrature points.
1.25.60The system shall only compute material properties when they are needed (consumed by other objects).
1.25.61The system shall support having multiple materials supplying multiple unique material properties on the same subdomains of the mesh.
1.25.62The system shall not create a dependency when old versions of material properties are retrieved and used in calculations.
1.25.63
The system shall support the output of material data as field variables including
1. outputting all properties within a material definition;
2. outputting all properties from the output definition;
3. outputting certain properties within a material definition;
4. outputting certain properties within the output definition on a subdomain;
5. outputting certain properties within the material definition on a subdomain;
6. outputting certain properties within the material definition on a subdomain with a displaced configuration;
7. outputting certain properties within the material definition on a boundary;
8. outputting certain properties within the material definition to different files; and
9. outputting properties for steady-state simulations.
1.25.64The system shall error if the supplied output options for material data output are not consistent with the list of available outputs.
1.25.65The system shall issue warnings if material data added by materials cannot be outputted as field variables.
1.25.66The system shall show the field variable names for outputting material data added by materials.
1.25.67
The system shall support the calculation of a material property with a
1. linear interpolation of a variable,
2. with a scaling factor, and
3. extrapolation.
1.25.68
The system shall support the calculation of a material property with a linear interpolation and error if
1. x, y, and xy_data are all specified;
2. x and xy_data are both specified;
3. the x and y vectors are different lengths; and
4. the xy_data vector length is not a multiple of two.
1.25.69The system shall be able to produce stateful material properties that can be consumed by other objects in the system.
1.25.70The system shall support coupling in an auxiliary field variable for use in initializing stateful material properties.
1.25.71The system shall allow the retrieval of stateful material properties for calculations on internal sides within a mesh.
1.25.72
The system shall be able to generate up to three states of material properties for use in other calculations: current, old and older
1. where properties are stored in auxiliary spatial fields, and
2. when those properties are averaged and output to a comma-separated value file.
1.25.73
The system shall verify that the oldest material property (older) can be coupled to other objects for use in another calculation:
1. where properties are stored in auxiliary spatial fields, and
2. when those properties are averaged and output to a comma-separated value file.
1.25.74The system shall be able to promote normal material properties to stateful when old/older properties are requested.
1.25.75The system shall make material property calculations available during the computation of the initial Residual vector.
1.25.76
The system shall store stateful properties that vary at every calculation point (quadrature point) similarly to a normal field variable even though they are not interpolatory:
1. on blocks, and
2. on boundaries.
1.25.77The system shall support the ability to copy stored stateful data from one element to another element.
1.25.78
The system shall handle storing stateful properties related to elements on the mesh as the mesh is adapting:
1. when properties are spatially constant, and
2. when properties vary spatially.
1.25.79The system shall not store any stateful material properties that are declared but never used.
1.25.80
The system shall be able to correctly handle stateful materials
1. when using a regular material property.
2. when using an AD material property.
3. when using a regular material property using templated methods.
4. when using an AD material property using templated methods.
1.25.81The system shall be capable of outputting material properties through auxiliary field variables.
1.25.82The system shall report and error when invalid indices are requested when attempting to output material properties through auxiliary field variables.
1.25.83The system shall only prepare or setup field variables on each element when they are used by a material object.
1.25.84The system shall support coupling in a nonlinear field variable for use in initializing stateful material properties.

framework: Mesh
1.26.1
The system shall support importing mesh information from Abaqus that includes
1. element identifiers,
2. element sets, and
3. element sets with extra space in file.
1.26.2The system shall perform identical adaptivity patterns on both the reference mesh and the displaced mesh when it exists.
1.26.3The system shall support toggling adaptivity on/off during a simulation.
1.26.4The system shall perform one or more adaptivity steps on the mesh before the simulation begins.
1.26.5The system shall support patch-based error estimation among a stencil of elements.
1.26.6The system shall support multiple adaptive steps per solve.
1.26.7The system shall perform adaptivity on systems containing multiple independent field variables.
1.26.8The system shall support running adaptivity on an interval basis (every several time steps).
1.26.9The system shall support weighted error estimation when considering multiple field variables for adaptivity.
1.26.10The system shall output all boundary and subdomain connections.
1.26.11The system shall support the use of a centroid-based parallel partitioning scheme.
1.26.12The system shall generate pre-split mesh files using a standard input file combined with command line arguments.
1.26.13The system shall use pre-split binary mesh files using a standard input file combined with command line arguments.
1.26.14The system shall auto-detect and use pre-split meshes using a standard input file combined with command line arguments.
1.26.15The system shall use pre-split ascii meshes when the command line parameter also includes the pre-split suffix.
1.26.16The system shall use pre-splits for several different numbers of processors auto-detected from the number of MPI processors used.
1.26.17The system shall use pre-splits for several different numbers of processors when the command line parameter also includes the pre-split suffix.
1.26.18The system shall generate a quadrilateral mesh consisting of concentric circles.
1.26.19
The system shall support the ability to create custom objects for performing mesh partitioning, for example
1. a linear partitioner that
2. operates with a displaced configuration and
3. is capable of restarting.
1.26.20
The system shall compute and store internal face data on request for
1. quadrilateral elements,
2. triangular elements, and
3. quadrilateral elements in multiple regions.
1.26.21The system shall read GMesh (.msh) format file meshes.
1.26.22The system shall read GMesh (.msh) format file meshes containing multiple boundaries.
1.26.23The system shall support refinement of QUAD4 mesh elements.
1.26.24The system shall support refinement of QUAD8 mesh elements.
1.26.25The system shall support refinement of QUAD9 mesh elements.
1.26.26The system shall support refinement of TRI3 mesh elements.
1.26.27The system shall support refinement of TRI6 mesh elements.
1.26.28The system shall support refinement of HEX8 mesh elements.
1.26.29The system shall support refinement of HEX20 mesh elements.
1.26.30The system shall support refinement of HEX27 mesh elements.
1.26.31The system shall support refinement of TET4 mesh elements.
1.26.32The system shall support refinement of TET10 mesh elements.
1.26.33The system shall support refinement of PRISM6 mesh elements.
1.26.34The system shall support refinement of PRISM15 mesh elements.
1.26.35The system shall support refinement of PRISM18 mesh elements.
1.26.36The system shall support refinement of PYRAMID5 mesh elements.
1.26.37The system shall support refinement of PYRAMID13 mesh elements.
1.26.38The system shall support refinement of PYRAMID14 mesh elements.
1.26.39MOOSE shall generate a structured mesh on a Cartesian domain.
1.26.40MOOSE shall generate first-order, structured meshes with biasing in the x, y, and z directions.
1.26.41MOOSE shall generate second-order, structured meshes with biasing in the x, y, and z directions.
1.26.42
The system shall include the ability to generate an annular mesh that errors when
1. the min radius is larger than the max radius;
2. the min angle is greater than or equal to the max angle;
3. the angle separation is larger than 360 degrees;
4. the number of elements in the angular direction is too small due to the number of elements; and
5. the number of elements in the angular direction is too small due to the maximum angle.
6. shall throw an error if the quadrilateral and triangular subdomain ids are the same.
1.26.43
The system shall include the ability to create
1. an annulus using quad elements;
2. an annulus sector using quad elements;
3. a circular disk using quad elements; and
4. circular disk sector using quad elements.
1.26.44MOOSE shall have an algorithm for meshing an annular region with triangular elements.
1.26.45MOOSE shall have an algorithm for generating triangular and quadrilateral meshes for the Ringleb problem.
1.26.52The system shall allow writing out the mesh without running a simulation.
1.26.53The system shall print out information about the mesh when writing out the mesh.
1.26.54The system shall warn when using –mesh-only and there is no clear filename to use
1.26.55The system shall support overriding output dimension when necessary to store coordinates in higher planes
1.26.56The system shall support writing parallel checkpoint files with –mesh-only
1.26.57The system shall support simulations on meshes containing both 1D and 2D element types.
1.26.58The system shall support proper material evaluations on meshes containing both 1D and 2D element types.
1.26.59The system shall support simulations on meshes containing both 1D and 3D element types.
1.26.60MOOSE shall generate meshes with different set of element integers and properly stitch them.
1.26.61The system shall support interchangeable use of integer and string identifiers for mesh entities.
1.26.62The system shall support interchangeable use of integer and string identifiers for mesh entities read from the XDA format.
1.26.63The system shall support interchangeable use of integer and string identifiers within the BCs/Periodic block.
1.26.64The system shall support the ability to assign and use string names to mesh entities during the simulation startup.
1.26.65The system shall support writing solution data in the Nemesis parallel file format.
1.26.66The system shall support the re-partitioning of mesh files input using the Nemesis format.
1.26.67The system shall issue an error if no Mesh block is provided.
1.26.68The system shall issue a diagnostic when a referenced node set does not exist in the mesh
1.26.69The system shall generate a mesh using one or more meshes stitched into a pattern controlled by a 2D array.
1.26.70The system shall read in a previously generated "patterned mesh" and run a simulation using that mesh.
1.26.71The system shall produce a valid periodic node map with only one periodic constraint direction.
1.26.72The system shall produce a valid periodic node map with two periodic constraint directions.
1.26.73The system shall produce a valid periodic node map with three periodic constraint directions.
1.26.74The system shall issue a diagnostic when a referenced side set does not exist in the mesh.
1.26.75The system shall have the ability to construct a side set from a set of nodes.
1.26.76A mesh can be split into a specified number of files using command line options.
1.26.77A mesh can be pre-split properly and used to generate equivalent results to running a simulation with the unsplit mesh.
1.26.78
Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode
1. without and
2. with the forced option.
1.26.79The mesh splitter will throw an error when an attempt is made to split a "DistributedMesh".
1.26.80The mesh splitter capability will honor geometric RelationshipManager objects.
1.26.81Meshes that are pre-split with active RelationshipManager objects work the same as if using an online DistributedMesh.
1.26.82Splitting meshes from file should work with custom partitioners.
1.26.83Splitting meshes from a generated mesh should work with custom partitioners.
1.26.84The system shall support the creating a single mesh from multiple meshes stitched together.
1.26.85The system shall error if at least one mesh file is not supplied when creating a mesh from multiple meshes stitched together.
1.26.86The system shall produce a parallel partition based on mesh subdomains for the Mac platform.
1.26.87The system shall produce a parallel partition based on mesh subdomains agnostic of platform.
1.26.88The system shall produce a parallel partition based on mesh subdomains for the Linux platform.
1.26.89The system shall construct a mesh by "tiling" another mesh repeatedly.
1.26.90The system shall support having a truly unique_id (never recycled) for all mesh elements and nodes when using replicated mesh.
1.26.91The system shall support having a truly unique_id (never recycled) for all mesh elements and nodes when using distributed mes.

framework: Mesh Modifiers
1.27.1
The system shall support assigning boundary identifiers base on normal vectors of an element face for
1. a rectangular cuboid and
2. non regular geometry.
1.27.2
The system shall support assigning boundary identifiers based on
1. a nodal id,
2. a spatial coordinate, and
3. if the supplied location is outside of the domain.
1.27.3
The system shall support assigning boundary identifiers based on the normal of a element face for
1. specified points and
2. specified directions with
3. fixed normal application.
1.27.4
The system shall support assigning boundary identifiers based the bounding box
1. for all subdomain sides as well as
2. for all subdomain sides including those with multiple existing identifiers in 2D and
3. 3D.
1.27.5
The system shall support assigning boundary identifiers based the bounding box of a subdomain and error if
1. if no elements are located in the given bounding box;
2. if no sides are located in the given bounding box;
3. if no nodes are located in the given bounding box; and
4. if the incorrect boundary inputs are supplied.
1.27.6
The system shall support assigning boundary identifiers based the bounding box of a subdomain
1. if existing boundaries overlap and
2. error if no nodes are located in the given bounding box.
1.27.7
The system shall support assigning subdomain identifiers
1. given a list of ids for each element; and
2. given a list of elements and ids for quadrilateral and
3. triangular elements.
1.27.8The system shall support assigning subdomain identifiers for the entire domain.
1.27.9
The system shall support removing elements including
1. a 2D concave subdomain;
2. a 3D concave subdomain;
3. a 2D interior subdomain;
4. a 3D interior subdomain;
5. a 2D non-concave subdomain;
6. a 3D non-concave subdomain;
7. a 2D removal of a union of disjoint pieces;
8. a 2D removal of a subdomain containing a nodeset;
9. a 2D removal of a subdomain that eliminates sideset;
10. a 2D removal of a subdomain containing a sideset;
11. a 2D concave subdomain with a cut across elements.
1.27.10
The system shall be capable of adding nodeset identifiers given a bounding box for
1. an area inside the box;
2. an area outside the box;
1.27.11
The system shall error when adding nodeset identifiers given a bounding box and
1. the supplied location is invalid and
2. when multiple ids are provided for assignment.
1.27.12
The system shall support separation of boundary identifiers for
1. all boundaries and
2. specific boundaries across a subdomain.
1.27.13
The system shall support separation of boundary identifiers
1. for 2D subdomains;
2. across an interface; and
3. an unstructured mesh.
1.27.14
The system shall support separation of boundary identifiers
1. for 3D subdomains;
2. across an interface; and
3. an unstructured mesh.
1.27.15
The system shall support creating subdomains from
1. 2D and
2. 3D images.
1.27.16
The system shall support the creation of lower dimensional elements on an existing sideset for
1. first-order and
2. second-order elements.
1.27.17
The system shall support creating of 3D meshes from extrusion of
1. 2D quadrilateral elements;
2. 2D triangular elements;
3. 2D quadrilateral elements at an angle; and
4. 2D quadrilateral elements from generated mesh
1.27.18
The system shall support creating of 3D meshes from extrusion of with the ability to remap subdomain identifiers
1. for each layer individually or
2. for all layers
1.27.19The system shall support the creation of lower dimensional elements along the faces contained in a side.
1.27.20
The system shall support the modification of the mesh
1. without restriction to the order of the supplied inputs with
2. a forced mesh preparation step.
1.27.21The system shall support the creation of side identifiers based on a function provided in the input file.
1.27.22The system shall support the creation of subdomain identifiers based on a function provided in the input file.
1.27.23
The system shall support the ability to rename mesh subdomains including
1. basic two domain meshes and
2. multi-subdomain meshes.
1.27.24
The system shall error when renaming subdomains if
1. the number of new subdomain identifiers is greater than the number of old subdomain identifiers;
2. the supplied the block identifier name missing;
3. the supplied the block identifier number missing;
4. the number of old subdomain identifiers is greater than the number of ned subdomain identifiers;
5. the supplied the new block identifier name missing; and
6. the supplied the new block identifier number missing.
1.27.25
The system shall support the creating of side identifiers surrounding
1. a subdomain;
2. a subdomain given a direction;
3. a generated subdomain; and
4. a multiple generated subdomains
1.27.26
The system shall support the creating of side identifiers between
1. subdomains;
2. multiple subdomains; and
3. generated subdomains.
1.27.27The system shall support the ability to apply smoothing to a mesh.
1.27.28
The system shall be capable of adding subdomain identifiers given a bounding box for
1. an area inside the box;
2. an area outside the box;
3. an area inside an oriented box; and
4. an area outside an oriented box.
1.27.29The system shall be capable of transforming an existing mesh.

framework: Meshgenerators
1.28.1The system shall support automatic addition of sidesets based on outward facing normals of the mesh.
1.28.2The system shall group automatically added sidesets when multiple surfaces share the same outward facing normal.
1.28.3The system shall have the capability of generating a mesh based upon an annular geometry.
1.28.4The system shall have the capability of generating a mesh based upon an annular geometry with a negative growth ratio.
1.28.6The system shall support the ability to add additional mesh generators from a user accessible programmatic interface.
1.28.7
The system shall be capable of deleting
1. all of the elements in a mesh based on subdomain ID,
2. all of the elements in a mesh based on subdomain names and
3. multiple blocks simultaneously in a mesh based on subdomain ID.
1.28.8The system shall have the capability to remove boundaries in an existing mesh.
1.28.9
The system shall be capable of generating new mesh node sets based upon a user-specified bounding box
1. where the new node set will be placed on nodes within the bounding box, or
2. where the new node set will be placed on nodes outside of the bounding box.
1.28.10
The system shall produce an error when attempting to add a new mesh node set based on a bounding box
1. where the bounding box fails to span any mesh nodes, and
2. where multiple boundary IDs are supplied for a single bounding box.
1.28.11
The system shall be capable of splitting existing mesh boundary sets where their underlying subdomain changes
1. on external boundaries, and
2. on internal boundaries.
1.28.12
MOOSE shall be able to create separate blocks in a mesh
1. without a split interface in 3D;
2. with a split interface in 3D;
3. with a polycrystal based mesh in 3D;
4. without a split interface in 2D;
5. with a split interface in 2D; and
6. with a polycrystal based mesh in 2D.
1.28.13
The system shall be able to break the mesh between listed blocks:
1. without splitting the interface and with splitting the transition interface;
2. with a split interface and without splitting the transition interface;
3. with a split interface and splitting the transition interface;
4. with a split interface, without splitting the transition interface, and without a transition interface;
5. without a split interface, splitting the transition interface, or a transition interface;
1.28.14The system shall properly assign node processor ids for paritioned meshes
1.28.15
The system shall be capable of generating an non-uniform mesh on a Cartesian domain in
1. one,
2. two, and
3. three dimensions.
1.28.16
The system shall support the ability to combine multiple meshes:
1. using a single input mesh at multiple positions,
2. using a single input mesh at multiple positions obtained from a file,
3. using multiple meshes at multiple positions, and
4. using multiple meshes at multiple positions obtained from a file, and
5. using multiple meshes with no positions.
1.28.17
The system shall error when trying to combine multiple meshes,
1. but only one input is supplied with no positions, or
2. but only one input is supplied with no positions file, or
3. the number of meshes and the number of positions is mismatched, or
4. the number of meshes and the number of positions in the file is mismatched.
1.28.18The system shall have the capability to generate a mesh pattern consisting of concentric circles contained within a square.
1.28.19The winding order of the elements created by the mesh generator shall be uniform.
1.28.20The system shall support the generation of meshes for both reference and displaced mesh configurations.
1.28.21The system shall support mesh adaptivity on a distributed generated displaced mesh.
1.28.22The system shall support mesh adaptivity with periodic boundary conditions on a distributed generated displaced mesh.
1.28.23
The system shall support a scalable mesh adaptivity with periodic boundary conditions on a distributed generated displaced mesh
1. without and with
2. automatic scaling.
1.28.24MOOSE shall be able to generate 2D Quad4 mesh in parallel
1.28.25MOOSE shall be able to check if or not users ask for too many layers of ghosting elements
1.28.26MOOSE shall be able to generate 1D EDGE2 mesh in parallel.
1.28.27MOOSE shall be able to generate 3D HEX8 mesh in parallel.
1.28.28MOOSE shall be able to generate 3D HEX8 mesh in parallel using ptscotch partitioner
1.28.29MOOSE shall be able to generate 3D HEX8 mesh in parallel using hierarch partitioner
1.28.30MOOSE shall be able to generate a first-order hexahedral mesh in parallel using a small number of cores for the graph partitioner.
1.28.31MOOSE shall error out if the number of cores for partition is larger than the total number of cores.
1.28.32The system shall be able to adapt a mesh generated in parallel.
1.28.33The system shall generate an arbitrary number of layers of side neighbors using DistributedRectilinearMeshGenerator.
1.28.34The system shall be able to generate a squarish partition for a 2D distributed generated mesh using 3 processors.
1.28.35The system shall be able to generate a squarish partition for a 2D distributed generated mesh using 4 processors.
1.28.36The system shall be able to generate a squarish partition for a 2D distributed generated mesh using 6 processors.
1.28.37The system shall be able to generate a squarish partition for a 1D distributed generated mesh using 3 processors.
1.28.38The system shall be able to generate a squarish partition for a 1D distributed generated mesh using 4 processors.
1.28.39The system shall be able to generate a squarish partition for a 3D distributed generated mesh using 3 processors.
1.28.40The system shall be able to generate a squarish partition for a 3D distributed generated mesh using 4 processors.
1.28.41The system shall be able to generate a squarish partition for a 3D distributed generated mesh using 8 processors.
1.28.42
The system shall support the ability to create a mesh element-wise by specifying points, element types, and connectivity,
1. resulting in a single element mesh, or
2. resulting in a mesh with multiple disconnected elements.
1.28.43The system shall have the ability to add extra mesh node sets based on existing node IDs.
1.28.44The system shall have the ability to add extra mesh node sets based on node coordinates.
1.28.45The system shall have the ability to add extra mesh node sets based on multiple node coordinates.
1.28.46The system shall be able to extrude a mesh with variable height elevations, with variable numbers of layers, and swap subdomain IDs
1.28.47The system shall make sure the mesh is prepared after a mesh generator has indicated the mesh is not prepared and before running a solve.
1.28.48The system shall be able to use the result from FancyExtruderGenerator in subsequent mesh generators
1.28.49The system shall have the ability to generate a mesh by reading it from a file.
1.28.50The system shall have the ability to assign element extra integers with elemental variables in an Exodus mesh file.
1.28.51The system shall have the ability to output checkpoint files along with the mesh meta data.
1.28.52The system shall have the ability to load the mesh from checkpoint files.
1.28.53
The system shall support using a directed acyclic graph of objects to generate a mesh where multiple possible end points may be explicitly selected:
1. the first of two targets
2. and the second of two targets.
1.28.54The system shall support selecting an earlier generation state of the mesh generator system used to generate the final mesh for a simulation.
1.28.55
The system shall generate an error when the objects used to generate a mesh results in an ambiguous end point
1. due to a single graph with multiple end points, or
2. due to multiple independent trees.
1.28.56MOOSE shall be able to use libmesh mesh generation tools.
1.28.57MOOSE shall be able to use libmesh mesh generation tools and shift node/sideset ids by a constant offset.
1.28.58
The system shall include mesh generation tools and allow adding a name prefix to the node/sideset names and maintain the
1. id and
2. include the added name.
1.28.59
The system shall include mesh generation tools and shift node/sideset ids by a constant offset while also adding a name prefix to them and maintain the
1. the shifted id and
2. include the added name.
1.28.60MOOSE shall generate a warning if Mesh Generators are used with a mesh type that does not accept them
1.28.61The system shall support the ability to import meshes written using the General Mesh Viewer format.
1.28.62The system shall have the ability to read boundary information from Gmsh formatted mesh files.
1.28.63MOOSE shall be able to read in an image.
1.28.64
The system shall be able to create different subdomains
1. using boundary ids.
2. using boundary names.
1.28.65The system shall be able to combine multiple meshes into a single unconnected mesh.
1.28.66
The system shall have the capability of extruding a lower dimensional mesh to create a higher dimensional mesh
1. from 2D quads to 3D hexes,
2. where newly created elements can be assigned a new subdomain IDs based on old IDs,
3. where newly created elements can be assigned a new subdomain IDs based on a pattern,
4. where the extrusion direction is not orthogonal to the original line or plane of elements, and
5. where the extrusion occurs based on another generated mesh,
6. while making sure to preserve existing side set names.
1.28.67The system shall support the generation of side sets between subdomains of a finite element mesh.
1.28.68The system shall support the ability for mesh generators to save attributes to a stateful data store available for use when recovering a simulation.
1.28.69The system shall issue an error when mesh meta-data properties are requested but never declared.
1.28.70The system shall error if a invalid identifier is supplied when attempting to retrieve a restart meta data object.
1.28.71The system shall support the ability to save mesh meta data generated by mesh generators when splitting the mesh.
1.28.72The system shall support the ability to use the mesh meta data when using the split mesh.
1.28.73The system shall have the ability to assign mesh side sets based on parsed spatial functions.
1.28.74The system shall have the ability to filter by neighboring subdomain id in ParsedGenerateSideset.
1.28.75The system shall have the ability to assign mesh subdomains based on parsed spatial functions.
1.28.76
The system shall be able to create a patch test mesh with:
1. quad4 elements,
2. quad8 elements,
3. hex8 elements, and
4. hex20 elements.
1.28.77The system shall have the ability to stetch multiple input meshes together into a new mesh based upon a user-defined pattern.
1.28.78The system shall provide a method for deleting mesh elements lying on one side of a user-defined plane.
1.28.79
The system shall be able to rename or renumber mesh subdomains prior to running the simulation:
1. using a sequence of renaming operations, or
2. by renaming several blocks simultaneously.
1.28.80
The system shall be able to rename or renumber mesh boundaries by:
1. identifying both old and new boundaries by ID,
2. identifying old boundaries by ID and new boundaries by name,
3. identifying old boundaries by name and new boundaries by ID, and
4. identifying both old and new boundaries by name,
5. and by identifying boundaries by both id and name.
1.28.81The system shall be able to merge boundaries in a mesh.
1.28.82
The system shall throw a reasonable error:
1. when old boundaries are provided that do not exist within the mesh
2. and when the provided old and new boundaries are not the same length.
1.28.83The system shall support the ability to create a mesh for a "Ringleb" geometry.
1.28.84The system shall be able to output detailed mesh information about generated meshes.
1.28.85
The system shall have the ability to create new mesh side sets around subdomains:
1. for a subdomain contained completely within a larger domain,
2. on specific sides of a subdomain based upon the normal to that side,
3. around multiple subdomains within a larger domain, and
4. around two blocks within a domain.
1.28.86
The system shall have the ability to create new side sets between adjacent subdomains:
1. on a mesh with several adjacent subdomains,
2. where some subdomains are adjacent and not where paired subdomains are not adjacent, and
3. between two subdomains in a mesh with two adjacent subdomains.
1.28.87
The system shall have the ability to generate side sets based upon bounding boxes:
1. a bounding box contained within the domain,
2. multiple bounding boxes contained within the domain,
3. multiple bounding boxes contained within a 3D domain, and
4. where bounding boxes perfectly overlap but create unique ids.
1.28.88
The system shall issue an error when attempting to create side sets from a bounding box:
1. when no elements are located within the specified bounding box,
2. when the bounding box is larger than the domain so that no new side set is created, and
3. when the bounding box fails to span over any nodes.
1.28.89The system shall be able to generate mesh side sets for all external surfaces on the mesh for each unique normal.
1.28.90The system must be able to replace the side sets when applying side sets during mesh generation.
1.28.91
The system shall support the generation of multiple mesh side sets on the exterior surfaces of a mesh grouped by normal:
1. where the normal varies within a tolerance from element to element,
2. where the normal is fixed within a specified tolerance.
1.28.92MOOSE shall be able to create sidesets.
1.28.93MOOSE shall be able to use libmesh mesh mdification tools.
1.28.94MOOSE shall be able to create meshes.
1.28.95
The system shall be able to generate meshes by stacking up existing meshes in
1. two and
2. three dimensions and
3. error if the dimensions of the meshes to be stacked are not consistent.
1.28.96
The system shall support the creation of a finite element mesh from existing meshes
1. by 'stitching' them together and
2. be able to utilize the resulting mesh in a simulation.
1.28.97The system shall include the ability to assign subdomain identifiers for elements within a regular bounding box.
1.28.98The system shall include the ability to assign subdomain identifiers for elements outside of a regular bounding box.
1.28.99The system shall include the ability to assign subdomain identifiers for elements within an arbitrarily oriented bounding box.
1.28.100The system shall include the ability to assign subdomain identifiers for elements with a regular bounding box that is restricted to only modify elements with specific subdomain identifiers.
1.28.101The system shall have the ability to change or overwrite the subdomain IDs of all elements in a mesh.
1.28.102The system mesh generation capability shall be extensible to allow composition of existing mesh generators.
1.28.103The system shall include the ability to create a finite element mesh by tiling existing meshes.
1.28.104The system shall include the ability to rotate and scale a finite element mesh.
1.28.105
The system shall include the ability to translate a finite element mesh in a manner that
1. is defined by the user,
2. places the center of the mesh at the origin, or
3. places the minimum of the mesh at the origin.

framework: Minimal App
1.29.1The system shall support the programmatic creation of a simulation tools without the need of an input file.

framework: Misc
1.30.1We shall be able to call AD variable methods on an auxiliary variable in a transient simulation and not hit assertions for both regular and neighbor calculations
1.30.2Coupling an auxiliary variable into a DGKernel shall not destroy the Jacobian
1.30.3We shall be able to do NL variable coupling into a DGKernel
1.30.4We shall be able to do NL variable coupling into a DGKernel and have a good Jacobian
1.30.5The compiled application shall be capable of returning the name used for registering objects.
1.30.6The system shall report an error when a material property is not defined on a boundary.
1.30.7The system shall report an error when a material property requested by a UserObject is not defined on a boundary.
1.30.8The system shall report an error when a material property requested by a DGKernel is not defined on a boundary.
1.30.9The system shall report an error when a material property requested by a DGKernel is not defined on a subdomain.
1.30.10The system shall verify that objects that use subdomain restricted variables are defined on a subset of the restricted domain area.
1.30.11The system shall produce an error when an object's discretization area is explicitly set to a value greater than the area of the underlying variable used by the object.
1.30.12The system shall produce an error when an object's discretization area is greater than the area of the underlying variable used by the object.
1.30.13The system shall produce an error when an object's discretization area is explicitly set to a different area than the area of a coupled variable used by the object.
1.30.14The system shall produce an error when an object's discretization area is different than an explicitly set variable on only defined on a different portion of the mesh.
1.30.15The system shall produce an error when an object's discretization area is covers the whole mesh but a coupled variable only exists on a portion of the mesh.
1.30.18The system shall report an error when a null pointer-checked parameter is retrieved from the InputParameters object.
1.30.19The system shall report an error when multiple AuxVariables are added to the system with conflicting types.
1.30.20The system shall report an error when multiple Scalar AuxVariables are added to the system with conflicting types.
1.30.21The system shall report an error when an attempt is made to instantiate a non-existent BoundaryCondition object.
1.30.22The system shall report an error when a non-existent nonlinear variable name is used by a MooseObject.
1.30.23The system shall report an error message when an invalid enumeration is supplied in any MooseEnum type.
1.30.24The system shall report an error message when an invalid Executioner is specified.
1.30.25The system shall report an error message when an invalid Kernel is specified.
1.30.26The system shall report an error message when a Kernel object attempts to access a non-existent variable.
1.30.27The system shall report an error when an invalid Material is specified.
1.30.28The system shall report an error when a previously undeclared variable is used in a parsed function expression.
1.30.29The system shall report an error when a first order element is used with a second order discretization.
1.30.30The system shall report an error message when a deprecated input file block is used.
1.30.31The system shall report a warning when a deprecated parameter with a default value is explicitly set by the user.
1.30.32The system shall report a warning when an optional deprecated parameter is explicitly set by the user.
1.30.33The system shall report an error when conflicting domain restrictions are applied to a single object.
1.30.34The system shall report an error when the number of ids and corresponding block names are mismatched.
1.30.35The system shall report an error when a duplicate name is provided for a set of unique block ids.
1.30.36The system shall report an error when the number of ids and corresponding boundary names are mismatched.
1.30.37The system shall report an error when a duplicate name is provided for a set of unique boundary ids.
1.30.38The system shall report an error when the linear interpolation utility is supplied with bad domain values.
1.30.39The system shall report an error when the Piecewise utility encounters an unexpected column data format.
1.30.40The system shall report an error when the Piecewise utility encounters an unexpected row data format.
1.30.41The system shall report an error when the Piecewise utility encounters inconsistent domain and range data.
1.30.42The system shall report an error when an invalid enumeration is supplied in the Piecewise utility.
1.30.43The system shall report an error when the Piecewise data is over-specified with the data file option.
1.30.44The system shall report an error when the Piecewise data is over-specified with row/column data.
1.30.45The system shall report an error when either the domain or range is missing when using the domain/range option in the Piecewise utility.
1.30.46The system shall report and error if the supplied domain/range pairs are not even in the Piecewise utility.
1.30.47The system shall report an error if no function is supplied in the Piecewise utility.
1.30.48The system shall report an error if the xy_data is supplied but the function is missing in the Piecewise utility.
1.30.49The system shall report an error when the number of columns appears incorrect in the Piecewise utility.
1.30.50The system shall report an error when an out of range y-column index is supplied in the Piecewise utility.
1.30.51The system shall report an error when an out of range x-column index is supplied in the Piecewise utility.
1.30.52The system shall report an error if too many rows are supplied when the data is expected to contain row information.
1.30.53The system shall report an error when an out of range x-row index is supplied in the Piecewise utility.
1.30.54The system shall report an error when an out of range y-row index is supplied in the Piecewise utility.
1.30.55The system shall report an error when the x and y index in file are equal in the Piecewise utility.
1.30.56The system shall report an error if one or more domain blocks do not have any active Kernels objects assigned.
1.30.57The system shall report an error if one or more variables do not have any active Kernel objects assigned.
1.30.58The system shall report an error if one or more domain blocks do not have any active FVKernels objects assigned.
1.30.59The system shall report an error if one or more variables do not have any active FVKernel objects assigned.
1.30.60The system shall report an error when an elemental variable (no $var element = document.getElementById("moose-equation-eb456f4b-a31b-4cdd-9550-76e510dee3d3");katex.render("C_0", element, {displayMode:false,throwOnError:false,macros:{"\\pf":"\\frac{\\partial #1}{\\partial #2}"}});$ continuity) is coupled to a variable with $var element = document.getElementById("moose-equation-98cef435-d6de-4d83-9829-be0223b61961");katex.render("C_0", element, {displayMode:false,throwOnError:false,macros:{"\\pf":"\\frac{\\partial #1}{\\partial #2}"}});$ continuity.
1.30.61The system shall report an error when an active input block section is specified but missing.
1.30.62The system shall report an error when a material property is requested but not supplied on a mesh block.
1.30.63The system shall report an error when a coupled variable is supplied that was not added as a valid parameter.
1.30.64The system shall report an error when the data file is non-existent or not-readable in the Piecewise utility.
1.30.65The system shall report an error when the coupled function does not exist or can not be parsedfor the Piecewise utility.
1.30.66The system shall report an error when one or more material properties are missing from any mesh block.
1.30.67The system shall report an error when a material property is supplied on some blocks but missing on other blocks where it is requested.
1.30.68The system shall report an error when only "old" properties are supplied but current properties are requested.
1.30.69The system shall report an error when only "older" properties are supplied but current properties are requested.
1.30.70The system shall report an error when the mesh file cannot be found.
1.30.71The system shall report an error when a required parameter is not supplied in an Action.
1.30.72The system shall report an error when a specific mesh required parameter is not supplied.
1.30.73The system shall report an error when the special "type" parameter is not supplied for a MooseObject.
1.30.74The system shall report an error when a required parameter is not supplied in a MooseObject.
1.30.75The system shall report an error when a required coupling parameter is missing.
1.30.76The system shall report an error when more than one preconditioner block is supplied.
1.30.77The system shall abort the solve and report a floating point error when a NaN is produced during user computation with the Steady executioner.
1.30.78The system shall abort the solve and report a floating point error when a NaN is produced during user computation with the Transient executioner.
1.30.79The system shall report an error when a nodal AuxKernel attempts to access a material property.
1.30.80The system shall report an error when the same named parameter appears multiple times in the same input file.
1.30.81The system shall report an error when the coordinate transformation conflicts with the underlying element types.
1.30.82The system shall report an error when nonlinear and auxiliary variables are declared with the same name.
1.30.83The system shall report an error when an AuxKernel is applied outside of the domain where a restricted variable exists.
1.30.84The system shall report an error when a Kernel is applied outside of the domain where a restricted variable exists.
1.30.85The system shall report a warning when an unused parameter is provided through the input file or an Action.
1.30.86The system shall report a warning when an unused parameter is supplied on the command line.
1.30.87The system shall report an error when a UserObject and a Postprocessor are added with the same names.
1.30.88The system shall report and error when a UserObject and a VectorPostprocessor are added with the same names.
1.30.89The system shall report an error when an input file block associated with on pluggable system is asked to build an object from a different system.
1.30.90The system shall report a standard Unix usage statement when an invalid command line switch is used.
1.30.91The system shall report an error when a required variable is missing from the ICs input file block.
1.30.92The system shall report an error when a boundary restriction is applied to a non-nodal variable discretization.
1.30.93The system shall report an error when coupling to old temporal solution vectors in a Steady (no time) Executioner.
1.30.94The system shall report an error when coupling to a time derivative solution vector in a Steady (no time) Executioner.
1.30.95The system shall report an error when an older scalar solution variable is accessed in a Steady (no time) Executioner.
1.30.96The system shall report an error when an older time derivative scalar solution variable is accessed in a Steady (no time) Executioner.
1.30.97The system shall report an error when a coupled variable is not defined in the same region as the variable performing the coupling.
1.30.98The system shall report the successful parsing and interpretation of input file syntax when using the "–check-input" command line flag.
1.30.99The system shall report an error when performing nodal constraints when there is a mismatch in the number of constrained nodes.
1.30.100The system shall report an error when requested to check the syntax in an input file but no input file is supplied.
1.30.101The system shall report an error when multiple time schemes are specified in the same input file.
1.30.102The system shall report an error when there is a mismatch between the parameter for an object and the type of object are mismatched.
1.30.103The system shall report an error when the variables representing displacement are of a lower order than the mesh.
1.30.104The system shall report an error when the name of a function could be misinterpreted because it could also be evaluated (e.g. a function name of "x").
1.30.105The system shall report an error when floating point input parameter types fail to parse as floating point numbers.
1.30.106The system shall report an error when a scalar variable is used where a spatial variable is expected.
1.30.107The system shall report an error when a field variable is used where a scalar variable is expected.
1.30.108The system shall report an error when an invalid coupled spatial variable is requested.
1.30.109The system shall report an error when an invalid coupled scalar variable is requested.
1.30.110The system shall report an error when an attempt is made to couple a variable with itself.
1.30.111The system shall report an error when an input file cannot be opened and read.
1.30.112The system shall report an error when a Kernel attempts to use an auxiliary variable.
1.30.113The system shall report an error when a boundary condition object attempts to use an auxiliary variable.
1.30.114The system shall report an error when an AuxKernel specifies a non-existent variable.
1.30.115The system shall report an error when a scalar Kernel specifies a non-existent variable.
1.30.116The system shall report an error when a nodal Kernel attempts to use an auxiliary variable.
1.30.117The system shall report an error when a constraint attempts to use an auxiliary variable.
1.30.118The system shall report an error when a scalar auxiliary Kernel attempts to use a solution variable.
1.30.119The system shall report an error when a DiracKernel attempts to use an auxiliary variable.
1.30.120The system shall report an error when a discontinuous Galerkin Kernel attempts to use a solution variable.
1.30.121The system shall report an error when an interface Kernel attempts to use an auxiliary variable.
1.30.122The system shall report an error when a Kernel attempts to retrieve an empty string variable.
1.30.123The system shall report an error when a vector Kernel attempts to use a scalar solution variable.
1.30.124The system shall report an error when a Kernel attempts to use a vector solution variable.
1.30.125The system shall report an error if users try to get nodal values of non-nodal variables.
1.30.126The system shall report an error if users try to get old nodal values of non-nodal variables.
1.30.127The system shall report an error if users try to get older nodal values of non-nodal variables.
1.30.128The system shall have an integrity check that ensures an Executioner object exists in the system.
1.30.129The system shall report an error when nodal boundary condition is applied on a non-nodal variable.
1.30.130The system shall report an error when a git-lfs file pointer is encountered.
1.30.131The system shall support the ability for actions to query the existence of a mesh attribute (meta data).
1.30.132The system shall support the output a processor id field for the purposes of debugging
1.30.133The system shall produce a warning when non-expired deprecated code is executed.
1.30.134The system shall produce a warning when expired deprecated code is executed.
1.30.135The system shall produce an error when the –no-deprecated-flag is passed and deprecated code is executed.
1.30.136The system shall produce a warning indicating a possible replacement when deprecated code is superseded.
1.30.137The system shall be able to deprecate coupled variable names, while enabling user code to only use the new, blessed name
1.30.138The system shall not give a deprecation warning if the user uses the blessed coupled variable name instead of the deprecated coupled variable name.
1.30.139
The system allow coupling between variables on or off displaced meshes
1. not using automatic differentiation methods
2. using automatic differentiation methods
1.30.140The system shall support throwing an exception during the residual calculation, which will cut back the time step.
1.30.141The system shall support throwing an exception during the residual calculation on a non-zero rank, which will cut back the time step.
1.30.142The system shall support throwing an exception during the Jacboain calculation, which will cut back the time step.
1.30.143The system shall support throwing an exception during the Jacobian calculation on a non-zero rank, which will cut back the time step.
1.30.144The system shall support throwing an exception during the initial condition calculation, which will terminate the solve.
1.30.145The system shall support throwing an error during a residual calculation, which will terminate the solve.
1.30.146The system shall support throwing an error during a Jacobian calculation, which will terminate the solve.
1.30.147The system shall allow users to skip exception checks to avoid global communication.
1.30.148The system shall maintain a flag available for inspection indicating the current "execution stage" enumeration.
1.30.149The system shall verify equality among the current, old, and older solution vectors prior to running the simulation.
1.30.150The system shall support a testing mechanism that fails intermittently.
1.30.151We shall be able the scrape the DOFMapOutput and determine when the Jacobian is slightly off
1.30.152We shall be able the scrape the DOFMapOutput and determine when the Jacobian is questionable
1.30.153We shall throw no errors if the off-diagonal Jacobian is wrong if we are only testing the on-diagonal Jacobian
1.30.154If use_displaced_mesh = false then MOOSE will not throw an exception if elements are inverted to produce a negative element Jacobian, in 3D simulations
1.30.155A 3D simulation shall throw an exception if there is a zero element Jacobian, when use_displaced_mesh = true
1.30.156A 3D simulation shall throw an exception if there is a negative element Jacobian, when use_displaced_mesh = true
1.30.157If use_displaced_mesh = false then MOOSE will not throw an exception if elements are inverted to produce a negative element Jacobian, in 2D simulations
1.30.158If use_displaced_mesh = false then MOOSE will not throw an exception if elements are distored to produce a zero element Jacobian, in 2D simulations
1.30.159A 2D simulation shall throw an exception if there is a zero element Jacobian, when use_displaced_mesh = true
1.30.160The PETSc Jacobian test shall reveal nans if there are nans in the matrix
1.30.161The system shall support embedding a 1D block inside of a 3D block.
1.30.162The maximum number of degrees of freedom for a single variable on a 1D EDGE2 elem shall be 2
1.30.163The maximum number of degrees of freedom for a single variable on a 2D QUAD4 elem shall be 4
1.30.164The maximum number of degrees of freedom for a single variable on a 2D QUAD9 elem shall be 9
1.30.165The maximum number of degrees of freedom for a single variable on a 2D TRI3 elem shall be 3
1.30.166The maximum number of degrees of freedom for a single variable on a 2D TRI6 elem shall be 6
1.30.167The maximum number of degrees of freedom for a single variable on a 3D HEX8 elem shall be 8
1.30.168The testing system shall support the ability to disable geometrical mapping of mesh elements for comparison purposes.
1.30.169PETSc option database shall work properly
1.30.170The system shall print an understandable message when a user-specified path/file does not exist.
1.30.171
The system shall be capable of storing residual contributions as an auxiliary field variable for
1. continuous Galerkin and
2. discontinuous Galerkin methods.
1.30.172
The system shall error if the residual calculation contribution is assigned to the incorrect variable for
1. on-diagonal and
2. off-diagonal terms.
1.30.173The system shall be able to compute the same value for a block-restricted save-in variable regardless of the number of processes used to run a simulation.
1.30.174The system shall only reinitialize variables values that are consumed by other active objects in the system.
1.30.175The system shall make a serialized solution vector available when requested by objects in the system.
1.30.176The system shall make a serialized solution vector available when requested by objects in the system when uniform refinement is active.
1.30.177The system shall make a serialized solution vector available when requested by objects in the system when adaptivity is active.
1.30.178The test system shall have the ability to execute a specific input file.
1.30.179The test system shall have the ability to run a test that neither clears expected outputs or runs the expected executeable for multiple output testing.
1.30.180The system shall support pausing execution for the purpose of attaching a debugger after launch.
1.30.181The system shall support running a user-defined subroutine each time a subdomain change occurs when iterating over the mesh.
1.30.182The application executable shall report the version with the –version command line argument.
1.30.183The application executable shall report the version with the -v command line argument.

framework: Mortar
1.31.1The system shall support the use of constrains using the mortar method in 1D.
1.31.2We shall tell the user that mortar doesn't currently work in 3D
1.31.3We shall be able to enforce solution continuity on a conforming mesh for one variable
1.31.4We shall be able to enforce solution gradient continuity on a conforming mesh for one variable
1.31.5We shall be able to enforce solution continuity on a conforming mesh for two variables
1.31.6We shall be able to enforce solution continuity on a conforming mesh for one variable using second order shape functions for both primal and lagrange variables. Note that this may be a relatively unstable discretization
1.31.7We shall be able to produce the expected result for a solution continuity test case using the mortar method, e.g. the primal variable values across the mortar interface shall be the same.
1.31.8We shall be able to produce the expected result for a solution continuity test case using the first order dual basis.
1.31.9We shall be able to produce the expected result for a solution continuity test case using the second order dual basis.
1.31.10We shall be able to produce the expected result for a fine mesh solution continuity test case using the mortar method, e.g. the primal variable values across the mortar interface shall be the same.
1.31.11The Jacobian for the solution continuity test case shall be perfect
1.31.12The system shall be able to prolong and restrict stateful material properties because of mesh adaptivity in the presense of lower dimensional subdomains that do not have materials and when stateful properties are needed on boundaries (because of integrated boundary conditions)
1.31.13The system shall be able to demonstrate asymptotically correct convergence rates of 3 and 3 for a mortar gap-conductance problem with equal, coarse-secondary, and coarse-primary geometric discretizations when using a second order basis for the temperature variable and a second order basis for the Lagrange multiplier.
1.31.14The system shall be able to demonstrate asymptotically correct convergence rates of 3 and 2 for a mortar gap-conductance problem with equal, coarse-secondary, and coarse-primary geometric discretizations when using a second order basis for the temperature variable and a first order basis for the Lagrange multiplier.
1.31.15The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 1 for a mortar gap-conductance problem with equal, coarse-secondary, and coarse-primary geometric discretizations when using a second order basis for the temperature variable and a zeroth order basis for the Lagrange multiplier.
1.31.16The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 2 for a mortar gap-conductance problem with equal, coarse-secondary, and coarse-primary geometric discretizations when using a first order basis for the temperature variable and a first order basis for the Lagrange multiplier.
1.31.17The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 1 for a mortar gap-conductance problem with equal, coarse-secondary, and coarse-primary geometric discretizations when using a first order basis for the temperature variable and a zeroth order basis for the Lagrange multiplier.
1.31.18The system shall be able to demonstrate asymptotically correct convergence rates of 3 and 3 for a mortar solution continuity problem with an equal geometric discretization when using a second order basis for the temperature variable and a second order basis for the Lagrange multiplier.
1.31.19The system shall be able to demonstrate asymptotically correct convergence rates of 3 and 2 for a mortar solution continuity problem with an equal geometric discretization when using a second order basis for the temperature variable and a first order basis for the Lagrange multiplier.
1.31.20The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 1 for a mortar solution continuity problem with an equal geometric discretization when using a second order basis for the temperature variable and a zeroth order basis for the Lagrange multiplier.
1.31.21The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 2 for a mortar solution continuity problem with an equal geometric discretization when using a first order basis for the temperature variable and a first order basis for the Lagrange multiplier.
1.31.22The system shall be able to demonstrate asymptotically correct convergence rates of 2 and 1 for a mortar solution continuity problem with an equal geometric discretization when using a first order basis for the temperature variable and a zeroth order basis for the Lagrange multiplier.
1.31.23We shall be able to couple variables between boundary auxiliary kernels and mortar constraints.
1.31.24We shall be able to use boundary-restricted material properties in mortar constraints.
1.31.25We shall be able to do gap conductance on a dynamic mesh using auxiliary displacements
1.31.26The Jacobian for the dynamic aux displacement gap conductance test case shall be perfect
1.31.27We shall be able to do gap conductance on a dynamic mesh using auxiliary displacements on a fine mesh
1.31.28We shall generate the exact expected analytic solution for the gap conductance problem
1.31.29We shall be able to produce the expected result for a gap conductance test case using the mortar method. Specifically, this test yields lagrange multipliers that are correctly proportional to the delta of temperature across the gap, e.g. the heat flux
1.31.30The Jacobian for the gap conductance test case shall be perfect
1.31.31We shall be able to produce the expected result for a gap conductance test case using the mortar method on a fine mesh. Specifically, this test yields lagrange multipliers that are correctly proportional to the delta of temperature across the gap, e.g. the heat flux
1.31.32The system shall give access to the locations in physical space of mortar segment element quadrature points.
1.31.33The system shall compute an exact Jacobian for a simulation involving the physical space location of mortar quadrature points.
1.31.34We shall be able to enforce periodic boundary conditions on a non-uniform mesh using the mortar method
1.31.35The Jacobian for mortar enforcement of periodic boundary conditions shall be perfect

framework: Multiapps
1.32.1The system shall allow use of automatic differentiation and automatic scaling in sub-applications.
1.32.2The system shall support running a transient simulation with sub-applications that can fail and re-execute with smaller timesteps until the execution times for the master and sub-applications are equivalent.
1.32.3The system shall include the ability to execute a sub-application at the centroid of every element within the finite element mesh.
1.32.4The system shall detect input file problems with sub app input files.
1.32.5The system shall CLI argument problems related to sub app input files.
1.32.6The system show error when the number of input files is great than one and doesn't match the number of provided sub app positions.
1.32.7The system show error when the number of input files is great than one and doesn't match the number of provided sub app positions when using CLI overrides.
1.32.8The system shall error when the number of sub app input files doesn't match the number of provided positions files.
1.32.9The system shall error when both positions are provided in the input file along with a separate file of positions.
1.32.10The system shall error when the multiapp positions file is malformed.
1.32.11The system shall error when the Multiapp parameter sub_cycling and catch_up are both set to true.
1.32.12The MultiApp system shall include the ability to set command line parameters for each sub application from the input file.
1.32.13The MultiApp system shall include the ability to set common command line parameters for all sub applications from the input file.
1.32.14The MultiApp system shall error when the number of command line arguments supplied in the input file differs from the number if sub apps.
1.32.15The system shall include the ability to halt the execution of sub-applications when steady-state is detected.
1.32.16
The system shall be capable of executing a sub-application from a Steady executioner on
1. initial and
2. final.
1.32.17
The system shall be capable of executing a sub-application from a Eigenvalue executioner on
1. initial and
2. final.
1.32.18
When sub-application solve does not converge, the system shall be able to either
1. abort run,
2. throw error if error_on_dtmin is not set, or
3. continue run.
1.32.19
The system shall be able to use the solution of a coarse mesh as the initial guess for a fine mesh solution for a
1. diffusion problem and a
2. variational inequality problem resulting in a significantly reduced number of nonlinear iterations to solve the fine mesh problem
1.32.20The system shall be able to solve a fine mesh variational inequality problem without grid sequencing but with a lot more nonlinear iterations
1.32.21The system shall error if the execution of a sub-application fails during the initial execution.
1.32.22The system shall support creating a Multiapp that is not initially enabled
1.32.23MOOSE shall allow forcely evaluating general user objects on initial before applying initial conditions.
1.32.24
The system shall support the ability for a sub-application to adaptive modify the time step of the master application when the sub-application operates at the
1. beginning and
2. end of a timestep.
1.32.25The system shall support limiting the number of processors for sub-applications.
1.32.26
The system shall support the ability to re-position sub-applications at a specified time
1. for single and
2. multi-level sub-applications.
1.32.27
The system shall support the ability to re-position and reset sub-applications at a specified time
1. for single and
2. multi-level sub-applications.
1.32.28
The system shall support evaluating multi-level sub-applications:
1. where the master application controls the time step for all sub-applications;
2. where the master application controls the time step via a function for all sub-applications; and
3. where the sub-application controls the time step for the master application,
1.32.29The system shall support writing screen output from multi-level sub-applications to a file.
1.32.30The system shall be capable of running multiple sub-applications that are defined by input and position file pairs.
1.32.31
The system shall support outputting sub-application data in a specified position
1. for single and
2. multi-level sub-applications.
1.32.32The system shall support the the ability to set solver options within sub-applications.
1.32.33The system shall allow transient multiapps to use Picard iterations to rerun the time step
1.32.34The system shall support adaptive time stepping for transient multiapps with Picard iterations controlled by tolerances
1.32.35The system shall reject the solve if the maximum number of Picard iterations is reached without converging
1.32.36The system shall allow transient multiapps with Picard iterations controlled by relative tolerances
1.32.37The system shall allow transient multiapps with Picard iterations controlled by absolute tolerances
1.32.38The system shall allow function-defined time stepping for transient multiapps
1.32.39The system shall allow steady-state Picard iteration with multiapps
1.32.40The system shall allow fixed number of Picard iterations
1.32.41The system shall allow custom convergence check on Picard iteration with derived executioners
1.32.42The system shall allow steady-state Picard iteration with pseudo-transient multiapps
1.32.43The system shall allow convergence check with user defined postprocessor directly.
1.32.44The system shall allow convergence check with the convergence of a user defined postprocessor.
1.32.45The system shall show the Picard convergence history of a user defined postprocessor that is used for convergence check.
1.32.46The system shall support performing iterative solves of sub-applications that perform additional time steps to maintain time step consistency with the master application.
1.32.47The system shall support performing iterative solves of sub-applications that perform additional time steps to maintain time step consistency with the master application that re-uses the previous solution as the initial condition for subsequent iterations.
1.32.48Multiapps shall be able to be restored when a subapp encounters a solve failure.
1.32.49CSV file writing should remain unaffected when a subapp encounters a solve failure.
1.32.50Multiapps shall be able to cut the master app time step when any subapp encounters a solve failure.
1.32.51The system should be able to restart from the latest solution
1.32.52The system should be able to check if users provide valid parameter to restart app using the latest solution
1.32.53The system shall support Picard iteration with a FullSolveMultiApp at the root with multiple multiapp levels.
1.32.54The system shall be able to run multiple timesteps of a multi-level multi-app simulation, handling the case when Picard coupling between two levels fails to converge.
1.32.55The system shall be able to uniformly cut the time-step across levels of a multi-app solve, even when there is no Picard coupling between two levels.
1.32.56The system shall support Picard iteration with multiple levels of Multiapps.
1.32.57The system shall support the evaluation of TIMESTEP_BEGIN and TIMESTEP_END norms even when there are not active Multiapps on both of those execute_on times.
1.32.58The system shall support performing iterative solves of sub-applications that used smaller time steps than master application.
1.32.59The system shall support evaluating sub-applications at spatial positions specified in a file.
1.32.60The system shall provide an ability to perform iterative solves with sub-applications.
1.32.61The system shall provide an ability to relax solutions with iterative solves with sub-applications.
1.32.62The system shall provide an ability to relax sub-applications solutions along with the master solution for during iterative solves.
1.32.63The system shall provide an ability to relax solutions of array variables with iterative solves with sub-applications.
1.32.64The system shall error if provided relaxation factor that is less than or equal to 0 or greater than or equal to 2.
1.32.65
The system shall support the ability to reset a sub-application at a specified time during the simultation
1. for single and
2. multi-level sub-applications.
1.32.66
The system shall support simulations that
1. that execute sub-applications, which
2. are capable of being restarted from a previous simulation.
1.32.67
The system shall support simulations that
1. that execute with multi-level sub-applications, which
2. are capable of being restarted from a previous simulation.
1.32.68
The system shall support simulations that
1. that executes sub-applications, which
2. can restart from a previous simulation and project the initial condition from the previous solution to the current, restarted simulation.
1.32.69The system shall support executing sub-applications that operate with smaller time steps then the master application that include material properties that are based on previous time steps.
1.32.70
The system shall support the execution of sub-applications that operate with smaller time steps then the master application:
1. with a sub-application that continues to the end time of the master application and
2. with a sub-application that specifies and completion time prior to the master application.
1.32.71The system shall support the output of sub-application data that operate with smaller time steps then the master application.
1.32.72The system shall support the execution of sub-application that operate with adaptive time steps that differ from the master application.
1.32.73The system shall support sub-cycling with negative times by particularly ensuring that the sub-app does not advance further than the main app.
1.32.74
The system shall support the failure of sub-application that operates with differing time steps than the master application.
1. The simulation shall continue by reducing the time step and
2. support the failure and the ability to limit the number of processors for the sub-application.
1.32.75The system shall support a time offset between the master and a subapp when using the Multiapp system.
1.32.76
The system shall support the execution of sub-applications:
1. with a time step governed by the sub-application and
2. with a time step governed by the master application.
1.32.77The system shall support negative times by particularly ensuring that the sub-app properly updates its time without sub-cycling.

framework: Nodalkernels
1.33.1
The system shall include ability to include contributions to the residual nodes of a finite element mesh
1. on a single and
2. multiple threads.
1.33.2
The system shall be able to enforce a lower bound on a variable using nodal NCP, nodal application of resultant forces,
1. have no oscillations in the solution, and
2. have a non-singular matrix
1.33.3
The system shall be able to enforce an upper bound on a variable using nodal NCP, nodal application of resultant forces,
1. have no oscillations in the solution, and
2. have a non-singular matrix
1.33.4
The system shall be able to enforce an upper and lower bound on a variable using nodal NCP, nodal application of resultant forces,
1. have no oscillations in the solution, and
2. work with automatic differentiation, and
3. have a non-singular matrix, and
4. be incompataible with algebraic multigrid
1.33.5
The system shall be able to enforce an upper and lower bound on a variable using a variational inequality
1. reduced space active set solver, which
2. is compatible with algebraic multigrid, and
3. a semi-smooth solver, which
4. is also compatible with algebraic multigrid
5. The reduced space active set method shall work with a matrix-free approximation of the Jacobian, and the function evaluations corresponding to the nonlinear residual and the base for finite-differencing shall be equivalent.
1.33.6The system shall show violation of bounds when a non-variational-inequality solver is used
1.33.7The system shall support the use of Crank-Nicolson time integration scheme.
1.33.8The system shall include ability to include contributions to the residual nodes of a finite element mesh using an LU preconditioner.
1.33.9
The system shall include ability to include contributions to the residual nodes of a finite element mesh and compute the correct Jacobian terms for
1. subdomain and
2. boundary restricted terms.
1.33.10The system shall not duplicate computation of kernels on a node that is shared between two subdomains.
1.33.11MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method for nodesets.
1.33.12The system shall apply scaling to residuals and Jacobians for volumetric PDE terms applied at nodes

framework: Outputs
1.34.1The system shall support the ability to append the date to output filenames.
1.34.2
The system shall support outputting of checkpoint files:
1. at a specific interval while only maintaining a specified number of recent files and
2. be capable of restarting a simulation from previously exported data at this interval.
1.34.3
The system shall support outputting of checkpoint files, using a simplified input format:
1. at every timestep while maintaining the most recent two files and
2. be capable of restarting a simulation from the output data.
1.34.4
The system shall support outputting of checkpoint files, using a complete input block:
1. at every timestep while maintaining the most recent two files and
2. be capable of restarting a simulation from the output data.
1.34.5The system shall support outputting of simulation data using the ExodusII format using simplified input file syntax.
1.34.6
The system shall by default display data on the console from:
1. the Postprocessor system and
2. the scalar variable system.
1.34.7The system shall output a running list of Picard norms during Picard iteration.
1.34.8The system shall only output Picard TIMESTEP_BEGIN norms when there are no TIMESTEP_END Multiapps.
1.34.9The system shall only output Picard TIMESTEP_END norms when there are no TIMESTEP_BEGIN Multiapps.
1.34.10The system shall output Picard norms for TIMESTEP_BEGIN and TIMESTEP_END Multiapps when both exist in the simulation.
1.34.11The system shall run a simulation without producing any file-based output.
1.34.12The system shall support outputting table based Postprocessor data.
1.34.13The system shall output Scalar Variables on the console in a table to the screen.
1.34.14The system shall warning when multiple console outputs attempt to write to the screen simultaneously.
1.34.15The system shall support outputting console information to a file.
1.34.16The system shall output Scalar Variables on the console in a table to a file.
1.34.17The system shall support outputting Scalar Variables to a file.
1.34.18The system shall support writing the console solve log to an output file.
1.34.19The system shall support writing norms to the console for each nonlinear variable in the simulation.
1.34.20The system shall output a Performance log based on a command line flag.
1.34.21The system shall support writing negative time information in the console.
1.34.22The system shall support outputting the Performance Log at user specified intervals.
1.34.23The system shall support writing to a buffered console object from every MooseObject-derived object.
1.34.24The system shall support writing to a buffered console object from const methods in MooseObject-derived objects.
1.34.25The system shall support outputting a transformed input file to the screen.
1.34.26The system shall support disabling the linear residual output.
1.34.27The system shall output a Performance Log based on a single input file parameter.
1.34.28The system shall override Performance Log output when conflicting values appear on the command line and input file.
1.34.29The system shall support adding an additional output time option without clobbering existing default options.
1.34.30The system shall output a "final" label at the end of the simulation before additional screen output occurs.
1.34.31The system shall error when specifying an invalid table fit width option.
1.34.32The system shall support the output of postprocessors and scalars to CSV files for steady state problems.
1.34.33The system shall support the output of postprocessors and scalars to CSV files for transient propblems.
1.34.34The system shall support the output of postprocessors and scalars to CSV files for transient problems without a time column.
1.34.35The system shall support the output of postprocessors and scalars to Exodus files for transient problems.
1.34.36
The system shall support the output of CSV data:
1. with checkpoint enabled and
2. when restarted creates a new output file or
3. optionally appends the existing file from the first part.
1.34.37The system shall support CSV output aligned columns and a custom delimiter.
1.34.38The system shall support CSV output to the console that is sorted by the variable name.
1.34.39The CSV output object shall create a symlink to the final output with with a '_FINAL' suffix for VectorPostprocessor data when there are execute flags in addition to FINAL.
1.34.40The CSV output object shall create a symlink to the final output with with a '_FINAL' suffix for VectorPostprocessor data when the execute flag is set to FINAL.
1.34.41The CSV output object 'create_final_symlink' parameter shall be able to disable the creation of the final symlink.
1.34.42The CSV output object shall create a symlink to the most recent output with with a '_LATEST' suffix for VectorPostprocessor data.
1.34.43The CSV output object 'create_latest_symlink' parameter shall be able to disable the creation of the latest symlink.
1.34.44The system shall be include the ability to display variable residual norms.
1.34.45The system shall include debug syntax that includes the ability to enable variable residual norm output.
1.34.46The system shall be include the ability to display material property information.
1.34.47The system shall include debug syntax that includes the ability to enable material property information output.
1.34.48The system shall be include the ability to display residual information for variables.
1.34.49The system shall include debug syntax that includes the ability to enable variable residual information.
1.34.50The system shall be include the ability to display residual information for variables that is limited to non-linear iterations.
1.34.51The system shall be include the ability to display residual information for scalar variables.
1.34.52The system shall include debug syntax that includes material property consumption information.
1.34.53The system shall be able to output the ~~displaced~~ mesh for a model with adaptive mesh refinement.
1.34.54If the user requested the output of a displaced problem and there is none present, the system shall fallback to using the non-displaced problem.
1.34.55If the user asks for no displaced mesh to be created, even though displacements are provided in the mesh block, the system shall not create a displaced mesh
1.34.56The Output system shall be capable of applying displacements directly to the outputted mesh for steady problems.
1.34.57The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems with Kernels using the displaced configuration.
1.34.58The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems.
1.34.59
The system shall support the ability to output the degree-of-freedom information:
1. to a json file,
2. to the screen,
3. with uniform refinement, and
4. with transient adaptivity.
1.34.60The system shall error when two outputs with the same name are created.
1.34.61The system shall error when two outputs produce a file with the same name.
1.34.62
The system shall reserve names for output objects:
1. "none" and
2. "all."
1.34.63The system shall support ExodusII output.
1.34.64The system shall support including the executed input file within the ExodusII output.
1.34.65The system shall support inclusion of initial condition data within the ExodusII output.
1.34.66The system shall support writing non-linear, auxililary, scalar, and postprocessor variables to ExodusII format.
1.34.67The system shall support the exclusion of non-linear, scalar, and postprocessor variables from ExodusII output.
1.34.68The system shall error if the supplied names for including or excluding variables is invalid.
1.34.69The system shall support outputting elemental and scalar variables as nodal variables within ExodusII output.
1.34.70The system shall support outputting discontinuous finite element types with the ExodusII format.
1.34.71Nemesis output shall work
1.34.72GMV output shall work
1.34.73We shall be able to dump YAML data
1.34.74Executioner output shall only be given once
1.34.75Tecplot output shall work
1.34.76If tecplot api is available, tecplot output will be given in tecplot binary format
1.34.77If tecplot api is not available, tecplot output will be given in ASCII format
1.34.78We shall be able to generate gnuplot postscript output
1.34.79We shall be able to generate gnuplot png output
1.34.80We shall be able to generate gnuplot gif output
1.34.81If a postprocessor utilizes the "outputs" parameter, but postprocessor output is disable for the console object, we shall warn the user
1.34.82–show-input shall print parameters
1.34.83Solution history output shall work
1.34.84MOOSE shall support XDR output
1.34.85The system shall be able to dump input file syntax in JSON format
1.34.86The system shall be able to dump input file syntax in JSON format and exclude test object syntax.
1.34.87The system shall be able to dump a subset of JSON formatted syntax.
1.34.88The system shall dump line information along with JSON formatted syntax.
1.34.89The system shall not include RESIDUAL and JACOBIAN template arguments in the JSON syntax format.
1.34.90The system shall be able to dump input file (HIT) syntax.
1.34.91The system shall be able to dump a subset of input file (HIT) syntax.
1.34.92MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check InputChoices
1.34.93MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ChildAtLeastOne
1.34.94MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ValEnums
1.34.95MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check active parameter
1.34.96MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check normal_sub
1.34.97MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check type_sub
1.34.98MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check default type
1.34.99MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check MinValInc
1.34.100MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check Block type MaxOccurs NoLimit
1.34.101MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check FunctionName type MaxOccurs NoLimit
1.34.102MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check Array type MinOccurs zero
1.34.103The system shall support outputting data to the general mesh viewer format.
1.34.104The system shall support limiting vector postrocessor data to a specific CSV output object.
1.34.105The system shall support the ability to control the output of an aggregate calculation via a parameter of the object itself.
1.34.106The system shall support specifying an output interval for an output input file block.
1.34.107The system shall support specifying an output interval for all outputs.
1.34.108The system shall support limiting output to the final timestep of a simulation.
1.34.109The system shall support output at specific simulation times.
1.34.110The system shall support multiple output objects that have different simulation synchronization times specified.
1.34.111The system shall support the disabling of an output object by restricting the execution settings.
1.34.112The system shall support the ability to limit output objects only at the beginning and end of a simulation.
1.34.113The system shall not output the same information multiple times when an output object is defined to operate on the end of each timestep and the final timestep.
1.34.114The system shall support output during linear and non-linear iterations during transient simulations using the ExodusII format.
1.34.115
The system shall support output during linear and non-linear iterations during steady simulations using the ExodusII format:
1. in a single file or
2. in a sequence of files.
1.34.116The system shall support output during linear and non-linear iterations during transient simulations using the VTK format.
1.34.117The system shall support output during linear and non-linear iterations during transient simulations using the CSV format.
1.34.118
The system shall support output during linear and non-linear iterations during transient simulations:
1. with both the start and end times defined,
2. with only the start time defined,
3. with the start and end timestep provided,
4. with the start timestep given, and
5. with the end timestep provided.
1.34.119The system shall support JSON output for data.
1.34.120
The system shall include the ability to output simulation data in JSON format:
1. that produces multiple files for parallel distributed data and
2. for parallel replicated data in a single file.
1.34.121The system shall provide an API for retrieving an output object by type and name.
1.34.122The system shall provide an API for retrieving all output objects of a type.
1.34.123The system shall provide an API for retrieving output objects for the given names and type.
1.34.124The system shall provide an API for retrieving all output object names of a type.
1.34.125The system shall support the naming of output files based on the input file block name.
1.34.126The Nemesis Output object shall output separate files per process for visualization purposes.
1.34.127The Nemesis Output object shall support writing elemental variables.
1.34.128The Nemesis Output object shall support writing elemental variables with the same numbering on DistributedMesh.
1.34.129The Nemesis Ouput object shall support writing scalar variables.
1.34.130The Nemesis Ouput object shall support writing scalar variables when using DistributedMesh.
1.34.131The system shall support the ability to specify the output dimension when outputting in ExodusII format.
1.34.132The system shall support the ability to limit output to certain sub-applications based on name.
1.34.133
The system shall include the ability to limit automatic output of adaptivity objects, including
1. indicators and
2. markers.
1.34.134The system shall allow the user to select different console output intervals.
1.34.135The system shall display active output information with corresponding execute flags.
1.34.136
The system shall provide a system for outputting solution variables with a uniformly refined mesh:
1. with a shift in output position,
2. with a custom filename,
3. with mesh adaptivity,
4. with a generated mesh,
5. with a file mesh, and
6. with second order elements from a file mesh.
1.34.137
The system shall include an example demonstrating the use of oversampling.
1. without and
2. with mesh adaptivity.
1.34.138The system shall include the ability to overwrite existing timesteps when writing ExodusII format.
1.34.139
The system shall output a performance log information for sub-applications
1. that are transient,
2. use differing time steps from the main, and
3. execute an entire simulation.
1.34.140MOOSE shall have the ability to output a detailed performance log
1.34.141
MOOSE shall be able to produce png images:
1. for 2D square images,
2. arbitrary shapped domains,
3. and complex shapes with periodic boudary conditions.
1.34.142The system shall support offseting the spatial position of a domain during output.
1.34.143The system shall support the ability to specify the output object for postprocessor data from within the input file block defining the postprocessor.
1.34.144The system shall error if an invalid output name is provided within the postprocessor input file block.
1.34.145The system shall support limiting postprocessor output to the screen.
1.34.146The system shall support limiting postprocessor output to from within the input file syntax of an output object.
1.34.147The system shall error if a postprocessor variable is listed for suppression and inclusion within an output object block in the input file.
1.34.148
The system shall support limiting the output of comma seperated value data to the final timestep:
1. for all scalar data and
2. for postprocessor data only.
1.34.149The system shall support the ability to output single value aggregate calculations to JSON format.
1.34.150Correctly set up initial recover files for the part2 test.
1.34.151A simulation executed using the "–recover" flag successfully runs a simulation using the specified recover file argument.
1.34.152Correctly set up initial recover files for the part2_latest test.
1.34.153A simulation executed using the "–recover" flag with a file argument using the placeholder "LATEST" successfully runs a simulation using most recent checkpoint/recover file from the specified directory.
1.34.154
The system shall automatically output values to a comma separated (CSV) file in
1. root/replicated mode
2. and distributed mode.
1.34.155The system shall support the ability to output the residual norms of individual nodal variables.
1.34.156The system shall support the ability to output the residual norms of individual elemental variables.
1.34.157The system shall support writing file to sub-directories.
1.34.158The system shall print the various components of the simulation information header to the screen
1.34.159The system shall print the mesh information to the screen when the mesh changes
1.34.160The system shall print the auxiliary system information to the screen when the mesh changes
1.34.161The system shall print the nonlinear system information to the screen when the mesh changes
1.34.162The system shall support Tecplot output.
1.34.163The system shall support appending Tecplot output files.
1.34.164The system shall optionally support writing binary Teckplot files.
1.34.165
The system shall guarantee that scalar variables are in the proper state for output when outputting:
1. ExodusII format and
2. CSV format.
1.34.166The system shall support outputting field and scalar data to the ExodusII format.
1.34.167The system shall error if a variable is marked for output and output suppression.
1.34.168The system shall error if a variable is perscribed for output but does not exist.
1.34.169The system shall test that output of an auxiliary field can be disabled within the input block defining the variable.
1.34.170The system shall support a system for including or suppressing output variables the operates when only a single variable for each type exists.
1.34.171The system shall support a system for including or suppressing output variables.
1.34.172The variables specified in an Output object's 'hide = ' list shall not appear in the output file.
1.34.173The system shall support the ability to output vector aggregate calculations to JSON format.
1.34.174
The system shall optionally support output of files using the VTK format:
1. in serial and
2. in parallel.
1.34.175
The system shall support the output of data using native libMesh formats:
1. in XDA (ASCII) format and
2. in XDR (binary) format.
1.34.176The system shall support simultaneous output of the ASCII and binary forms of the libMesh native format.
1.34.177
The system shall support XML output for vector data that is
1. replicated or
2. distributed in parallel.
1.34.178The system shall support XML output for vector data during nonlinear solve.

framework: Parser
1.35.1The system shall support active/inactive parameters to selectively enable/disable subblocks within all input file blocks.
1.35.2The system shall produce an error when the active parameter refers to a non-exiseant block.
1.35.3The system shall produce an error when the inactive parameter refers to a non-existent block.
1.35.4The system shall produce an error when both the active and inactive parameters are present in the same block.
1.35.5The system shall honor the active or inactive parameters at the top (root) level.
1.35.6The system shall support the ability to override input file parameters from the command line.
1.35.7The system shall support the ability to globally change MultiApp input file syntax from the command line.
1.35.8The system shall support the ability to change a whole MultiApp's (multiple SubApps) input file syntax from the command line.
1.35.9The system shall support the ability to change individual SubApp input file syntax from the command line.
1.35.10The system shall produce an error when a SubApp command line override index is not valid.
1.35.11The system shall output all registered objects in HIT format.
1.35.12The system shall output all registered objects in single line format.
1.35.13The system shall report an error if the supplied input file is not formatted correctly.
1.35.14The system shall be able to read input file syntax and write into map parameters.
1.35.15The system shall error if a user supplies an odd number of entries, implying an unbalanced key-value set, to a map parameter.
1.35.16The system shall error if a user supplies syntax in a map parameter that cannot be cast to the requested mapped type.
1.35.17The system shall support parameter substitution in input files using command line variable expressions.
1.35.18The system shall support parameter substitution in input files using variable expressions from within the same input file.
1.35.19The system shall support unit conversion in input files using variable expressions.
1.35.20The system shall support reading in jagged double-indexed arrays from the input file using two delimiters for columns and rows respectively.
1.35.21
The system shall support vector size checking on input parameter vectors:
1. for ints,
2. for Reals.
1.35.22
The system shall support vector element checking:
1. against constant expressions,
2. against other unsigned int vector elements,
3. against other long vector elements,
4. against other int vector elements, and
5. against other Real vector elements.
1.35.23The system shall support vector bounds checking on input parameter vectors.
1.35.24The system shall support checking for non-empty input parameter vectors.

framework: Partitioners
1.36.1
The system shall support a block-weighted partitioner
1. when using ReplicatedMesh
2. and when using DistributedMesh.
1.36.2MOOSE shall provide a simple regular grid-based partitioner
1.36.3MOOSE shall have the ability to do hierarchical partitioning based on a regular grid.
1.36.4Make MOOSE support ptscotch via PETSc
1.36.5ptscotch shall support element-weighted graphs for balancing workload
1.36.6ptscotch shall support side-weighted graphs for minimizing communication
1.36.7ptscotch shall take both side weights and element weights into consideration
1.36.8Make MOOSE support parmetis via PETSc
1.36.9Parmetis shall support element-weighted graphs for balancing workload
1.36.10Parmetis shall support side-weighted graphs for minimizing communication
1.36.11Parmetis shall take side weights and element weights into consideration
1.36.12Parmetis shall support presplit
1.36.13MOOSE shall support a serial partitioner Chaco
1.36.14MOOSE shall support a serial partitioner party
1.36.15MOOSE shall provide a random partitioner

framework: Phi Zero
1.38.1The system shall be able to construct zero objects for shape functions and shape function gradients consistent with the maximum number ofshape functions and quadrature points in the simulation.
1.38.2The system shall be able to construct zero objects for shape functions and shape function gradients consistent with the maximum number ofshape functions and quadrature points in the simulation. This test checks the size of zero objects when using second-order elements and second order-variables.

framework: Postprocessors
1.39.1The AreaPostprocessor shall compute the "area" or dimension - 1 "volume" of sides.
1.39.2
The system shall compute the average value of a field variable over time
1. at the end of a time step and
2. and at the beginning of the time step.
1.39.3The system shall compute the average value of a quantity along the axis of rotation in an axisymmetric coordinate system.
1.39.4
The system shall support calculating the value change over time
1. with respect to the previous calculation and
2. with respect to the initial calculation.
1.39.5
The system shall issue an error when the dependent "change of time" calculation
1. "with respect to initial" isn't calculated at the initial step and
2. "with respect to previous" isn't calculated at the previous step.
1.39.6The system shall allow for the retrieval of raw elemental degree-of-freedom values directly for elemental evaluations.
1.39.7The system shall have the ability to accumulate a scalar value over time.
1.39.8
The system shall the substitution of a constant value in place of an optional Postprocessor coupling value
1. when that value is supplied as a default in the coupling declaration
2. or when that value is supplied in the input file.
1.39.9The system shall support computing the difference between two scalar Postprocessor values.
1.39.10The system shall execute dependent Postprocessors first when computing the difference between two Postprocessors.
1.39.11
The system shall support running Postprocessors on the the mesh containing displacements:
1. elemental and
2. side.
1.39.12The system shall compute the the average value of a non-AD material property over the domain.
1.39.13The system shall compute the the average value of an AD material property over the domain.
1.39.14
The system shall contain a "Postprocessor" that computes the average value of a variable
1. one a single block and
2. on multiple blocks.
1.39.15The system shall compute the the extreme (min/max) values of a non-AD material property over the domain.
1.39.16The system shall compute the the extreme (min/max) values of an AD material property over the domain.
1.39.17The system shall compute the the extreme (min/max) values of an elemental field variable over the domain.
1.39.18The system shall compute the H1-seminorm between a field variable and a analytical function.
1.39.19
The system shall compute the element integral of a variable
1. over the whole domain and
2. over a subset of the domain.
1.39.20The system shall compute the average integral quantity over an element of a scalar material property.
1.39.21
The system shall support computing the integral of a variable quantity over the domain on the mesh
1. during the initial setup step
2. and at the end of each time step, for FE variables
3. and FV variables.
1.39.22The system shall compute the L1 error between an elemental field variable and an analytical function.
1.39.23The system shall compute the element-wise L2 difference between two field variables.
1.39.24The system shall compute the L2-error (Euclidean) between a field variable and a analytical function.
1.39.25The system shall compute the volumetric L2 norm of a variable over the mesh.
1.39.26The system shall compute the average time derivative of a solution value computed per element in 2D.
1.39.27The system shall compute the average time derivative of a solution value computed per element in 1D.
1.39.28The system shall support sampling a specific quantity integrated over a single element.
1.39.29The system shall support sampling a specific quantity integrated over a single element with finite volume variables.
1.39.30The system shall compute the Vector L2 Error of three scalar variables simultaneously as three orthogonal components of a vector.
1.39.31Postprocessor objects shall be able to execute and output after the simulation is complete.
1.39.32The system shall support an attribute (scalar value) reporter through the "Execution" system.
1.39.33The system shall be capable of find a value on a monotonically changing line.
1.39.34The system shall report and error when the target value is lower than one of the sampled endpoints.
1.39.35The system shall report and error when the target value is greater than one of the sampled endpoints.
1.39.36The system shall return the default flag value when the target value is lower than one of the sampled endpoints and error_if_not_found is false.
1.39.37The system shall return the default flag value when the target value is greater than one of the sampled endpoints and error_if_not_found is false.
1.39.38The system shall return user specified flag value when the target value is lower than one of the sampled endpoints and error_if_not_found is false.
1.39.39The system shall return user specified flag value when the target value is greater than one of the sampled endpoints and error_if_not_found is false.
1.39.40The system shall report and error when the sampling line extends beyond the mesh bounding box.
1.39.41The system shall report and error when the line sampling algorithm fails to converge within the desired depth.
1.39.42The system shall integrate functions over volume.
1.39.43The system shall compute the integral of a function over a boundary.
1.39.44The system shall support evaluating a function of space and time at a single point as a Postprocessor value.
1.39.45The system shall be able to correctly compute the volume of blocks and the area of sidesets in 3D.
1.39.46The system shall be able to correctly compute the area of blocks and the perimeterof sidesets in 2D and appropriately handle boundary conditions applied to sidesetscreated with respect to different bodies.
1.39.47Testing the implementation of the InterfaceAverageVariableValuePostprocessor By design at the end of the first step we should observe: an average material property of 7, an average material property absolute jump to 6,a signed material property jump (primary minus secondary) of 6, a signed material propertyjump (secondary minus primary) of -6, a material property value on the primary side of 10, a material property value on the primary side of 4
1.39.48Testing the implementation of the InterfaceIntegralVariableValuePostprocessor By design at the end of the first step we should observe: an integral material property of 21, an integral material property absolute jump to 18,a signed integral material property jump (primary minus secondary) of 18, a signed integral material propertyjump (secondary minus primary) of -18, a material integral property value on the primary side of 30, a material integral property value on the primary side of 12
1.39.49Testing the implementation of the InterfaceAverageVariableValuePostprocessor for finite volume variables.By design at the end of the first step we should observe: an average material property of 7, an average material property absolute jump to 6,a signed material property jump (primary minus secondary) of 6, a signed material propertyjump (secondary minus primary) of -6, a material property value on the primary side of 10, a material property value on the primary side of 4
1.39.50Testing the implementation of the InterfaceIntegralVariableValuePostprocessor for finite volume variables.By design at the end of the first step we should observe: an integral material property of 21, an integral material property absolute jump to 18,a signed integral material property jump (primary minus secondary) of 18, a signed integral material propertyjump (secondary minus primary) of -18, a material integral property value on the primary side of 30, a material integral property value on the primary side of 12
1.39.51The system shall support retrieving solution values from neighboring elements for use in internal side calculations.
1.39.52The system shall support the ability to compute a linear combination of scalar values (Postprocessors).
1.39.53The system shall allow a mix of postprocessor names and real numbers to be provided to PostprocessorName parameters.
1.39.54MOOSE 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
1.39.55MOOSE shall provide a vectorpostprocessor to on each rank measure physical and virtual memory usage, major page fault count, and total available ram available, depending on the operating system's ability to make those values available
1.39.56The system shall verify calculations using the method of manufactured solutions using a higher order polynomial function for linear elements.
1.39.57
The system shall verify calculations using the method of manufactured solutions using sine functions for linear elements:
1. on a 3D mesh
2. verified with an analytical 3D solution and
3. on a 2D mesh
4. verified with an analytical 2D solution.
1.39.58The system shall verify calculations using the method of manufactured solutions using a functional form of an equation outside of the shape function space.
1.39.59The system shall compute the the extreme (min/max) values of a nodal field variable over the domain.
1.39.60
The system shall compute the maximum value of a field variable by sampling nodes
1. over the whole domain and
2. within a subdomain.
1.39.61
The system shall compute the sum of nodal values of a variable
1. on the whole domain,
2. on a subset of the domain, and
3. on multiple overlapping blocks visiting some nodes multiple times.
1.39.62
The system shall report the value of a variable at a specified node
1. for auxiliary variables and
2. for primary (nonlinear) variables.
1.39.63
The system shall support selecting the output for a single Postprocessor
1. to a file and
2. to the console.
1.39.64The system shall be capable of running multiple adaptivity cycles in a single solve step.
1.39.65They system shall be capable of toggling adaptivity at the start of the simulation.
1.39.66They system shall be capable of toggling adaptivity during the simulation.
1.39.67The NumDOFs Postprocessor shall report the number of degrees of freedom (DOFS) from one or more equations systems in the simulation.
1.39.68The NumElems Postprocessor shall report the number of elements (active or total) in the simulation.
1.39.69The NumElems Postprocessor shall report the number of elements (active or total) in the simulation when using distributed (pre-split) mesh.
1.39.70
The system shall support time integration schemes that compute a consistent number of nonlinear and linear iterations for
1. four stage, A-stable DIRK;
2. explicit Euler;
3. lumped explicit Euler;
4. lumped and preconditioned explicit Euler;
5. second-order backward difference;
6. Crank-Nicloson;
7. quasi explicit Euler;
8. explicit midpoint;
9. two-stage TVD Runge-Kutta;
10. Heun;
11. implicit Euler;
12. implicit midpoint;
13. two-stage, L-stable DIRK;
14. three stage, L-stable DIRK;
15. four stage, L-stable DIRK;
16. and Ralston methods.
1.39.71The NumNodes Postprocessor shall report the number of nodes (replicated or distributed) in the simulation.
1.39.72The NumNodes Postprocessor shall report the number of nodes in the simulation when using distributed (pre-split) mesh.
1.39.73The system shall be capable of outputting the number of Residual evaluations
1.39.74The NumVars Postprocessor shall report the number of variables from one or more equation systems in the simulation.
1.39.75
The system shall support the ability to retrieve previously computed Postprocessor values within a Postprocessor calculation:
1. old (one timestep back) and
2. older (two timesteps back).
1.39.76The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors.
1.39.77The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors while maintaining vector history.
1.39.78MOOSE shall have the abililty to pull time from the PerfGrahp into a Postprocessor
1.39.79The system shall support the ability to sample a field variable value anywhere within the domain.
1.39.80The system shall report an error when a field variable sample location is outside of the domain.
1.39.81
The system shall include the ability to compare post-processor data and return a boolean value for
1. greater than operator and the
2. less than operator.
1.39.82The system shall support evaluating Postprocessors (UserObjects) in the following order: Elemental, Side, Internal Side, Nodal, and General.
1.39.83
The system shall support outputting the scalar Postprocessor values at specific intervals
1. to a file and
2. to the console.
1.39.84The system shall support outputting the scalar Postprocessor values to multiple locations with different intervals.
1.39.85The system shall have the ability to output performance data to a file.
1.39.86The system shall calculate performance time when the data is only used by a Postprocessor.
1.39.87The system shall calculate performance time even when the performance graph isn't printed to any output format.
1.39.88
The system shall compute parallel-agnostic random numbers in the Postprocessor system
1. when running a complete simulation, or
2. when running the first half of the simulation and
3. running the second half of the simulation with recovery and receiving the same values.
1.39.89The system shall support the ability to report an input parameter on the screen or to an input file.
1.39.90
The system shall report an error when a requested parameter for reporting does not exist
1. with a wildcard in the name and
2. a complete name/
1.39.91
The system shall support the ability to report a scalar value set by arbitrary objects in the simulation
1. with an initial default value and
2. with a default previous (older) value.
1.39.92
The system shall support computing the relative difference between two scalar values (Postprocessors)
1. when values are non-zero, and
2. when values are approximately zero.
1.39.93The system shall be capable of computing the relative norm of the solution difference between two consecutive time steps.
1.39.94The system shall support coupling in a scalar variable to the Postprocessing system for calculating values.
1.39.95The system shall support reporting scalar variables as Postprocessor (scalar output) values.
1.39.96The system shall support the scaling of a post processor quantity by another post processor quantity.
1.39.97The system shall compute the area-weighted average of the integral of a variable over a side.
1.39.98The system shall be capable of computing the average of the integral through a specified boundary on the mesh.
1.39.99The system shall be capable of computing the average of the diffusive flux integral of a finite volume variable through a specified boundary on the mesh.
1.39.100The system shall support computing the integral of a variable quantity over a side on the mesh.
1.39.101The system shall support computing the integral of a finite volume variablequantity over a side on the mesh.
1.39.102The system shall compute an aggregate scalar quantity when applied along multiple boundaries.
1.39.103The TableOutput object shall allow the user to override tolerance checks when determining whether new rows should be added (independent variable delta)
1.39.104The system shall have the ability to record a minimum or maximum value of a field variable over time.
1.39.105The system shall include the ability to compute the inner product of two variables.
1.39.106The system shall compute the difference between the test and trial functions (Residual) for a specified variable.
1.39.107
Vector post-processor values shall be able to be compared and return a boolean value for
1. greater than or equal,
2. greater than,
3. less than, or
4. equal.
1.39.108The system shall provide a Postprocessor that returns a single specified component of a VectorPostprocessor
1.39.109The Postprocessor that returns a single specified component of a VectorPostprocessor shall generate an error if the requested component is out of the range of the vector
1.39.110The system shall have the capability of computing the volume of the mesh domain.

framework: Preconditioners
1.40.1The system shall support the disabling of an automatically created preconditioning object when preforming a Newton solve.
1.40.2The system shall automatically create the correct preconditioning object when preforming a Newton solve.
1.40.3The system shall not automatically create a preconditioning object when preforming a Newton solve if the auto preconditioning capability is disabled.
1.40.4The system shall produce a perfect coloring for the Jacobian when using the finite difference preconditioner.
1.40.5The system shall produce a perfect Jacobian when using the stadard finite difference preconditioner.
1.40.6The system shall detect missing off-diagonal Jacobian entries when using a full finite different preconditioner.
1.40.7
The system shall support the use of field split preconditioner on
1. a single subdomain and
2. multiple subdomains.
1.40.8The system shall support the use of HMG (high performance MG)
1.40.9The system shall support the use of HMG (high performance MG) for 3D problems
1.40.10The system shall support the use of strumpack (sparse direct solver) for 3D problems
1.40.11The system shall support the ability to use multiple cycles within hypre during preconditioning with PETSc.
1.40.12
The system shall support the use of a physics based preconditioner
1. without and
2. with mesh adaptivity.
1.40.13The system shall support the ability to add arbitrary options to the solver when using a physics based precondioner.
1.40.14The system shall support the ability to control the variable solve order when using a physics base preconditioner.
1.40.15The system shall support the ability to use the conjugate gradient method for preconditioning with PETSc.
1.40.16
The system shall support the use of a single matrix preconditioner
1. without and
2. with mesh adaptivity.
1.40.17The system shall support the ability to group variables when using a single matrix preconditioner.

framework: Predictors
1.41.1The system shall include a means for predicting future solution based on previous solutions.
1.41.2The system shall include a means for predicting future solution based on previous solutions and print the scale factor to the output stream.
1.41.3
The system shall support the ability to skip performing solution predictions
1. using solution times or
2. previous solution times.
1.41.4The system shall support the ability to skip a prediction after a failed time step

framework: Problems
1.42.1The system shall allow the creation of a custom problem through a user-defined Action.
1.42.2The system shall support the creation of a custom problem with parameters in Problem block.
1.42.3The system shall error out when Problem block type is not specified.
1.42.4The system shall support the creation of a custom problem through Problem block with type specified.
1.42.5The system shall support the ability to extend the basic "Problem" interface.
1.42.6MOOSE shall have a capability to dump the equivalent input file syntax for all objects added by a given action.
1.42.7
The system shall include the support for Eigen value calculations that utilize
1. an array of residual contributions;
2. multiple variables; and
3. multiple variables with Eigen values include in preconditioning matrix.
1.42.8Eigenvalue system should support standard eigenvalue problems
1.42.9Eigenvalue system should support generalized eigenvalue problems
1.42.10Eigenvalue system should support IntegratedBC
1.42.11Eigenvalue system should not allow users to use inhomogeneous nodal boundary conditions
1.42.12Eigenvalue system should use homogeneous boundary conditions only
1.42.13Eigenvalue system requires SLEPc installed
1.42.14Eigenvalue system should be able to solve a nonlinear eigenvalue problem
1.42.15Eigenvalue system should be able to solve a nonlinear eigenvalue problem using Newton
1.42.16Eigenvalue system should be able to solve a deficient eigenvalue problem
1.42.17Eigenvalue system should be able to compute a nonlinear eigenvalue problem
1.42.18Eigenvalue system should be able to compute a coupled nonlinear eigenvalue problem
1.42.19Eigenvalue system should be able to handle scalar kernels
1.42.20Eigenvalue system should be able to handle DG kernels
1.42.21Eigenvalue system shall support Picard iteration using eigenvalue executioner as a master.
1.42.22Eigenvalue system shall support Picard iteration using eigenvalue executioner as a master and output eigen vectors as an exodus file.
1.42.23Eigenvalue system shall support Picard iteration using eigenvalue executioner as a sub app.
1.42.24Eigenvalue system shall support Picard iteration using eigenvalue executioner as a sub app and output eigen vectors as an exodus file.
1.42.25Eigenvalue system should be able scale eigenvector such that postprocessor is a certain value
1.42.26The system shall be able to automatically condition a nonlinear eigen-solve based on diagonal entries in the preconditioning matrix.
1.42.27The system shall be able to automatically scale a nonlinear eigen-solve based on entries in the non-eigen residual vector.
1.42.28The system shall provide an initial guess to Newton if users request.
1.42.29The system shall support eigenvalue execution without free power iterations.
1.42.30The system shall provide an option to output the eigenvalue as its inverse.
1.42.31The system shall provide an option to output the eigenvalue on screen as its inverse.
1.42.32The system shall support extra power iterations.
1.42.33The system shall support extra power iterations and check eigenvalue.
1.42.34Eigen solver should work with a physics-based preconditioner
1.42.35The system shall support a physics-based preconditioner with using JFNK
1.42.36Eigen solver should work with a physics-based preconditioner with a shell preconditioning matrix
1.42.37Eigen solver should work with a physics-based preconditioner with a PETSc shell matrix
1.42.38Eigen solver should work with a physics-based preconditioner with including eigen kernels in the preconditioning matrix
1.42.39MOOSE shall support an code coupling interface that can trigger external solves.
1.42.40MOOSE shall support an code coupling interface that can trigger external solves for transient simulations.
1.42.41The system shall support different coordinate systems on different subdomains within the mesh.
1.42.42The system shall support the ability to disable the check for PDE operators in all or some parts of the domain.
1.42.43The system shall support the ability to disable the check for active materials in all parts of the domain.
1.42.44The system shall support the ability to disable the check for the existence of all dependent properties within a domain.
1.42.45The system shall have the ability to disable the actual nonlinear system solve in a simulation.
1.42.46The system shall have the ability to base convergence on the comparison of individual variables to reference quantities of those variables.
1.42.47The system shall fail to find a converged solution when basing convergence on individual variable reference quantities with poor scaling.
1.42.48The system shall have the ability to automatically scale a originally poorly scaled problem and achieve convergence based on individual reference quantities

framework: Quadrature
1.43.1The system shall support the use of Gauss-Lobatto quadrature for numerical integration.
1.43.2The system shall support the ability to manually increase the quadrature order used for numerical integration on the entire mesh.
1.43.3The system shall support the ability to manually specify the quadrature order used for numerical integration on a per-block basis with face quadrature between blocks preferring the higher-order between the two sides.
1.43.4The system shall support the ability for objects to increase quadrature order in code during runtime.
1.43.5The system shall support the ability to control the volumetric and side quadrature orders used for numerical integration on the entire mesh.
1.43.6The system shall support the ability to allow object code to increase the quadrature order used for numerical integration on a per-block basis.

framework: Relationship Managers
1.44.1The CouplingFunctorCheckAction shall add a default coupling functor if it's needed and hasn't already been added by another Action
1.44.2The system shall be able to indicate when libMesh Ghosting Functors are in use.
1.44.3MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager
1.44.4MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh
1.44.5MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh with 3D
1.44.6The system shall be able to ghost elements for algebraic relationships.
1.44.7MOOSE shall ghost additional neighboring elements without also supplying solution information when a developer registers a RelationshipManager with an optional second argument to restrict functionality
1.44.8MOOSE 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
1.44.9
The system shall allow multiple active objectsto manage ghosting for the same object using
1. replicated and
2. distributed parallelism of the mesh.

framework: Reporters
1.45.1The system shall have a system for computing and retrieving aggregate values of arbitrary type.
1.45.2The system shall error if an invalid name is provided when retrieving aggregate value.
1.45.3
The system shall report a reasonable error when declaring a Reporter value and
1. the parameter that contains the name was not found,
2. the parameter that contains the name is not of the correct type,
3. a Reporter with the same name has already been declared, and
4. a Reporter with the same name but a different type has been requested.
1.45.4The system shall support the mixing of computing and retreiving aggregate values of arbitrary types with the Postprocessor and VectorPostprocessor system.
1.45.5The system shall be able to produce arbitrary integer, real number, and string scalar/vector values for use in other calculations.
1.45.6
The system shall throw an error when producing constant reporter values if
1. no values are specified,
2. no names are specified,
3. or the number of values and names are not equal.
1.45.7
The system shall output aggregate simulation information to JSON format
1. when the aggregate value is declared after object construction
2. and with other values declared at construction time.
1.45.8The system shall support getting a reference to an aggregate calculation before it is created.
1.45.9
The system shall include the ability to report iteration information:
1. that outputs all information be default;
2. that outputs specific information;
3. automatically disables items based on execution;
4. errors if requested item(s) are invalid for the execution method.
1.45.10
The system shall include the ability to report mesh information:
1. that outputs all information be default and
2. that outputs specific information.

framework: Restart
1.46.1The system shall support reading and writing solutions on meshes containing duplicate or overlapping mesh nodes.
1.46.2
The system shall support the ability to
1. perform residual calculations that accumulate state and
2. restart the calculation using the accumulated state.
1.46.3
The system shall support the ability to
1. to name problem objects in a simulation and
2. restart the calculation using the defined name.
1.46.4
The system shall error when
1. a simulation is started with multiple processors but
2. restarted with a different number processors.
1.46.5
The system shall error when
1. a simulation is started with multiple threads but
2. restarted with a different number threads.
1.46.6The system shall support running a transient test for the purposed of changing a restart time step size.
1.46.7The system shall support changing the time step size during a recover operation.
1.46.8The system shall produce an error when an attempt is made to serialize a type without a serialization (dataStore) routine when that data is declared as restartable.
1.46.9The system shall store a custom type that contains a data serialization routine that is declared as restartable.
1.46.10The system shall produce an error when an attempt is made to deserialize a type without a deserialization (dataLoad) routine when that data is declared as restartable during a restart or recover operation.
1.46.11The systen shall support running and saving off a transient solution with stateful material properties for a restart test.
1.46.12The systen shall support restart with a solution containing only a subset of the variables in the restart simulation.
1.46.13
The system shall support outputting a mesh from a simulation
1. with uniform refinement to ExodusII format,
2. start a new simulation that adds additional refinement,
3. which can be used in an third simulation.
1.46.14The system shall support outputting a mesh to checkpoint format for restart testing.
1.46.15The system shall support starting a transient simulation from a steady simulation result.
1.46.16The system shall support renaming a variable read from a solution file upon restart.
1.46.17The system shall support writing out several timesteps to a solution file to test reading from a specific point.
1.46.18The system shall support restarting from the last timestep using the keyword "LATEST".
1.46.19The system shall issue a useful error message stating the valid options when a user requests an invalid time step number or keyword.
1.46.20The system shall support running and saving off a transient solution for using in a steady state restart.
1.46.21The system shall support restarting a steady state solve from a transient simulation solution.
1.46.22The system shall support solving a transient problem as a reference solution for a two part multiapp solve.
1.46.23The system shall support writing out checkpoint directly from a subapp, a subtree of the multiapp tree of the master solve.
1.46.24The system shall support restarting a subapp, a subtree of the multiapp tree of a master solve without restarting the master application.
1.46.25
The system shall support executing a
1. a steady-state problem
2. and restarting a transient simulation from the previous solution.
1.46.26The system shall support generating checkpoint files for restart testing with sub apps.
1.46.27The system shall support restarting a transient simulation from a steady solution file with sub apps.
1.46.28The system shall support generating checkpoint files for restart testing with multiple sub apps.
1.46.29The system shall support restarting a transient simulation from a steady solution file with multiple sub apps.
1.46.30The system shall support generating checkpoint files for transient to transient restart testing with multiple sub apps.
1.46.31The system shall support restarting a transient simulation from a pseudo-transient solution file with multiple sub apps.
1.46.32
The system shall be capable, on a single process, of
1. writing data to a restart file
2. and restarting the simulation from the restart file.
1.46.33
The system shall be capable, in parallel, of
1. writing data to a restart file
2. and restarting the simulation from the restart file.
1.46.34
The system shall be able to restart a scalar variable in the presence of other variables with the standard sequence of:
1. run initial input
2. run restart input
1.46.35The system shall support outputting a mesh to checkpoint format for restart testing with "start_time".
1.46.36The system shall use the the final time as the "start_time" from the restart file.
1.46.37The system shall support resetting "start_time" when restarting from a checkpoint mesh format.
1.46.38The system shall support overriding "start_time" when restarting from a checkpoint mesh format to an arbitrary time.

framework: Restrictable
1.47.1The system shall include an interface to allow objects to be restricted to subdomains.
1.47.2The system shall error if an object is restricted to a set of subdomains that differs from a dependant object.
1.47.3
The system shall include an interface that provides a method for returning all associated subdomains:
1. as a list of names or
2. as a list of ids.
1.47.4
The system shall include an interface that provides methods for indicating if the supplied subdomain identifier(s) exists on the object:
1. if a single subdomain is supplied ant the object is not restricted;
2. if a single subdoman is supplied and the object is restricted to a set of subdomains; and
3. if multiple boundaries are supplied and the object is restricted to a set of subdomains.
1.47.5
The system shall include an interface that provides a method for indicating if the supplied material property exists on the same subdomains as the object:
1. the method shall return true if the property subdomains match with the object subdomains and
2. the method shall return false if the property subdomains dot not match with the object subdomains.
1.47.6
The system shall include an interface that provides a method for returning all associated boundaries:
1. as a list of names or
2. as a list of ids.
1.47.7
The system shall include an interface that provides methods for indicating if the supplied boundary identifier(s) exists on the object:
1. if a single boundary is supplied and the object is restricted to a set of boundaries and
2. if multiple boundaries are supplied.
1.47.8
The system shall include an interface that provides a method for indicating if the supplied material property exists on the same boundaries as the object:
1. the method shall return true if the property boundaries match with the object boundaries and
2. the method shall return false if the property boundaries dot not match with the object boundaries.
1.47.9
The system shall error if an object restricted to subdomains is created without valid data
1. regarding the problem being solved or
2. information regarding the finite element mesh.
1.47.10The system shall support the ability to restrict user defined calculations to sides of a subdomain.
1.47.11The system shall issue an error when a referenced subdomain does not exist in the mesh.

framework: Samplers
1.48.1
The system shall include a random number sampling system that operates in parallel
1. with threads,
2. MPI, and
3. that operates with a row-based iteration scheme.
1.48.2
The system shall include a random number sampling system that creates replicated and/or distribute sample data that is consistent:
1. on a single processor,
2. on a two processors,
3. on a three processors,
4. on a one processor with random numbers,
5. on two processor with random numbers, and
6. on thre processor with random numbers.
1.48.3
The system shall include a random number sampling system that errors
1. if the number of rows is altered during sample access,
2. if the number of columns is altered during sample access,
3. if the number of random number generator seeds is set after object construction,
4. if the number of rows is set to zero,
5. if the number of columns is set to zero,
6. if the number of random number generator seeds is set to zero,
7. if the number of entries in the global sample matrix exceeds the maximum allowed,
8. if the number of entries in the local sample matrix exceeds the maximum allowed, and
9. if the number of entries in the local sample matrix row exceeds the maximum allowed.
1.48.4
The system shall error when the expected size of a sampler is altered and accessed prior to initialization by accessing the
1. the global sample matrix;
2. the local sample matrix;
3. the local sample matrix row;
4. the total row count;
5. the local row count;
6. the first local row index;
7. the last local row index;
8. the column count.
1.48.5
The system shall include a random number sampling system
1. that distributes samples in parallel and
2. demonstrates efficient parallel scaling of memory use.

framework: Scalar Kernels
1.49.1We shall be able to couple a scalar variable into AD objects and do some meaningful physics: depleting boundary source diffusion problem
1.49.2We shall be able to couple a scalar variable into AD objects and get the correct Jacobian

framework: Scaling
1.50.1
The system shall be able to automatically scale variables and produce a good condition number from a naturally ill-conditioned system using
1. automatic and
2. manual prescribed settings.
1.50.2The system shall display a very poor condition number for an ill-conditioned system.
1.50.3
The system shall be able to conduct residual based automatic scaling such that the largest residual vector component corresponding to each variable has magnitude unity
1. in a one variable problem
2. and in a two variable problem.
1.50.4
The system shall be able to conduct jacobian based automatic scaling such that the largest jacobian diagonal component corresponding to each variable has magnitude unity
1. in a one variable problem
2. and in a two variable problem
1.50.5The system shall print current variable automatic scaling factors

framework: Tag
1.52.1
The system shall support the ability for a specific calculation to fill a labeled or "tagged"
1. numeric vector,
2. numeric matrix,
3. multiple numeric vectors simultaneously, or
4. multiple numeric matrices simultaneously.
1.52.2
The system shall support filling in labeled or "tagged" vectors or matrices from:
1. the scalar kernel system,
2. the discontinous Galerkin system,
3. integrated boundary conditions,
4. the interface kernels system,
5. the Dirac kernel system,
6. the nodal kernel system, and
7. the eigen system.
1.52.3Cached Active object state will be maintained correctly even when objects' active state changes during runtime.

framework: Time Integrators
1.53.1The system shall include an option that aborts the solve immediately if a solve fails.
1.53.2
The system shall support the use of explicit solvers, including
1. first-order, forward Euler,
2. with mass lumping, and
3. with mass lumping and preconditioning.
1.53.3
The system shall report an error if an explicit solver fails to converge with
1. first-order, forward Euler,
2. with mass lumping, and
3. with mass lumping and preconditioning.
1.53.4
The system shall correctly solve a time dependent Laplace equation using an explicit first-order, forward Euler scheme with:
1. for a 1D problem using linear Lagrange elements and Dirichlet boundary conditions;
2. for a 1D problem using second-order Lagrange elements and Dirichlet boundary conditions;
3. for a 1D problem using second-order Lagrange elements and Neumann boundary conditions;
4. for a 2D problem using linear Lagrange elements and Dirichlet boundary conditions;
5. for a 2D problem using linear Lagrange elements, Dirichlet boundary conditions, and mesh adaptivity;
6. for a 2D problem using second-order Lagrange elements and Dirichlet boundary conditions;
1.53.5The system shall correctly solve a time dependent ordinary differential equation using an explicit first-order, forward Euler scheme.
1.53.6The system shall support the use of the Adams Bashforth predictor for time integration.
1.53.7
The system shall support the second-order backward difference method for time integration
1. with and
2. without mesh adaptivity.
1.53.8The CentralDifference time integrator shall correctly compute the first and second time derivatives.
1.53.9
The system shall include explicit time integration using the Heun method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.10
The system shall include explicit time integration using the Ralston method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.11
The system shall include explicit time integration using the midpoint method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.12
The system shall include explicit time integration using the Euler method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.13
The system shall include implicit time integration using the Midpoint method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.14
The system shall include implicit time integration using the L-stable DIRK3 method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.15
The system shall include implicit time integration using the L-stable DIRK4 method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.16
The system shall include implicit time integration using the A-stable DIRK4 method and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.17
The system shall include implicit time integration using the A-stable DIRK4 method (bootstrapped with L-stable DIRK) and converge at the theoretical rate with
1. a full timestep,
2. a half timestep, and
3. a quarter timestep.
1.53.18
The system shall support the second-order Crank-Nicolson method for time integration
1. with and
2. without mesh adaptivity.
1.53.19
The system shall support the L-stable DIRK method for time integration
1. with and
2. without mesh adaptivity.
1.53.20
The system shall support the use of quasi-explicit Euler solver with
1. 1D elements with first order shape functions and Dirichlet boundary conditions;
2. 1D elements with second order shape functions and Dirichlet boundary conditions;
3. 1D elements with second order shape functions and Neumann boundary conditions;
4. 2D elements with first order shape functions and Dirichlet boundary conditions;
5. 2D elements with second order shape functions and Dirichlet boundary conditions; and
6. 2D elements with second order shape functions and Neumann boundary conditions.
1.53.21
The system shall include the strong-stability-preserving Runge-Kutta method of
1. 1st order
2. 2nd order
3. 3rd order
1.53.22
The system shall support the use of an implicit Euler solver with
1. with and
2. without mesh adaptivity.
1.53.23The system shall support the use of an implicit Euler solver with discontinuous (first-order Monomial) shape functions.
1.53.24Multi-stage time integrators shall check convergence for all stages
1.53.25The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using the default beta and gamma parameters.
1.53.26The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using user provided beta and gamma parameters.
1.53.27
The system shall support the use of an explicit midpoint time integration scheme for
1. 1D elements with linear finite element shape functions and
2. 2D elements with quadratic finite element shape functions.
1.53.28
The system shall compute the Jacobian during explicit midpoint time integration for
1. 1D elements with linear finite element shape functions and
2. 2D elements with quadratic finite element shape functions.
1.53.29
The system shall support th used of Crank-Nicolson time integration method for scalar variables with
1. scalar variables within and ordinary differential equations including
2. stiff and
3. nonlinear systems.
1.53.30
The system shall support the use of an total variation diminishing Runge-Kutta time integration schemefor
1. 1D elements with linear finite element shape functions and
2. 2D elements with quadratic finite element shape functions.
1.53.31
The system shall compute the Jacobian during total variation diminishing Runge-Kutta time integration for
1. 1D elements with linear finite element shape functions and
2. 2D elements with quadratic finite element shape functions.

framework: Time Steppers
1.54.1
The system shall calculate the time step size based one the number of steps and the end time of the simulation when the initial time step size is not supplied:
1. when the start time is not supplied, and
2. when the start time is supplied.
1.54.2The system shall include a means for performing simulations with a constant time step.
1.54.3The system shall support the ability to regrow a time step that has been previously cut due to a solve failure.
1.54.4The system shall support how time step size is cut, using user-specified cutback_factor_at_failure, due to a solve failure. Here, the original time step size is specified as a constant value.
1.54.5The system shall support how time step size is cut, using user-specified cutback_factor_at_failure, due to a solve failure. Here, the original time step size is specified as a function of time.
1.54.6The system shall suppport the ability to sample a piecewise linear function for time step sizes while supporting a minimum time step size.
1.54.7The system shall support the ability to sample a piecewise constant function for time step sizes choosing either the left or right values between adjacent constants.
1.54.8MOOSE shall support the ability to force time steps consistent with points specified in a function.
1.54.9MOOSE shall check that a timestep limiting function has been defined when a user specifies the 'force_step_every_function_point' parameter as true.
1.54.10MOOSE shall check that a timestep limiting function has been defined when a user specifies a value for the 'max_function_change' parameter.
1.54.11MOOSE shall support the ability to grow the time step size when specifying the initial value of dt in the TimeStepper.
1.54.12MOOSE shall support the ability to grow the time step size when specifying the initial value of dt in the TimeStepper after a restart.
1.54.13MOOSE shall support the ability to grow the time step size when specifying the values of t and dt in the TimeStepper.
1.54.14MOOSE shall support the ability to grow the time step size when specifying the values of t and dt in the TimeStepper after a restart.
1.54.15MOOSE shall support the ability to limit the time step size based on the optimal iterations and linear_iteration ratio.
1.54.16MOOSE shall support the ability to limit the time step size based on the optimal iterations and linear_iteration ratio after a restart.
1.54.17MOOSE shall support the ability to limit the time step size based on a postprocessor value.
1.54.18MOOSE shall support the ability to reject a time step based on a threshold value for the ratio of the ideal step size to the limit.
1.54.19MOOSE shall support the ability to force time steps to resolve sudden changes in piecewise linear functions.
1.54.20MOOSE shall support the ability to force time steps to hit all nodes in a set of piecewise linear functions.
1.54.21MOOSE shall support the ability to force time steps to resolve sudden changes in multiple piecewise linear functions.
1.54.22The system shall support the ability to select a time step size based upon a scaled log-constant calculation.
1.54.23The system shall support the ability to use a scalar value computed after a solve to be used as a scaled time step size.
1.54.24The system shall support the ability to select time step sizes based upon the ratio of the real (wall) time of the solve and the size of the time step.
1.54.25
The system shall support the ability to choose time step sizes based on a sequence of increasing numbers:
1. beginning at the default start time,
2. beginning at an earlier time than the sequence numbers,
3. beginning at a time somewhere in-between existing sequence numbers, and
4. when reading the sequence from an ExodusII formatted input file.
5. when reading the sequence from a comma-separated input file.
1.54.26The system shall support the ability to override time sequence time step sizes when solves fail.
1.54.27
The system shall support the ability to run a calculation for the purpose of creating a time sequence restart file:
1. when writing the checkpoint file,
2. when restarting where the time sequence is identical, and
3. when restarting where the time sequence is different after the point of the checkpoint.
1.54.28
The system shall support the ability to run a calculation for the purpose of creating a time sequence restart file suitable for failure:
1. when writing the checkpoint file,
2. when restarting where the time sequence is different prior to the failure.
1.54.29The system shall report an error if the initial time step size is calculated to be zero.

framework: Transfers
1.55.1The system shall support the transfer of data from a completed solve within sub-application to the master application.
1.55.2The system shall include an interface for retrieving objects that pertain to transferring data between applications.
1.55.3The system shall support conservative transfers
1.55.4The system shall check execute_on for PP in sub app
1.55.5The system shall support conservative transfers using regular postprocessors
1.55.6The system shall check execute_on for PP in master app
1.55.7The system shall support conservative transfers with nearestpoint VectorPostprocessors
1.55.8The system shall check execute_on for vector PP in master app
1.55.9The system shall be able to output the adjusting values in conservative transfers
1.55.10The system shall support conservative transfers in MultiAppUserObjectTransfer
1.55.11The system shall be able to output the adjusting values in conservative transfers for MultiAppUserObjectTransfer
1.55.12The systen shall allow adjustment if both from and to adjuster are negative.
1.55.13The systen shall allow to skip adjustments without throwing an error if from/to adjusters do not satisfy conditions.
1.55.14The system shall support direct copy of array variables from a sub-application to the main application.
1.55.15
The system shall support the transfer of auxiliary field variables between identical meshes:
1. from a sub-application and
2. to a sub-application.
1.55.16
The system shall error if a variable, during a direct copy of auxiliary field variables, does not exist
1. in the sub-application when transferring form it and
2. in the master application when transferring for it.
1.55.17The system shall support direct copy of a constant monomial auxiliary variable from a sub-application to a constant monomial nonlinear variable in the main application.
1.55.18The system shall support direct copy of a constant monomial auxiliary variable from a the main application to a constant monomial nonlinear variable in the sub-application.
1.55.19The system shall error when the MultiAppCopyTransfer object is used on non-identical meshes.
1.55.20The system shall error when the MultiAppCopyTransfer object is used on meshes with different variable types.
1.55.21The system shall support direct copy of a linear Lagrange nonlinear variable from a sub-application to the main application.
1.55.22The system shall support direct copy of a linear Lagrange nonlinear variable to a sub-application from the main application.
1.55.23The system shall support direct copy of multiple nonlinear variables from a sub-application to the main application.
1.55.24The system shall support direct copy of a second-order Lagrange nonlinear variable from a sub-application to the main application.
1.55.25The system shall support direct copy of a second-order Lagrange nonlinear variable to a sub-application from the main application.
1.55.26The system shall support the transfer of field variables with solution vectors indicated by tags.
1.55.27The system shall support direct copy of a third-order monomial auxiliary variable from a sub-application to a third-order monomial nonlinear variable in the main application.
1.55.28The system shall support direct copy of a third-order auxiliary variable from a the main application to a third-order monomial nonlinear variable in the sub-application.
1.55.29The system shall support mesh to mesh interpolation with the first order elemental variable
1.55.30The system shall support mesh to mesh interpolation with the first order elemental variable when a different mesh is used in sub
1.55.31The system shall support nearest node transfer with the first order elemental variable
1.55.32The system shall support interpolation transfer with the first order elemental variable
1.55.33The system shall support user object transfer with the first order elemental variable
1.55.34The system shall support conservative transfer with L2 nonlinear variable
1.55.35The system shall allow to interpolate variables from the master app to the sub apps
1.55.36The system shall allow to interpolate variables from the sub apps to the master app
1.55.37The system shall allow to interpolate block restricted variables from the sub apps to the master app
1.55.38
The system shall support the transfer of data using the finite element solution function:
1. to a sub-application,
2. from a sub-application,
3. from a deformed mesh to a sub-application,
4. from to a sub-application with a deformed mesh,
5. from a sub-application with deformed mesh, and
6. from a sub-application to a deformed mesh.
1.55.39
The system shall error if preforming a transfer of data using the finite element solution if:
1. the evaluation point does not exist and
2. if the execution settings do not match between the master and sub-applications.
1.55.40The system shall transfer both nodal and elemental fields to a SubApp from the Master App.
1.55.41The system shall transfer both nodal and elemental fields from SubApps to the Master App.
1.55.42The system shall transfer values from SubApps which set the displaced_source_mesh flag to true.
1.55.43The system shall support the 'fixed_meshes' flag which allows caching of nearest neighbors.
1.55.44The system shall transfer values to multiple SubApps from the Master App's boundary.
1.55.45The system shall transfer values from a SubApp boundary to the Master App.
1.55.46The system shall work when there are multiple SubApps present.
1.55.47The system shall work in parallel between meshes with different spatial dimensions.
1.55.48
The system shall support the transfer of scalars to a field variable between an application and sub-applications:
1. using a inverse distance algorithm,
2. if the destination variable is CONSTANT MONOMIAL,
3. using a radial basis algorithm,
4. with multi-level sub-applications,
5. with multiple sub-application files, and
6. with a single sub-application file.
1.55.49The system shall report an error if a data transfer is requested for a data variable that is not defined.
1.55.50The system shall report an error if a variable is specified that is not LINEAR LAGRANGE or CONSTANT MONOMIAL
1.55.51
The system shall support the transfer of data between a master and sub-applications for scalar unknowns and postprocessing data:
1. from the master application to the sub-applications and
2. to the master application from the sub-applications.
1.55.52
The system shall error during the transfer of scalar variable and postprocessor data if the number of sub-applications differs from the order of the scalar variable if
1. the order is too large and
2. the order is too small.
1.55.53
The system shall support the transfer of scalar post processing data:
1. from the master application to sub-applications and
2. to the master application from sub-applications.
1.55.54The system shall support the transfer of scalar post processing data from a single sub-application.
1.55.55
The system shall support the transfer of field data using L2 projection:
1. from the master application to sub-applications and
2. to the master application from sub-applications.
1.55.56The system shall support the transfer of field data using L2 projection for first order shaped monomial shape functions.
1.55.57The system shall support the transfer of field data using L2 projection and include optimization for non deforming meshes.
1.55.58The system shall include the ability to transfer scalar variables to an applications from sub-applications.
1.55.59The system shall error if the variable order does not match when transferring scalar variables to an application from sub-applications.
1.55.60The system shall include the ability to transfer scalar variables from an applications to sub-applications.
1.55.61The system shall error if the variable order does not match when transferring scalar variables from an application to sub-applications.
1.55.62The system shall be able to create virtually translated points during MultiApp transfers.
1.55.63
The system shall support an interface for transferring user-defined spatial data
1. to a master application from sub-applications,
2. from a master application to sub-applications,
3. from a master application to sub-applications that have a deformed mesh, and
4. between a 3D master application and 1D sub-applications.
1.55.64The system shall transfer user-defined spatial data into block and boundary restricted nodal variables.
1.55.65The system shall transfer user-defined spatial data into block and boundary restricted elemental variables.
1.55.66MultiAppUserObjectTransfer shall generate an error if a master node/element is not contained within any sub application domains.
1.55.67MultiAppUserObjectTransfer shall allow skipping the bounding box test.
1.55.68The system shall include the ability to transfer a field variable sampled at a point to populate a field variable on the sub-application with the supplied value.
1.55.69
The system shall include the ability to transfer a field variable sampled at a point to post processing variable on the sub-application
1. from a linear Lagrange source variable and
2. from a constant monomial source variable and
3. from a finite volume constant monomial source variable.
1.55.70The system shall support the ability to disable the use of parallel barriers when streaming text to the screen.
1.55.71The system shall support the ability transfer vectors of post processing data between the master application and sub-applications.
1.55.72
The system shall support the ability to transfer vectorpostprocessor data
1. from the main application to all sub-applications,
2. from the main application to a single sub-applications,
3. and from a sub-application to the main application.
1.55.73The system shall support the ability to transfer integer, real, vector, and string reporter data.
1.55.74
The system shall support the ability to transfer reporter data and error if an invalid sub-application number is supplied when transferring data
1. to a sub-application,
2. from a sub-application.
3. from multiple sub-applications.
1.55.75
The system shall support declaring reporter value clone on a main application and transferring sub-application data into it
1. in serial and
2. in parallel.
1.55.76
If processors do not contain a sub-application and reporter clone transfer is requested, the system shall
1. be able to transfer if reporter types are specified and
2. error if types are not specified.
1.55.77The system shall support support the ability to perform interpolation between time steps when transferring field data between a master application and sub-applications.
1.55.78The Transfer system shall support execution with the EXEC_FINAL flag.
1.55.79The system shall support the transfer of data between a master application and sub-applications after a sub-application as been reset.

framework: Userobjects
1.57.1The system shall be able to terminate the execution of a solve based on post-processing calculations performed within the simulation.
1.57.2The system shall be able to terminate abort the current step in a solve based on post-processing calculations performed within the simulation to cut the timestep.
1.57.3The terminator system shall be able to output a custom info, warning, or error message.
1.57.4The terminator system shall check the compatibility of the suplied parameters.
1.57.5The terminator system shall check that a message is supplied if required.
1.57.6The system shall support the use of data produced by a custom user object calculations within a kernel object.
1.57.7
The system shall evaluate the quality of all the mesh elements and report
1. a warning when the "warning" option is selected,
2. an error when the "error" option is selected, or
3. a message when the selected metric does not apply to the element type being examined.
1.57.8
The framework shall include the ability to change element subdomain during simulation
1. reversibly,
2. irreversibly,
3. with and without a specified boundary,
4. with solution
5. and stateful material properties properly initialized.
1.57.9The framework shall include the ability to change element subdomain for a steady state simulation
1.57.10The system shall support overriding the inter-system dependency resolution to allow for developers to decide when specific calculations should be forced into a specific order.
1.57.11The system shall support "snapping" or moving new nodes and sides created by mesh adaptivity to the surface of a geometric sphere to capture high fidelity features on curved geometries.
1.57.12Testing the implementation of the InterfaceQpValueUserObject. This test also shows the use of InterfaceValueUserObjectAux AuxKernel. InterfaceValueUserObjectAux use interface values computed and stored at each qp from the InterfaceQpValueUserObject and output them into an auxvaraible.Values on the interface are then computed via SideAverageValue PP.By design at the end of the first step we should observe: an average material property of 7, an average material property absolute jump fo 6, a singed material property jump (primary-secondary) of 6 a singed material propertyjump (secondary-primary) of -6 a material property value on the primary side of 10 a material property value on the primary side of 4
1.57.13The InterfaceUserObject system shall be able to get updated bulk, boundary and interface material property values.This test uses two specific test materials (e.g. LinearNonLinearIterationMaterial and LinearNonLinearIterationInterfaceMaterial) and one test userobject (e.g. InterfaceUserObjectTestGetMaterialProperty).This test will produce an error if the computed an retrived material property are not the same.
1.57.14Testing the implementation of the InterfaceQpValueUserObject when computing the variable rate or increment.
1.57.15Testing the implementation of the InterfaceQpMaterialPropertyRealUO.
1.57.16
The system shall support executing custom algorithms on all internal sides of the mesh where properties retrieved on that side come from:
1. the same subdomain, or
2. different subdomains.
1.57.17MOOSE shall allow taking averages of variables along a coordinate axis in layers
1.57.18The system shall be capable of computing layered averages of a variable given bounds.
1.57.19
The system shall shall error when computing layered averages of a variable if
1. the bounding box is set along with the number of layers or
2. sample interpolate and
3. if neither the bounds or number of layers are set.
1.57.20MOOSE shall allow interpolating between layers for layered averages
1.57.21MOOSE shall respect mesh displacements in layered average
1.57.22
The system shall be capable of computing layered averages of a variable
1. within a subdomain and
2. within a prescribed region in a subdomain.
1.57.23MOOSE shall respect block restriction for layered averages even when using num_layers
1.57.24MOOSE shall allow bounds for layered averages when using num_layers to come from a block different than the block restriction
1.57.25The system shall have the ability to maintain persistent generic user data stored in "layers" that may persist across invocations in the form of file data.
1.57.26
The system shall include the ability to computes volume integrals of a variable storing partial sums for the specified number of intervals in a direction (x,y,z)
1. using 3 layers with
2. as a cumulative calculation and
3. as an average calculation,
4. and using finite volume variables.
1.57.27MOOSE shall correctly compute layered integrals along a specified boundary.
1.57.28MOOSE shall correctly compute layered integrals of finite volume variables along a specified boundary.
1.57.29MOOSE shall allow taking averages of variables along a coordinate axis in layers on a boundary.
1.57.30MOOSE shall allow taking averages of the flux of variables along a coordinate axis in layers on a boundary.
1.57.31MOOSE shall allow taking averages of the diffusive flux of finite volume variables along a coordinate axis in layers on a boundary.
1.57.32MOOSE shall not allow both the block and boundary parameter to be specified for layered side integrals.
1.57.33The system shall support late binding of material properties to other objects so that those objects may be created first, or material property retrieval may be delayed until the system is initialized.
1.57.34The system shall compute layered averages that computed from the closest values for a list of points that are explicitly specified in an input file
1.57.35The system shall compute layered averages that computed from the closest values for a list of points that are specified in an external file
1.57.36The system shall report an error when points are not specified in an input file nor an external file when computing nearest point layered averages
1.57.37The system shall report an error when points are specified both in an input file and an external file when computing nearest point layered averages
1.57.38The system shall report an error when there is not enough coordinates specified in an external file specifing the point for computing nearest point layered averages
1.57.39The system shall compute layered averages for concentric cylindrical rings with equal thickness for a list of points that correspond to the average radius of each ring
1.57.40The system shall compute layered integrals that computed from the closest values for a list of points that are specified in an external file
1.57.41The system shall compute layered side averages that computed from the closest values for a list of points
1.57.42The system shall be able to keep track of a postprocessor value associated with a sub-app at a geometrical location
1.57.43
The system shall execute objects associated with mesh entities corresponding to the number of times those objects appear:
1. once for general user objects,
2. for each element,
3. for each side,
4. for each internal side, and
5. for each node.
1.57.44The system shall support optionally initializing shape function data structures for use in custom algorithm (UserObject) calculations.
1.57.45
The system shall compute the proper shape functions which can be used to verify Residual and Jacobian calculations
1. of a single variable,
2. of two coupled variables with explicit off-diagonals requested,
3. of two coupled variables with a full Jacobian matrix
4. on the side of elements, and
5. for a full physics test.
1.57.46The system shall error if the boundary is not specified when computing the average value of a variable on a boundary.
1.57.47The system shall be capable of writing out a solution file with both continuous and discontinuous fields for the purpose of verifying that ability to read those solutions back into a new simulation.
1.57.48The system shall be capable of reading in field information and producing gradient values from both continuous and discontinuous fields.
1.57.49
The system shall support creating n-thread copies of user-defined objects (GeneralUserObjects) for the purpose of running multiple related calculations simultaneously, avoiding thread locks during common look-up operations, where individual thread ids may be used to calculate a quantity based on the number of threads for:
1. one thread,
2. two threads,
3. three threads,
4. four threads,
5. five threads,
6. six threads,
7. seven threads, and
8. eight threads.
1.57.50
The system shall support the ability to toggle mesh adaptivity:
1. off when it has been turned on in the input file,
2. off when we are using initial adaptivity in the input file,
3. off after a specific time, or
4. off after some number of steps.

framework: Utils
1.58.1The system shall support a piecewise bilinear interpolation object to be constructed from x, y data read from an external file.
1.58.2The system shall support a piecewise bilinear interpolation object to be constructed from x, y data.
1.58.3The system shall error when a file and data are supplied simultaneously in the PiecewiseBilinear object.
1.58.4The system shall error when there is a mismatch in vector lengths in the PiecewiseBilinear object.
1.58.5The system shall error when there are insufficient parameters supplied for the PiecewiseBilinear object.
1.58.6The system shall provide a method for transferring common parameters from one object to another.
1.58.7The system shall prevent the user from copying InputParameters objects inside of MooseObject-derived objects.
1.58.8Moose shall have a function that evaluates the polynomial and derivative of polyonimal of varying degree and arbitrary coefficients
1.58.9Moose shall have a clamp function that returns a value limited to upper and lower bounds
1.58.10Moose shall have a smootherstep function that returns a smooth transition value between an upper and lower bound
1.58.11The system shall support the use of the Dennis-Schnabel method for computing the finite difference parameter for matrix free finite difference solver.
1.58.12The system shall automatically report input errors when a required parameter is not specified.
1.58.13The system shall include a utility for swapping values within a vector of data.
1.58.14The system shall include a utility for shuffling values within a vector of data.
1.58.15The system shall include a utility for resampling values within a vector of data.
1.58.16The system shall include a utility for computing spline functions.
1.58.17
The system shall include a utility for computing bicubic spline functions
1. using the x-component, and
2. using the y-component.
3. using the z-component,

framework: Variables
1.59.1MOOSE shall provide an ability to add array variables with constant initial conditions.
1.59.2The system shall support direct calculation of field variables on multiple mesh subdomains.
1.59.3
The system shall support the ability to couple a scalar auxiliary calculation for use in a field auxiliary calculation:
1. using current scalar values,
2. using previously calculated scalar values (old), and
3. using values calculated from two steps back (older).
1.59.4The system shall support the ability to use a default value when an optional scalar coupling is requested but not supplied.
1.59.5The system shall support the ability to use the initial value of a scalar auxiliary calculation when it is coupled into another object that executes at the beginning of the simulation.
1.59.6The system shall support "curvilinear" elements (elements that contain curved edges.
1.59.7
The system shall support the hierarchical family of shape functions on mesh
1. in 1D,
2. in 2D, and
3. in 3D.
1.59.8
The system shall produce the correct convergence rate for third-order Hermite shape function discretizations as mesh refinement is performed:
1. when using periodic boundary conditions, and
2. when using Dirichlet boundary conditions.
1.59.9
The system shall support the hierarchical family of shape functions on mesh including:
1. first-order on 1D elements,
2. second-order on 1D elements,
3. third-order on 1D elements,
4. first-order on 2D elements,
5. second-order on 2D elements,
6. third-order on 2D elements,
7. first-order on 3D elements,
8. second-order on 3D elements, and
9. third-order on 3D elements.
1.59.10
The system shall support the constant Monomial family of shape functions on mesh elements:
1. in one dimension,
2. in two dimensions, and
3. in three dimensions.
1.59.11
The system shall support the direct retrieval of "elemental solution" or "degree of freedom" values without the need to sample the finite element shape function:
1. for current solution values,
2. for previous solution values (old), and
3. for solution values calculated two steps back (older).
1.59.12The system shall support second and third order Monomial family of shape functions.
1.59.13The system shall support the ability to have mixed field variable orders on the same mesh.
1.59.14The system shall support the ability to have multiple independent block restricted variables in a mesh contain multiple blocks.
1.59.15Allow optional variable coupling where a default constant value is assumed when the user omits specifying a variable.
1.59.16Users are allowed to provide constant numeric values as input to an optionally coupled variable in addition to variable names that overrides the default constant value specified in code.
1.59.17Simulations with second derivative variable coupling shall not crash due to access to uninitialized data structures.
1.59.18
Coupleable shall provide an interface that allows providing default values for a variables that operates
1. with defaults or
2. a vector of coupled variables.
1.59.19The system shall report an error when users couple constant values and variables together
1.59.20
The system shall report an error when requested default vector value is out of range and
1. accessed by name or
2. accessed by index.
1.59.21The system shall support the ability to couple to a previous field variable calculation to produce another field such that there is no Jacobian contribution due to the lagged coupling.
1.59.22The system shall ensure that coupled second derivative calculations are only performed when requested and are only performed on the minimum required fields.
1.59.23The system shall compute time derivatives on a neighbor element for constant monomials

framework: Vectorpostprocessors
1.60.1Line sampling shall account for floating point precision error.
1.60.2The system shall be able to produce arbitrary vectors of values for use in other calculations.
1.60.3The system shall be able to produce multiple arbitrary vectors of values for use in other calculations.
1.60.4The system shall support the ability to read a comma separated file into an object and make it accessible through easy to use standard C++ containers.
1.60.5The system shall support the ability to read CSV data on only one processor and broadcast it to other ranks.
1.60.6The system shall error if the broadcast CSV data does not match on all ranks in a parallel job.
1.60.7The system shall support the ability to read a comma separated file into an object prior to initial setup.
1.60.8The system shall issue an error if the CSVReader is used in a UserObjectTransfer because the former does not have any notion of "spatial" information.
1.60.9MOOSE shall support the computation of averages of variables over cylindrical shells.
1.60.10
The system shall support writing a vector of data
1. that is completely stored on a single processor or
2. distributed across many and
3. allows for the creation of symbolic links to the the most recent and final files on each processor.
1.60.11The system shall support dynamic numbers of sample points during the simulation.
1.60.12The system shall support dynamic numbers of sample points during the simulation with move semantics of the points vector.
1.60.13The system shall have the ability to retrieve element integers when visiting elements.
1.60.14The system shall have the ability to retrieve element integers when visiting elements only on certain subdomains.
1.60.15The system shall have the ability to retrieve element integers of attached elements when visiting sides of a side set.
1.60.16The system shall have the ability to retrieve element integers of attached elements on both sides when visiting internal interfaces.
1.60.17The system shall have the ability to retrieve element integers of attached elements on both sides when visiting all internal sides.
1.60.18
The system shall support sampling of a field variable at the centroid of every element in the domain
1. for elemental variables and
2. nodal variables.
1.60.19
The system shall be capable of locating the maximum distances (the element) between two field variables:
1. the true maximum involving a simple difference, and
2. the absolute maximum involving the difference between absolute values.
1.60.20The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 1D mesh
1.60.21The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 2D mesh
1.60.22The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 3D mesh
1.60.23The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 1D mesh
1.60.24The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 2D mesh
1.60.25The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 3D mesh
1.60.26The system shall be able to compute a histogram of each vector of data produced by a vector data producer (VectorPostprocessor).
1.60.27
The system shall support finding all of the elements intersected by a line:
1. in 1D,
2. in 2D, and
3. in 3D.
1.60.28The system shall have late binding producers of vector quantities (VectorPostprocessors) that may be declared after system initialization.
1.60.29The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a first-order polynomial sampled from a solution field using LineValueSampler with shifting and scaling parameters specified
1.60.30The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a zeroth-rder polynomial with data provided by a CSVReader
1.60.31The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a first-rder polynomial with data provided by a CSVReader
1.60.32The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a second-rder polynomial with data provided by a CSVReader
1.60.33The LeastSquaresFit vectorpostprocessor shall generate an error if a fit for a third-order polynomial is requested and only three data points are provided
1.60.34The system shall support computing the least squares fit of a set of time values obtained from an aggregate operation defined by the developer.
1.60.35The system shall support sampling one or more spatial functions along a line with fixed sampling intervals.
1.60.36The system shall support the ability to sample a scalar material along an arbitrary line through the mesh domain.
1.60.37MOOSE shall allow to sample variables at equally spaced points for outputting.
1.60.38MOOSE shall allow to sample variables at equally spaced points in parallel.
1.60.39MOOSE shall allow to scale the line value sampler with a postprocessor.
1.60.40MOOSE shall allow to sample auxvariables at equally spaced points with CSV delimiter and precision setting.
1.60.41The system shall be able to output material properties calculated at quadrature points on user-defined elements in a comma separated format.
1.60.42
The system shall issue an error if material output samples are attempted for elements:
1. but the material is restricted to a boundary, or
2. the material is restricted to a block not containing the desired elements.
1.60.43The system shall support sampling of a field variable at every node in the domain.
1.60.44The system shall issue an error when a nodal sampler is used on a field that does not have values defined at the nodes.
1.60.45MOOSE shall provide VectorPostprocessor results to all processors as scattered data
1.60.46MOOSE shall provide VectorPostprocessor results to all processors as replicated data
1.60.47The system shall support the ability to sample field variables at user specified points.
1.60.48The system shall support the ability to sample field FV variables at user specified points.
1.60.49The system shall report an error when requested sample points do not fall within the mesh domain.
1.60.50The 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.
1.60.51The system shall be capable of sampling one or more field variables along a side at each quadrature point along the side.
1.60.52The system shall allow outputting relevant information about sidesets
1.60.53The system shall support computing the spherical average of a variable as a function of radius throughout the mesh domain.
1.60.54The system shall support the ability to output a separate comma separated value file containing time and time time information corresponding to vector Postprocessor output.
1.60.55The system shall be able to aggregate an arbitrary set of scalar data producers (Postprocessors) into a single vector of Postprocessors.
1.60.56The system shall allow support the creation of histogram or binned data of volume fractions with respect to variable values.
1.60.57
The system shall have the ability to compute several statistics related to the balance of the mesh partitioning
1. on replicated meshes, and
2. on distributed meshes.

Usability Requirements

framework: Usability
1.56.1
The system will be operated using a command-line interface that
1. reports the available options in non are provided and
2. accepts defined command-line flags.
1.56.2
The system will be operated using
1. an input file and
2. command-line options.
1.56.3The system shall return usage messages when unidentified arguments or incorrectly used arguments are passed.
1.56.4The system shall provide diagnostics when the input file fails to parse, or the format is incorrect.
1.56.5The system will provide on screen information about the simulation characteristics of the solves under normal operating conditions.

Performace Requirements

framework: Performance
1.37.1
The system shall support the use of multiple processors using
1. distributed memory,
2. shared memory, and
3. both distributed and shared memory.
1.37.2
The system shall support execution on
1. macOS and
2. Linux operating systems.

System Interfaces

framework: System Interfaces
1.51.1The system shall support the use of message passing interface (MPI).
1.51.2
The system shall support the use of shared memory threads using
1. 'pthreads' or
2. OpenMP.
1.51.3
The system shall support the use of the following parallel mesh partitioners:
1. Chaco,
2. ParMETIS,
3. Party, and
4. PTScotch.
1.51.4
The system shall support the use of the following solver packages:
1. SuperLU,
2. MUMPS, and
3. SLEPc.
1.51.5
The system shall support the use of the following C++ libraries:
1. Visualization ToolKit (VTK) and
2. BOOST.
1.51.6
The system shall interface operate with the following C++ compilers:
1. Clang and
2. GCC.

System Operations

Human System Integration Requirements

MOOSE is a command line driven application which conforms to all standard terminal behaviors. Specific human system interaction accommodations shall be a function of the end-user's terminal. MOOSE does support optional coloring within the terminal's ability to display color, which may be disabled.

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 Lesser 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. !template-end!

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:

Command Line Flag	Description of mode
`-i <input_file>`	Normal execution mode
`--split-mesh <splits>`	Read the mesh block splitting the mesh into two or more pieces for use in a subsequent run
`--use-split`	(inplies -i flag) Execute the the simulation but use pre-split mesh files instead of the mesh from the input file
`--yaml`	Output all object descriptions and available parameters in YAML format
`--json`	Output all object descriptions and available parameters in JSON format
`--syntax`	Output all registered syntax
`--registry`	Output all known objects and actions
`--registry-hit`	Output all known objects and actions in HIT format
`--mesh-only` (implies -i flag)	Run only the mesh related tasks and output the final mesh that would be used for the simulation
`--start-in-debugger <debugger>`	Start the simulation attached to the supplied debugger

note

The list of system-modes may not be extensive as the system is designed to be extendable to end-user applications. The complete list of command line options for applications can be obtained by running the executable with zero arguments. See the command line usage.

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. !template-end!

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 Nuclear Quality Assurance Level 1 (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.

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. !template-end!

Introduction
System Overview
References
Definitions and Acronyms
System Requirements
Verification