Framework System Requirements Specification

System Purpose

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

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

System Scope

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

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

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

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

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

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

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

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

Definitions

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

Acronyms

Functional Requirements

• framework: Actions
• F1.1.1The system shall error if the supplied order of scalar auxiliary variable is of an unknown order.
• F1.1.2The system shall support calculations with an auxiliary scalar variable represented with a 21st order monomial function.
• F1.1.3The system shall be capable of reporting Action object dependencies.
• F1.1.4The system shall be capable of reporting Action object task information.
• F1.1.5The system shall be able to retrieve other Action objects from within another Action object.
• F1.1.6The Action system shall allow Action objects to create other Action objects.
• F1.1.7The Action system shall allow the creation of Action objects with multiple tasks.
• F1.1.8The Postprocessor data shall be initialized by the SetupPostprocessorDataAction object and the PostprocessorInterface::hasPostprocessor shall return true when called with a defined postprocessor name.
• F1.1.9The system PostprocessorInterface::hasPostprocessor method shall return false when called with an undefined postprocessor name.

• framework: Adaptivity
• F1.2.1The Adaptivity system shall allow for multiple mesh adaptivity steps per timestep.
• F1.2.2The Adaptivity system shall support mesh adaptivity during initial setup.
• F1.2.3The Adaptivity system shall support marking elements for refinement during initial setup using a different marker than used during execution.
• F1.2.4The Adaptivity system shall support execution at every n timestep.
• F1.2.5The Adaptivity system shall be capable of restricting the element refinement level.
• F1.2.6The Adaptivity system shall allow for Marker objects to be recomputed with each adaptivity cycle.

• framework: Auxkernels
• F1.3.1MOOSE shall provide a way to convert a component of an array variable to a standard variable.
• F1.3.2MOOSE shall support auxiliary calculations for scalar variables at nodes.
• F1.3.3The AuxScalarKernel system shall automatically resolve dependencies between objects.
• F1.3.4The system shall include the ability to compute a field variable from a another that is upper and lower bounded.
• F1.3.5The ConstantScalarAux object shall set the value of an scalar auxiliary variable to a constant value.
• F1.3.6The system shall make current boundary id available in objects evaluated on boundaries.
• F1.3.7The DiffusionFluxAux object shall compute the components of the flux vector for diffusion problems.
• F1.3.8The variable data created by a MaterialRealAux object shall support being limited to boundaries.
• F1.3.9Kernel objects shall be capable of coupling to an auxiliary variable.
• F1.3.10AuxKernel object dependencies shall be resolved automatically.
• F1.3.11AuxKernel objects shall operate on higher-order monomial basis functions.
• F1.3.12AuxKernel objects shall operate on first-order L₂ basis functions.
• F1.3.13AuxKernel object dependencies shall be resolved between block and non-block restricted variables.
• F1.3.14MOOSE shall include an AuxKernel object for returning the element length.
• F1.3.15MOOSE shall be able to compute and visualize element quality metrics
• F1.3.16MOOSE shall support the computation of a single value per element within the auxiliary system.
• F1.3.17MOOSE shall include the ability to compute the L^p, L², and H¹ error norms for each element.
• F1.3.18MOOSE shall allow objects that depend on each other but have differing execution flags to run without error.
• F1.3.19MOOSE shall include the ability to access the normal of a coupled variable within an AuxKernel object.
• F1.3.20MOOSE shall include the ability to set the value of a scalar variable using a function.
• F1.3.21MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap.
• F1.3.22MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap for a block restricted variable.
• F1.3.23MOOSE shall allow viewing the elements that would be ghosted to specific processors
• F1.3.24MOOSE shall allow viewing the elements that would be ghosted to specific processors
• F1.3.25MOOSE shall utilize the minimum of ghosting necessary for the problem
• F1.3.26MOOSE shall include the ability to extract a component of a linear Largrange variable gradient as an auxiliary variable.
• F1.3.27MOOSE shall include the ability to extract a component of a first order monomial variable gradient as an auxiliary variable.
• F1.3.28MOOSE shall allow visualization of the MPI processes mapping to compute nodes
• F1.3.29MOOSE shall include the ability to compute the linear combination of variables as an auxiliary variable.
• F1.3.30MOOSE shall include the ability to use extra element integers.
• F1.3.31MOOSE shall include the ability to compute the shortest distance from a nodes across boundaries.
• F1.3.32MOOSE shall have the ability to restrict AuxKernel objects with coupled variables to a boundary.
• F1.3.33MOOSE shall include the ability to limit the execution of an AuxKernel object to initial setup.
• F1.3.34MOOSE shall include the ability to couple auxiliary variables.
• F1.3.35MOOSE shall be capable of resolving dependencies between AuxKernel objects regardless of input file order.
• F1.3.36The AuxKernel objects shall be capable of coupling to multiple variables.
• F1.3.37The MOOSE auxiliary system shall be capable of updating multiple auxiliary variables within a single AuxKernel object.
• F1.3.38The MOOSE auxiliary system shall be capable of coupling to nonlinear variables at the end of a timestep.
• F1.3.39MOOSE shall include the ability to normalize a variable based on a Postprocessor value.
• F1.3.40MOOSE shall include the ability to normalize and shift a variable based on a Postprocessor value.
• F1.3.41AuxKernel objects shall support the use of material properties from the previous two timesteps.
• F1.3.42MOOSE shall include an AuxKernel object capable of computing values from a functional expression.
• F1.3.43Execution of a UserObject shall occur after the execution of the AuxKernel objects if the former depends on the latter.
• F1.3.44MOOSE shall support the ability to compute the quotient of two variables.
• F1.3.45The 'auxkernels/solution_aux/build' test shall create an output file for testing the 'SolutionAux' object.
• F1.3.46The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution.
• F1.3.47The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution using a direct degree-of-freedom copy for identical meshes.
• F1.3.48The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file.
• F1.3.49The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file with a custom extension (e.g., *.e-s003).
• F1.3.50The SolutionAux object shall be capable of reading elemental data for the largest timestep.
• F1.3.51The SolutionAux object shall be capable of reading elemental data for a specific timestep.
• F1.3.52The SolutionAux object shall be capable of restricting reading to a single elemental variable.
• F1.3.53The 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.
• F1.3.54The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation.
• F1.3.55The 'auxkernels/solution_aux/exodus_interp_restart1' shall create a restart file for subsequent tests.
• F1.3.56The SolutionAux object shall be capable of restart.
• F1.3.57The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation using a direct degree-of-freedom copy for identical meshes.
• F1.3.58The SolutionAux object shall be capable of accessing specific variables from a SolutionUserObject.
• F1.3.59The SolutionAux object shall produce an error if the 'from_variable' parameter is not set and the supplied UserObject has multiple variables.
• F1.3.60The SolutionUserObject object shall be capable of scaling and translating the supplied data.
• F1.3.61The SolutionAux object shall error if data for the supplied variable is not found in the SolutionUserObject data.
• F1.3.62The 'auxkernels/solution_aux/aux_nonlinear_solution' test shall create an XDA and XDR output file for testing the 'SolutionAux' object with auxiliary variables.
• F1.3.63The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file.
• F1.3.64The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDR file.
• F1.3.65The 'auxkernels/solution_aux/aux_nonlinear_solution_adapt' test shall create an XDA output file for testing the 'SolutionAux' object with adaptivity.
• F1.3.66The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file with adaptivity.
• F1.3.67The SolutionAux object shall be capable to reading auxiliary variables when operating on multiple threads.
• F1.3.68The 'auxkernels/solution_scalar_aux/build' test shall create an output file for testing the 'SolutionScalarAux' object.
• F1.3.69The system shall read a scalar variable from an Exodus file and use its value.
• F1.3.70Kernel objects shall be able to couple to the time derivative of an auxiliary variable.
• F1.3.71AuxKernel objects shall be able to couple to the time derivative of a nonlinear variable.
• F1.3.72Error an AuxKernel object attemps to couple to the time derivative of an auxiliary variable.
• F1.3.73MOOSE shall include the ability to compute the integral of a variable over time.
• F1.3.74MOOSE shall include the ability to set the components of a vector auxiliary variable using a function defined within the input file.
• F1.3.75MOOSE shall include the ability to compute the Euclidean norm of three coupled variables.
• F1.3.76MOOSE shall be capable of populating an auxiliary variable from VectorPostprocessor data sized to the number of processors.
• F1.3.77AuxKernel objects shall be capable of coupling to VectorPostprocessor objects.

• framework: Bcs
• F1.4.1MOOSE shall support Neumann type boundary conditions for a 1D problem.
• F1.4.2MOOSE shall support Neumann type boundary conditions for a 1D problem using an imported mesh.
• F1.4.3The 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.
• F1.4.4MOOSE shall support setting AD Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.
• F1.4.5MOOSE shall support setting AD Dirichlet type boundary conditions directly to the solution vector prior to the solve.
• F1.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.
• F1.4.7MOOSE shall support setting AD Dirichlet type boundary conditions directly to the solution vector prior to the solve and have perfect Jacobians.
• F1.4.8We shall be able to produce the expected result using ADKernel, ADNodalBC, and ADIntegratedBC
• F1.4.9We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a first order variable
• F1.4.10We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a second order variable
• F1.4.11We shall be able to produce the expected result using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC
• F1.4.12We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a first order variable
• F1.4.13We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a second order variable
• F1.4.14The 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.
• F1.4.15The 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.
• F1.4.16MOOSE shall provide array vacuum boundary condition.
• F1.4.17MOOSE shall support setting Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.
• F1.4.18MOOSE shall support setting Dirichlet type boundary conditions directly to the solution vector prior to the solve.
• F1.4.19MOOSE shall support the creation of BoundaryCondition objects that support conditional activation.
• F1.4.20MOOSE shall support the creation of BoundaryCondition objects that couple to nonlinear variables.
• F1.4.21MOOSE shall support coupled Neumann type boundary conditions.
• F1.4.22MOOSE shall support Dirichlet type boundary conditions defined by a function.
• F1.4.23The system shall support applying a function of space-time as a Neumann boundary condition.
• F1.4.24MOOSE shall support matching variable values on a boundary.
• F1.4.25MOOSE shall support the ability to create convective flux boundary conditions.
• F1.4.26MOOSE shall support a vacuum boundary condition for neutron diffusion on the boundary.
• F1.4.27MOOSE shall support Neumann type boundary conditions where the specified value is defined as the value of a vector, , in the direction of the boundary outward facing normal, (i.e., ).
• F1.4.28MOOSE shall support the 'no boundary condition' type boundary condition (Griffiths, 1997).
• F1.4.29MOOSE shall be capable of computing the nodal normals for triangle elements.
• F1.4.30MOOSE shall be capable of computing the nodal normals for quadrilateral elements.
• F1.4.31MOOSE shall be capable of computing the nodal normals for first order hexahedron elements.
• F1.4.32MOOSE shall be capable of computing the nodal normals for second order hexahedron elements.
• F1.4.33MOOSE shall be capable of computing the first order nodal normals for second order hexahedron elements.
• F1.4.34MOOSE shall be capable of computing the nodal normals for quadrilateral elements on a square domain.
• F1.4.35MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method.
• F1.4.36MOOSE shall support the application of Dirichlet type boundary conditions, defined by a function, using the penalty method.
• F1.4.37MOOSE shall support periodic boundary conditions with transforms defined as functions.
• F1.4.38MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions.
• F1.4.39MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions using a non-generated mesh.
• F1.4.40The PeriodicDistanceAux object shall produce an error when a point is provided that is outside the mesh domain.
• F1.4.41MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x', 'y', and 'z' directions.
• F1.4.42MOOSE shall support periodic boundary conditions on orthogonal boundaries with transforms defined as functions.
• F1.4.43MOOSE shall support periodic boundary conditions on parallel boundaries with transforms defined as functions.
• F1.4.44MOOSE shall support periodic boundary conditions on subdomain restricted variables.
• F1.4.45MOOSE shall support periodic boundary conditions with mesh adaptivity.
• F1.4.46MOOSE shall support periodic boundary conditions with transforms prescribed as a translation.
• F1.4.47MOOSE shall support periodic boundary conditions with displacements.
• F1.4.48MOOSE shall support periodic boundary conditions on a trapezoid domain with transforms prescribed as functions.
• F1.4.49Calls to periodic distance and bounds methods on the mesh shall work when periodic boundary conditions are not used.
• F1.4.50MOOSE shall support periodic boundary conditions on a wedge domain with transforms prescribed as functions.
• F1.4.51MOOSE shall support periodic boundary conditions for a single variable on a wedge domain with transforms prescribed as functions.
• F1.4.52MOOSE shall support periodic boundary conditions for input meshes that have repeated element ids.
• F1.4.53The Periodic Boundary system shall not attempt to add periodic boundary conditions to scalar variables.
• F1.4.54MOOSE shall support the application of a Neumann boundary condition computed via Postprocessor object.
• F1.4.55MOOSE shall properly compute second derivatives within BoundaryCondition objects.
• F1.4.56MOOSE shall support creating sidesets from nodesets for hexahedron elements to use with Boundary Condition objects.
• F1.4.57MOOSE shall support creating sidesets from nodesets for tetrahedron elements to use with Boundary Condition objects.
• F1.4.58MOOSE shall include the ability to apply a Neumann boundary condition according to a sin function.
• F1.4.59MOOSE shall include the ability to apply a Dirichlet boundary condition according to a sin function.
• F1.4.60BoundaryCondition objects shall support retrieval of VectorPostprocessor data.

• framework: Constraints
• F1.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.
• F1.5.2MOOSE shall include the ability to constrain the values on a boundary to a value at a prescribed node.
• F1.5.3MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.
• F1.5.4MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a penalty formulation.
• F1.5.5MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.
• F1.5.6MOOSE shall support embedded constraints between a 1D and 3D subdomain, using a penalty formulation.
• F1.5.7MOOSE shall support embedded constraints between 2D subdomains, using a kinematic formulation.
• F1.5.8MOOSE shall support embedded constraints between 2D subdomains, using a penalty formulation.
• F1.5.9MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a kinematic formulation.
• F1.5.10MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a penalty formulation.
• F1.5.11MOOSE shall support embedded constraints between 3D subdomains, using a kinematic formulation.
• F1.5.12MOOSE shall support embedded constraints between 3D subdomains, using a penalty formulation.
• F1.5.13MOOSE shall support the ability to constrain nodal values.
• F1.5.14MOOSE shall support the ability to constrain nodal values using a displaced mesh.
• F1.5.15MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface.

• framework: Controls
• F1.6.1The Control system shall be capable of activating or deactivating MOOSE objects using a conditional function.
• F1.6.2The MOOSE control system shall allow parameters from differing objects, with differing names to be associated and changed together.
• F1.6.3The MOOSE control system shall allow parameters from objects to be assigned aliases for the purpose of changing the value.
• F1.6.4The Control system shall support explicitly defined dependencies.
• F1.6.5The Control system shall error if an attempt to alter a non-controllable parameter is performed.
• F1.6.6The Control system shall error if multiple controllable parameters exists, but only a single parameter is expected to be controlled.
• F1.6.7The Control system shall error if an unknown parameter is supplied for control.
• F1.6.8The Control system shall error if a thread id greater than the number of threads available is supplied when retrieving a Control object.
• F1.6.9The Control system shall error if an attempt is made to disable the Executioner.
• F1.6.10The Control system shall error if an invalid control name is supplied to the Control dependency resolution procedure.
• F1.6.11The Control system shall support the modification of a single parameter using the objects base class name, object name, and parameter name.
• F1.6.12The Control system shall support the modification of multiple parameters using the objects base class and the parameter name.
• F1.6.13The Control system shall include a means to output information regarding the controlled parameters.
• F1.6.14The 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.
• F1.6.15MOOSE shall include a command line flag for displaying controllable parameter information.
• F1.6.16The Control system shall include a means to output information regarding the objects with controllable parameters.
• F1.6.17The Control system shall allow a scalar parameter to be controlled with a function.
• F1.6.18The Control system shall allow multiple scalar parameters to be controlled with a function.
• F1.6.19The MOOSE control system shall be capable of restricting parameters to be controlled for specific execution flags.
• F1.6.20The Control system shall allow multiple parameters to be changed by the parameter name alone using input syntax format.
• F1.6.21The Control system shall allow multiple parameters to be changed given the object and parameter names using input syntax format.
• F1.6.22The Control system shall allow for a single parameter to be changes given the input syntax, object name, and parameter name.
• F1.6.23The Control system shall allow for multiple parameters to be changed given input syntax and a parameter name.
• F1.6.24The Control system shall allow multiple parameters to be changed by the parameter name alone using a tag.
• F1.6.25The Control system shall allow multiple parameters to be changed given a tag and parameter names, given a tag assigned across input blocks.
• F1.6.26The 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.
• F1.6.27The 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.
• F1.6.28The Control system shall be capable of activating or deactivating AuxKernel objects with time.
• F1.6.29The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given identical start end times.
• F1.6.30The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given differing start end times.
• F1.6.31The Control system shall be capable of activating or deactivating NodalBC objects with time.
• F1.6.32The Control system shall be capable of activating or deactivating IntegratedBC objects with time.
• F1.6.33The Control system shall be capable of activating and deactivating NodalBC objects with time within a single TimePeriod block.
• F1.6.34The Control system shall be capable of activating or deactivating Constraint objects with time.
• F1.6.35MOOSE shall support the disabling an object using an input parameter.
• F1.6.36MOOSE shall support the enabling an object using an input parameter.
• F1.6.37The Control system shall be capable of activating or deactivating Damper objects with time.
• F1.6.38The Control system shall be capable of activating or deactivating DGKernel objects with time.
• F1.6.39The Control system shall be capable of activating or deactivating DiracKernel objects with time.
• F1.6.40The TimePeriod object shall error when used with a steady state problem.
• F1.6.41The TimePeriod object shall error when the start and end time parameters are not the same length.
• F1.6.42The TimePeriod object shall error when start and end time parameters differ in length than the supplied object list.
• F1.6.43The TimePeriod object shall error when a list of objects to control is omitted.
• F1.6.44The TimePeriod object shall error when start time is greater than the end time.
• F1.6.45The Control system shall be capable of activating or deactivating Kernel objects with time.
• F1.6.46The Control system shall be capable of activating or deactivating MultiApp objects with time.
• F1.6.47The Control system shall be capable of activating or deactivating NodalKernel objects with time.
• F1.6.48The Control system shall be capable of activating or deactivating ScalarKernel objects with time.
• F1.6.49The Control system shall be capable of activating or deactivating Transfer objects with time.
• F1.6.50The Control system shall be capable of activating or deactivating UserObject objects with time.

• framework: Coord Type
• F1.7.1MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction.
• F1.7.2MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction.
• F1.7.3MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction with discontinous Galkerin and integrated boundary conditions.
• F1.7.4MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction with discontinous Galkerin and integrated boundary conditions.

• framework: Dampers
• F1.8.1MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on elements.
• F1.8.2MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on elements.
• F1.8.3MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on nodes.
• F1.8.4MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on nodes.
• F1.8.5MOOSE shall include the ability to reduce the change in nonlinear residual based on a constant value.
• F1.8.6The Damper system shall use the minimum of NodalDamper and ElementDamper, when the later computes the minimum.
• F1.8.7The Damper system shall use the minimum of NodalDamper and ElementDamper, when the former computes the minimum.
• F1.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.
• F1.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.
• F1.8.10The BoundingValueNodalDamper object shall report if the minimum value is greater than the maximum value.
• F1.8.11The BoundingValueElementDamper object shall report if the minimum value is greater than the maximum value.
• F1.8.12The Damper system shall error if the damping value is below a minimum.

• framework: Dgkernels
• F1.9.1MOOSE shall support solving 1D advection using the discontinous Galerkin method.
• F1.9.2MOOSE shall support solving 2D diffusion using the discontinuous Galerkin method.
• F1.9.3DGKernels shall coexist with stateful material properties
• F1.9.4We shall not do any mallocs in MatSetValues because of automatic scaling
• F1.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
• F1.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
• F1.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
• F1.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
• F1.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
• F1.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
• F1.9.11MOOSE shall support solving 3D diffusion using the discontinuous Galerkin method.
• F1.9.12We shall be able to use constant monomials with AD
• F1.9.13MOOSE should support AD in DG Kernels
• F1.9.14Adaptivity shall work with dg kernels as long as stateful properties are not used.
• F1.9.15The system shall error if the triad of dg kernels, adaptivity, and stateful properties are used together.
• F1.9.16MOOSE shall be able to solve the advection diffusion equation using the discontinuous Galerkin method.
• F1.9.17MOOSE shall compute the correct Jacobian for the advection diffusion equation using the discontinuous Galerkin method.
• F1.9.18The DGKernel system shall support restriction to subdomains, in 1D.
• F1.9.19The DGKernel system shall support restriction to subdomains, in 2D.
• F1.9.20The DGKernel system shall operate with displaced meshes.
• F1.9.21The DGCoupledDiffusion object shall compute the correct Jacobian.

• framework: Dirackernels
• F1.10.1The system shall support the coupling of scalar aux variables for the purpose of sharing data and reporting values.
• F1.10.2The system shall support a constant point source implemented as a Dirac function:
  1. in 1D,
  2. in 2D, and
  3. in 3D.
• F1.10.3The system shall allow for source locations to be set by a user-defined object.
• F1.10.4The system shall have the ability to set the value of point source from a function.
• F1.10.5The system shall allow point sources originating from the evaluation of material properties.
• F1.10.6DiracKernel 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.
• F1.10.7The DiracKernel system shall allow for duplicate source locations to be defined.
• F1.10.8The system shall support the computation of off diagonal Jacobian terms for residual terms defined with a Dirac delta function.
• F1.10.9The 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.
• F1.10.10The DiracKernel system shall report an error if a location does not correspond with the supplied element id.

• framework: Executioners
• F1.11.1The Executioner system shall support the ability to create custom objects with custom execution callbacks.
• F1.11.2The Executioner system shall support the creation of custom objects with arbitrary execution flags.
• F1.11.3MOOSE shall support solving an Eigen value problem using the inverse power method.
• F1.11.4MOOSE shall support solving an Eigen value problem using Newton's method.
• F1.11.5MOOSE shall support solving an Eigen value problem using Newton's method in parallel.
• F1.11.6MOOSE shall support the use of material properties during an Eigen problem solve.
• F1.11.7MOOSE shall be capable of solving a diffusion problem using an Eigen value solver.
• F1.11.8MOOSE shall be capable of solving a nonlinear diffusion problem using an Eigen value solver.
• F1.11.9MOOSE shall be capable of solving a coupled nonlinear diffusion problem using an Eigen value solver.
• F1.11.10The EigenKernel object shall be capable of using coupled variables.
• F1.11.11MOOSE shall support adaptive solves for steady-state execution.
• F1.11.12MOOSE shall be able to detect steady state conditions during execution.
• F1.11.13MOOSE shall be capable of solving a steady state diffusion problem.
• F1.11.14MOOSE shall be capable of solving a transient diffusion problem.
• F1.11.15MOOSE shall print automatic scaling factors if specified.
• F1.11.16MOOSE shall not print automatic scaling factors if not specified.
• F1.11.17MOOSE shall provide an ability to solve a problem iteratively with tagging.
• F1.11.18MOOSE shall provide an ability to solve a problem iteratively with tagging.
• F1.11.19MOOSE shall correctly compute Jacobians when boundary conditions are disabled.
• F1.11.20The Executioner system shall support the PETSc non-linear divergence tolerance.
• F1.11.21MOOSE shall compute the solution of rank-deficient linear equations if the right hand side is within the range of the linear operator.
• F1.11.22MOOSE 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.
• F1.11.23Executioner objects shall be capable of coupling to Postprocessor values.
• F1.11.24MOOSE shall correctly evaluate Jacobians with coupled problems and the LINEAR solve type
• F1.11.25MOOSE shall not change the system time during steady-state execution.
• F1.11.26MOOSE shall be able to set the system time for steady-state execution.
• F1.11.27MOOSE shall support controlling what objects are executing based on start and end times.
• F1.11.28MOOSE shall support explicit definition of execution times.
• F1.11.29MOOSE shall support output using a time interval.

• framework: Fixedbugs
• F1.12.1The Material objects provided on all subdomains shall satisfy requests for objects on all subdomains.

• framework: Functions
• F1.13.1Generate the fine tabulated function data for the coarsened_piecewise_linear test
• F1.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.
• F1.13.3The Function system shall include a constant function.
• F1.13.4The Function system shall include the ability to set default values for input parameters expecting a function name.
• F1.13.5The Function system shall include the ability to read comma or space separated data and perform linear interpolation using the supplied data.
• F1.13.6MOOSE shall include an InitialCondition object capable of setting values base on a supplied function.
• F1.13.7The Function object shall include a callback executed during each timestep.
• F1.13.8The Material system shall support defining properties within the input file that are associated with functions.
• F1.13.9The system shall allow for piecewise functions to directly set the x and y data internally.
• F1.13.10The 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.
• F1.13.11MOOSE shall include the ability to define a function based on a 2D image and initialize a nodal variable.
• F1.13.12MOOSE shall include the ability to define a function based on a 2D image and initialize a elemental variable.
• F1.13.13MOOSE shall include the ability to define a function based on a stack of images and initialize a nodal variable.
• F1.13.14MOOSE shall include the ability to define a function based on a subset stack of images and initialize a nodal variable.
• F1.13.15The ImageFunction object shall allow the image data to be set as one of two values based on a threshold value.
• F1.13.16MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data.
• F1.13.17MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data, in parallel.
• F1.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.
• F1.13.19The ImageFunction object shall be capable of limiting the supplied data to a single component of the RGB image data.
• F1.13.20The ImageFunction object shall be capable of shifting and scaling the supplied data.
• F1.13.21The ImageFunction object shall be capable of operating on domains that are larger than the image size.
• F1.13.22The ImageFunction object shall be capable of flipping the data along the vertical axis.
• F1.13.23The ImageFunction object shall be capable of flipping the data along vertical axis and shifting the origin.
• F1.13.24The ImageFunction object shall be capable of flipping the data along vertical and horizontal axis.
• F1.13.25The ImageFunction object shall be capable of operating on domains that are smaller than the image size.
• F1.13.26The ImageMesh object shall be capable of generating a 3D mesh based on a stack of 2D images.
• F1.13.27The ImageMesh object shall be capable of generating a 2D mesh based on an image.
• F1.13.28The ImageFunction shift and scale options shall operate independently.
• F1.13.29The LinearCombinationFunction shall report an error if the parameters listing the functions differs in size than the list of coefficients.
• F1.13.30The LinearCombinationFunction shall be capable of computing the sum of function values, each multiplied by a scale factor.
• F1.13.31The LinearCombinationFunction shall be capable of computing the sum of function gradients, each multiplied by a scale factor.
• F1.13.32The LinearCombinationFunction shall be capable of computing the sum of vector functions, each multiplied by a scale factor.
• F1.13.33The Function system shall support the creation of objects that execute a function defined within the input file.
• F1.13.34The ParsedFunction object shall be capable of defining function within the input file for use with the method of manufactured solutions.
• F1.13.35The Function system shall support the creation of objects that execute a vector function defined within the input file.
• F1.13.36The Function system shall support the creation of objects that execute a function defined within the input file that includes a scalar variable.
• F1.13.37The ParsedFunction object shall support the use of other functions specified by their names in its expression.
• F1.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.
• F1.13.39The Function system shall support the creation of objects that execute a curl of a vector function defined within the input file.
• F1.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.
• F1.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).
• F1.13.42The PiecewiseMultilinear object will error if the supplied file fails to open.
• F1.13.43The PiecewiseMultiInterpolation object shall error if the supplied data is not monotonically increasing.
• F1.13.44The PiecewiseMultiInterpolation object shall error if the number of requested functions differ than the number available from the file.
• F1.13.45The PiecewiseMultiInterpolation errors if the axes supplied are not independent.
• F1.13.46The PiecewiseMultilinear shall error if the axis lines are not located in the supplied data.
• F1.13.47The PiecewiseMultilinear object shall perform interpolation on a 1D domain.
• F1.13.48The PiecewiseMultilinear object shall perform interpolation on a 1D domain that compares to an equivalent known function.
• F1.13.49The PiecewiseMultilinear object shall perform interpolation of time-dependent data.
• F1.13.50The PiecewiseMultilinear object shall perform interpolation on a 2D domain.
• F1.13.51The PiecewiseMultilinear object shall perform interpolation on a 2D domain that compares to an equivalent known function.
• F1.13.52The PiecewiseMultilinear object shall perform constant interpolation on a 2D domain.
• F1.13.53The PiecewiseMultilinear object shall perform interpolation on a 3D domain with time-dependent data.
• F1.13.54The Function object shall support the ability to couple Postprocessor values.
• F1.13.55The SolutionFunction object shall be capable of evaluating a solution read from XDA mesh and solution files.
• F1.13.56The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file with temporal interpolation.
• F1.13.57The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file.
• F1.13.58The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the z-axis.
• F1.13.59The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the y-axis.
• F1.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.
• F1.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.
• F1.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.
• F1.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.
• F1.13.64The SolutionFunction object shall error if a variable that does not exist is requested.
• F1.13.65The 'functions/solution_function/solution_function_grad_p1' test shall create an output for the 'solution_function_grad_p2' test.
• F1.13.66The SolutionFunction object shall be capable of evaluating the gradient of a solution read from an Exodus file.
• F1.13.67The VectorPostprocessorFunction shall be capable of linear interpolating data generated by a VectorPostprocessor object.

• framework: Geomsearch
• F1.14.1MOOSE shall be capable of computing the distance between two disjoint boundaries on a 1D domain.
• F1.14.2MOOSE shall be capable of computing the distance as well as transfer data between interior boundaries on a 2D domain.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.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.
• F1.14.27The 'geomsearch/2d_moving_penetration/restart' shall create the necessary files for testing restart of the PenetrationAux object.
• F1.14.28The PenetrationAux object shall be capable of restarting from a previous simulation.
• F1.14.29The 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.
• F1.14.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 in 2D with triangular elements.
• F1.14.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.
• F1.14.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 second order elements.
• F1.14.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.
• F1.14.34The 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.
• F1.14.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.
• F1.14.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 with second order elements.
• F1.14.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.
• F1.14.38The 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.
• F1.14.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.
• F1.14.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 and second order elements.
• F1.14.41The 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.
• F1.14.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.
• F1.14.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 second order elements.
• F1.14.44The 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.
• F1.14.45The 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.
• F1.14.46The 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.
• F1.14.47The 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.
• F1.14.48The 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.
• F1.14.49The NearestNodeDistanceAux object shall be capable of computing the shortest distance between a boundary and subdomain.
• F1.14.50The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries.
• F1.14.51The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries with adaptivity.
• F1.14.52MOOSE shall support a means for updating the geometric search patch dynamically that may be disabled.
• F1.14.53MOOSE shall support a means for updating the geometric search patch dynamically that automatically determines when an update to the patch shall occur.
• F1.14.54MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each solve.
• F1.14.55MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each iteration.
• F1.14.56The MOOSE penetration locator system shall error if penetration is not detected.
• F1.14.57The system shall be able to perform patch updates on every non-linear iteration while performing uniform coarsening and refinement from grid sequencing
• F1.14.58The PenetrationAux object shall compute the distance between two boundaries in 3D that overlap.
• F1.14.59The PenetrationAux object shall compute, in parallel, the distance between two boundaries in 3D that overlap.
• F1.14.60The nonlinear system shall be able to augment its sparsity based on constraints when we have a quadrature nearest-node locator.
• F1.14.61The NearestNodeDistanceAux object shall compute the shortest distance between nodes on two overlapping boundaries using a constant monomial auxiliary variable.
• F1.14.62Volumetric AD assembly data shall be properly sized when reinitializing faces
• F1.14.63The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable.
• F1.14.64The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable in 1D.

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

• framework: Ics
• F1.16.1The system shall allow to set initial conditions for an array variable based on functions.
• F1.16.2The system shall support setting initial conditions on boundaries.
• F1.16.3Generates a rectangular IC
• F1.16.4BoundingBoxIC shall have a diffuse interface option.
• F1.16.5The system shall report an error when multiple initial conditions are applied to the same boundary.
• F1.16.6The system shall report an error when multiple initial conditions are applied to the same subdomain.
• F1.16.7The system shall report an error when a global initial conditions overlap on the same variable.
• F1.16.8The system shall report an error when a global and subdomain restricted initial conditions overlap on the same variable.
• F1.16.9The system shall support setting different values for each coefficient of higher-order scalar values.
• F1.16.10The system shall support setting initial conditions of field variables to a constant value.
• F1.16.11The system shall support setting initial conditions of subdomain restricted field variables to a constant value.
• F1.16.12The system shall provide current node or element pointers when possible when evaluating initial conditions at a point in the domain.
• F1.16.13The system shall allow setting field initial condition from an user object
• F1.16.14The system shall allow setting scalar initial condition from an user object
• F1.16.15The system shall allow nodal initial condition objects to couple to other nodal variables for computing values for the current variable.
• F1.16.16The system shall allow elemental initial condition objects to couple to other elemental variables for computing values for the current variable.
• F1.16.17The system shall write output files containing nodal solutions in ExodusII format suitable for restart.
• F1.16.18The system shall be able to populate nodal initial conditions from a previous solution file in ExodusII format.
• F1.16.19The system shall write output files containing elemental solutions in ExodusII format suitable for restart.
• F1.16.20The system shall be able to populate elemental initial conditions from a previous solution file in ExodusII format.
• F1.16.21The system shall support setting gradient values for shape functions that support them.
• F1.16.22The system shall support using a spline function to set both value and gradient values in an initial condition.
• F1.16.23The system shall support setting a scalar initial condition by evaluating a function.
• F1.16.24The system shall support setting initial conditions for the Hermite set of shape functions.
• F1.16.25The system shall support initial conditions on second order Lagrange variables in 3D space.
• F1.16.26MOOSE shall generate parallel agnostic random initial conditions
• F1.16.27MOOSE shall generate threaded agnostic random initial conditions
• F1.16.28The system shall allow to set constant vector-valued initial conditions.
• F1.16.29The system shall allow vector-valued initial conditions be set using a vector function.
• F1.16.30The system shall allow vector-valued initial conditions be set using a function by components.
• F1.16.31The system shall error if the 'function' and 'function_x' parameters are both set within the VectorFunctionIC object.
• F1.16.32The system shall error if the 'function' and 'function_y' parameters are both set within the VectorFunctionIC object.
• F1.16.33The system shall error if the 'function' and 'function_z' parameters are both set within the VectorFunctionIC object.
• F1.16.34The system should supply a special convenience "zero" variable that can be indexed like a normal coupled variable.

• framework: Indicators
• F1.17.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.
• F1.17.2The 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.
• F1.17.3The 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.
• F1.17.4The 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:

• framework: Interfacekernels
• F1.18.1Interface kernels shall provide integrated conditions between subdomains, and shall work with boundary restricted materials with stateful properties.
• F1.18.2The interface diffusion penalty method should reproduce the analytic solution
• F1.18.3The InterfaceKernel system shall use with interface material in 1D.
• F1.18.4The system shall support the evaluation of neighboring quantities on elements containing different shape functions.
• F1.18.5The system shall produce correct Jacobians for coupled flux on an interface.
• F1.18.6The system shall support produce correct Jacobians when evaluating neighboring quantities on elements containing different shape functions.
• F1.18.7The system shall produce correct Jacobians for single variable coupled flux on an interface.
• F1.18.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.
• F1.18.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.
• F1.18.10The interface reaction kernel should reproduce the analytic solution
• F1.18.11The interface reaction kernel should work with interface diffusion kernel
• F1.18.12The solution should be discontinued at the interface due to the reaction taking place
• F1.18.13The Jacobian from InterfaceReaction shall be perfect
• F1.18.14The InterfaceKernel system shall operate with coupled variables in 2D. This uses a penalty implementation that is optimally convergent.
• F1.18.15Allow the interface to impose the same time derivative on two neighboring variables. This uses a penalty implementation that is optimally convergent.
• F1.18.16The InterfaceKernel system shall use with interface material in 2D.
• F1.18.17The Jacobian evaluation for InterfaceKernel objects in 2D shall be analytically correct.
• F1.18.18The finite difference preconditioner shall work in parallel.
• F1.18.19The InterfaceKernel system shall support Vector Finite Elements in 2D.
• F1.18.20We shall not do any mallocs in MatSetValues because of automatic scaling
• F1.18.21The InterfaceKernel system shall operate with coupled variables in 3D. This uses a penalty implementation that is optimally convergent.
• F1.18.22The InterfaceKernel system shall support Vector Finite Elements in 3D.
• F1.18.23The InterfaceKernel system shall use with interface material in 3D.
• F1.18.24Adaptivity shall work with interface kernels as long as stateful properties are not used.
• F1.18.25The system shall error if the triad of interface kernels, adaptivity, and stateful properties are used together.

• framework: Interfaces
• F1.19.1The system shall build a bijective map between variable numbers and their couple variable indices.
• F1.19.2The system shall produce parallel-agnostic random number fields on a single processor.
• F1.19.3The system shall produce parallel-agnostic random number fields on two or more processors.
• F1.19.4The system shall produce parallel-agnostic random number fields on two or more threads.
• F1.19.5The system shall produce a parallel field without repeating patterns on distributed meshes.
• F1.19.6The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system.
• F1.19.7The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system on two or more processors.
• F1.19.8The system shall produce parallel-agnostic random number fields via the user defined (UserObject) system on two or more threads.
• F1.19.9The system shall produce a parallel field without repeating patterns via the user defined (UserObject) system.
• F1.19.10The system shall produce a parallel-agnostic random number via the material system.
• F1.19.11The system shall produce a parallel-agnostic random number via the material system on two or more processors.

• framework: Kernels
• F1.20.1MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions.
• F1.20.2MOOSE shall provide an ability to solve a 2D diffusion problem with Neumann boundary conditions.
• F1.20.3MOOSE shall provide a diffusion kernel that obtains the diffusion coefficient from a material property
• F1.20.4MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term.
• F1.20.5MOOSE shall provide a tester that checks hand-coded Jacobian against finite difference Jacobian using -snes_type=test option.
• F1.20.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.
• F1.20.7MOOSE should not compute an extra residual if the linear solver is used
• F1.20.8MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions using AD and match non-AD methods.
• F1.20.9MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term using AD and compute a perfect jacobian.
• F1.20.10MOOSE shall provide an ability to solve a 2D diffusion problem using AD with Neumann boundary conditions.
• F1.20.11MOOSE shall provide an ability to solve a 2D diffusion problem using AD with Neumann boundary conditions and compute a perfect jacobian.
• F1.20.12MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term using AD and match non-AD methods.
• F1.20.13MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term using AD and compute a perfect jacobian.
• F1.20.14Coupled variable gradient Jacobian entries generated with AD shall be accurate
• F1.20.15Coupled variable value Jacobian entries generated with AD shall be accurate
• F1.20.16We shall be able to get aux variable values through adCoupledValue with the knowledge that the derivatives will always be zero
• F1.20.17Getting a constant aux variable through adCoupledValue shall not destroy our Jacobian
• F1.20.18We shall be able to get dot aux variable values through adCoupledValue with the knowledge that the time derivatives will always be zero
• F1.20.19The system will output the required number of derivative entries needed for automatic differentiation calculations
• F1.20.20Jacobians calculated by ADTimeDerivative and ADBodyForce shall be perfect.
• F1.20.21Diffusion with a material property diffusivity shall match the answer from an analytical solution
• F1.20.22Diffusion with a material property diffusivity from an AD kernel shall get the same answer as a traditional kernel
• F1.20.23AD Diffusion with a material property diffusivity and the Jacobian shall be beautiful
• F1.20.24Diffusion with a material property diffusivity shall match the answer from an analytical solution
• F1.20.25Diffusion with a material property diffusivity from an AD kernel shall get the same answer as a traditional kernel
• F1.20.26AD Diffusion with a material property diffusivity shall have a perfect Jacobian
• F1.20.27The system will error and tell the user if they use derivative storage that is too small
• F1.20.28Jacobian entries generated with AD for a simple diffusion problem shall be accurate
• F1.20.29We shall be able to reproduce the simple_transient_diffusion results with ADTimeDerivative
• F1.20.30The Jacobian from ADTimeDerivative shall be perfect
• F1.20.31We shall be able to reproduce the simple_transient_diffusion results with ADTimeDerivative
• F1.20.32The Jacobian from ADVectorTimeDerivative shall be perfect
• F1.20.33Jacobian entries generated with AD shall match hand-coded Jacobian entries as measured through save-in values
• F1.20.34The system shall support coupling of variables with automatic differentiation and vector values.
• F1.20.35The system shall support coupling to the gradient of variables with automatic differentiation and vector values.
• F1.20.36The system shall support coupling of default values for variables with automatic differentiation and vector values.
• F1.20.37The 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.
• F1.20.38The system shall support direct tensor-vector products and vector dot products to maintain dimension agnostic formulations where possible.
• F1.20.39MOOSE shall provide array diffusion kernels on an array variable.
• F1.20.40MOOSE shall provide array reaction kernels on an array variable.
• F1.20.41MOOSE shall provide array DG diffusion kernels on an elemental array variable.
• F1.20.42MOOSE shall provide coupling of standard variables in array kernels.
• F1.20.43MOOSE shall provide coupling of array variables in standard kernels.
• F1.20.44MOOSE shall provide residual save-in and Jacobian diagonal save-in on an array variable.
• F1.20.45MOOSE shall provide residual save-in and Jacobian diagonal save-in on an array variable.
• F1.20.46MOOSE shall provide array time derivative kernels on an array variable.
• F1.20.47We shall be able to show that without automatic scaling, this system is singular
• F1.20.48We shall be able to show that with automatic scaling, this system is non-singular
• F1.20.49We shall be able to show that with automatic scaling we can run this problem successfully in parallel
• F1.20.50The 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.
• F1.20.51The system shall support scaling the computed time derivative by a scalar coefficient.
• F1.20.52The 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.
• F1.20.53A coupled time derivative kernel shall be provided
• F1.20.54A coupled time derivative kernel with forward mode automatic differentiation shall be provided
• F1.20.55A coupled time derivative kernel compatible with vector variables with hand-coded jacobians shall be provided
• F1.20.56The Jacobian from VectorCoupledTimeDerivative shall be perfect
• F1.20.57The SMP Jacobian for a problem with a hanging-node shall be non-singular
• F1.20.58The colored finite difference Jacobian for a problem with a hanging-node shall be non-singular
• F1.20.59The standard finite difference Jacobian for a problem with a hanging-node shall be non-singular
• F1.20.60A matrix-free operator shall be able to solve the hanging-node problem, indicating it is non-singular
• F1.20.61The SMP Jacobian shall be perfect for the hanging-node problem
• F1.20.62The system shall support applying a function of space-time as a forcing function to the mesh domain.
• F1.20.63The system shall report an error when a parsed function expression contains quote characters.
• F1.20.64We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements
• F1.20.65We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements
• F1.20.66We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a cylindrical geometry
• F1.20.67We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a cylindrical geometry
• F1.20.68We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a spherical geometry
• F1.20.69We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a spherical geometry
• F1.20.70MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out.
• F1.20.71MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out in the automatic differentiation system.
• F1.20.72The Jacobian for the automatic differentiation problem shall be perfect
• F1.20.73The system shall support the ability to use mass lumping for time derivative terms.
• F1.20.74The system shall verify that the Jacobian terms when using mass lumping for time derivative terms are computed correctly.
• F1.20.75The system shall have the ability to verify individual Jacobian contributions before they are scaled by other finite element factors in the system.
• F1.20.76The system shall support solving Ordinary Differential Equations in explicit form.
• F1.20.77The system shall support solving Ordinary Differential Equations in implicit form.
• F1.20.78The system shall support solving ODEs specified within the input file through parsed function syntax.
• F1.20.79The system support coupling of postprocessor values in the parsed function ODE kernel.
• F1.20.80The system shall support solving Coupled Ordinary Differential Equations.
• F1.20.81The system shall allow scalar variable initial condition to be loaded from a file mesh
• F1.20.82The system shall allow auxscalar variable initial condition to be loaded from a file mesh
• F1.20.83MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach.
• F1.20.84MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach when displacements are active.
• F1.20.85MOOSE shall support the ability to set Dirichlet boundary conditions using the Lagrange multiplier approach.
• F1.20.86The system shall support retrieving a vector of values in a kernel object for the purpose of computing a residual statement.
• F1.20.87The system shall run a simple 2D linear diffusion problem with Dirichlet boundary conditions on a regular mesh.
• F1.20.88MOOSE shall be able to run a transient diffusion problem
• F1.20.89MOOSE shall not do any mallocs in MatSetValues for simple kernels
• F1.20.90We shall not be able to solve a problem where the physics Jacobians are very large compared to the jacobian from a Dirichlet BC (unity)
• F1.20.91We shall be able to solve an initially poorly scaled problem by using MOOSE's automatic scaling feature
• F1.20.92We shall be able to solve an initially poorly scaled problem by using MOOSE's automatic scaling feature in parallel
• F1.20.93We shall not be able to solve a problem where the physics has large changes over time if we only scale once
• F1.20.94We shall be able to solve a problem where the physics has large changes over time if we scale on every time step
• F1.20.95We shall be able to solve a problem where the physics has large changes over time if we scale on every time step in parallel
• F1.20.96The system shall error if the volumetric residual calculation is not assigned an associated vector within the numerical solving routine.
• F1.20.97Time kernel requires a transient executioner
• F1.20.98The kernel can be only assigned to the existing vector tags in the system
• F1.20.99The kernel can be only assigned to the existing matrix tags in the system
• F1.20.100The system shall be able to reproduce the simple_transient_diffusion test with VectorTimeDerivative (hand-coded Jacobian).
• F1.20.101The Jacobian from VectorTimeDerivative shall be perfect
• F1.20.102The system shall compute second-order time derivatives for vector variables
• F1.20.103MOOSE shall be able to solve a curl-curl problem using NEDELEC_ONE elements
• F1.20.104MOOSE shall be able to couple a vector variable into a standard kernel
• F1.20.105MOOSE shall be able to assign a default value for a vector variable from the source file
• F1.20.106MOOSE 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
• F1.20.107MOOSE shall be able to assign a default value for a vector variable from the input file and still have the correct jacobian
• F1.20.108MOOSE shall be able to solve multi-dimensional problems with LAGRANGE_VEC variables
• F1.20.109MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables
• F1.20.110MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables and produce the correct Jacobian
• F1.20.111MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and reproduce the hand-coded result
• F1.20.112MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and have a perfect Jacobian
• F1.20.113MOOSE shall be able to couple a vector variable into a standard kernel and produced the correct Jacobian
• F1.20.114MOOSE shall be able to couple a standard variable into a vector kernel. Additionally, MOOSE shall be able to calculate time derivatives of variable gradients.
• F1.20.115MOOSE shall be able to compute the correct Jacobian when coupling a standard variable into a vector kernel and taking time derivatives of variable gradients.
• F1.20.1161) 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
• F1.20.117The system shall error if the 'function' and 'function_x' parameters are both set within the VectorFunctionIC object.
• F1.20.118The system shall error if the 'function' and 'function_x' parameters are both set within the ADVectorFunctionDirichletBC object.

• framework: Markers
• F1.21.1The system shall include the ability to mark a mesh subdomain for uniform refinement.
• F1.21.2The adaptivity system shall create an auxiliary field variable that marks elements for refinement within a rectangular region.
• F1.21.3The adaptivity system shall adapt the mesh within a rectangular region.
• F1.21.4The system shall include the ability to combine multiple mesh refinement markers into a single value.
• F1.21.5The system shall include the ability to mark elements within a subdomain to be unchanged for mesh adaptivity.
• F1.21.6The 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.
• F1.21.7The system shall include the ability to use the same error extremes during all calculations of error fraction values during mesh adaptivity.
• F1.21.8The system shall include a means for computing mesh refinement flags based on an absolute values of error.
• F1.21.9The system shall include a means for performing mesh adaptivity based on an absolute values of error.
• F1.21.10It shall not be possible to specify Markers to run on the displaced mesh.
• F1.21.11The system shall support the ability to mark elements for mesh adaptivity based on a bounding box with arbitrary orientation.
• F1.21.12The system shall support access to finite element quadrature point locations during the calculation of refinement marker flags.
• F1.21.13The 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.
• F1.21.14The system shall support marking the entire finite element mesh for refinement.
• F1.21.15The 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.
• F1.21.16The 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
• F1.22.1The Jacobian from a material property declared as AD and gotten as AD shall be accurate
• F1.22.2The Jacobian from a material property declared as regular and gotten as AD shall be inaccurate
• F1.22.3The Jacobian from a material property declared as AD and gotten as regular shall be inaccurate
• F1.22.4The Jacobian from a material property declared as regular and gotten as regular shall be inaccurate
• F1.22.5AD shall work with stateful material properties and the Jacobian shall be beautiful
• F1.22.6The time evolution of the stateful diffusivity property shall show that AD works with stateful material properties
• F1.22.7We shall be able to set default values for AD material properties
• F1.22.8We shall have a perfect Jacobian when using default values for an AD material property
• F1.22.9ADPiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable
• F1.22.10PiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable and perform approriate scaling
• F1.22.11ADPiecewiseLinearInterpolationMaterial shall throw an error if x, y, and xy_data are all specified
• F1.22.12ADPiecewiseLinearInterpolationMaterial shall throw an error if x and xy_data are both specified
• F1.22.13ADPiecewiseLinearInterpolationMaterial shall throw an error if x and y vectors are different lengths
• F1.22.14ADPiecewiseLinearInterpolationMaterial shall throw an error if xy_data vector is not a multiple of two
• F1.22.15ADPiecewiseLinearInterpolationMaterial shall calculate perfect Jacobians
• F1.22.16The system shall provide material properties in boundary restricted objects acting on nodal variables.
• F1.22.17The system shall provide material properties in boundary restricted objects acting on elemental variables.
• F1.22.18The system shall issue an error when multiple materials properties with the same name are declared on the same block.
• F1.22.19The 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.
• F1.22.20The 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 they may be retrieved before being declared.
• F1.22.21The system shall support supplying a constant literal in place of a property name for material property derivative consumers.
• F1.22.22The system shall support optional coupling where materials that do not exist are returned as valid objects containing zero.
• F1.22.23The system shall issue an error when required derivative materials that are retrieved are never declared.
• F1.22.24The 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.
• F1.22.25The system shall not calculate materials that are meant to be controlled by other materials (discrete) materials.
• F1.22.26The 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.
• F1.22.27The 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.
• F1.22.28The system shall issue a warning when a "discrete" material's "reset" method is not defined.
• F1.22.29The system shall be able to produce a valid material object on the fly for use in calculations requiring material properties.
• F1.22.30The system shall be able to compute a single value per element for efficiency that is made available to all quadrature points in a coupled calculation.
• F1.22.31The 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.
• F1.22.32The system shall support retrieving a single property (name) supplied by different materials on different mesh blocks.
• F1.22.33The 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.
• F1.22.34The system shall report that a material property is available when it is defined on a subdomain.
• F1.22.35The system shall support retrieving a boundary restricted material property for performing a calculation on a boundary.
• F1.22.36The 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.
• F1.22.37The 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
• F1.22.38The 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
• F1.22.39The system shall be able to calculate stateful material properties in an interface material object
• F1.22.40The system shall evaluate interface materials such that they can be used in boundary restricted elemental auxiliary kernels
• F1.22.41The 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.
• F1.22.42The system shall support material property calculations for used with discontinuous Galerkin finite element method.
• F1.22.43The system shall support material property calculations that are restricted to boundaries on the mesh.
• F1.22.44The system shall error if material property calculations result in a cyclic dependency.
• F1.22.45The system shall error is a material property is requested on a subdomain on which it is not defined.
• F1.22.46The system shall support material property calculations that operate on auxiliary systems and during volume and surface residual calculations.
• F1.22.47The system shall error if material properties are not computed on all subdomains.
• F1.22.48The 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.
• F1.22.49The system shall support the calculation of material properties that vary at numerical integration quadrature points.
• F1.22.50The system shall only compute material properties when they are needed (consumed by other objects).
• F1.22.51The system shall support having multiple materials supplying multiple unique material properties on the same subdomains of the mesh.
• F1.22.52The system shall not create a dependency when old versions of material properties are retrieved and used in calculations.
• F1.22.53The 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.
• F1.22.54The system shall error if the supplied output options for material data output are not consistent with the list of available outputs.
• F1.22.55PiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable
• F1.22.56PiecewiseLinearInterpolationMaterial shall create a material with a linear interpolation of a variable and perform approriate scaling
• F1.22.57PiecewiseLinearInterpolationMaterial shall throw an error if x, y, and xy_data are all specified
• F1.22.58PiecewiseLinearInterpolationMaterial shall throw an error if x and xy_data are both specified
• F1.22.59PiecewiseLinearInterpolationMaterial shall throw an error if x and y vectors are different lengths
• F1.22.60PiecewiseLinearInterpolationMaterial shall throw an error if xy_data vector is not a multiple of two
• F1.22.61The system shall be able to produce stateful material properties that can be consumed by other objects in the system.
• F1.22.62The system shall support coupling in an auxiliary field variable for use in initializing stateful material properties.
• F1.22.63The system shall allow the retrieval of stateful material properties for calculations on internal sides within a mesh.
• F1.22.64The 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.
• F1.22.65The 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.
• F1.22.66The system shall be able to promote normal material properties to stateful when old/older properties are requested.
• F1.22.67The system shall make material property calculations available during the computation of the initial Residual vector.
• F1.22.68The 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.
• F1.22.69The system shall support the ability to copy stored stateful data from one element to another element.
• F1.22.70The 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.
• F1.22.71The system shall not store any stateful material properties that are declared but never used.
• F1.22.72The system shall be capable of outputting material properties through auxiliary field variables.
• F1.22.73The system shall report and error when invalid indices are requested when attempting to output material properties through auxiliary field variables.
• F1.22.74The system shall only prepare or setup field variables on each element when they are used by a material object.
• F1.22.75The system shall support coupling in a nonlinear field variable for use in initializing stateful material properties.

• framework: Mesh
• F1.23.1The system shall perform identical adaptivity patterns on both the reference mesh and the displaced mesh when it exists.
• F1.23.2The system shall support toggling adaptivity on/off during a simulation.
• F1.23.3The system shall perform one or more adaptivity steps on the mesh before the simulation begins.
• F1.23.4The system shall support patch-based error estimation among a stencil of elements.
• F1.23.5The system shall support multiple adaptive steps per solve.
• F1.23.6The system shall perform adaptivity on systems containing multiple independent field variables.
• F1.23.7The system shall support running adaptivity on an interval basis (every several time steps).
• F1.23.8The system shall support weighted error estimation when considering multiple field variables for adaptivity.
• F1.23.9The system shall support the use of a centroid-based parallel partitioning scheme.
• F1.23.10The system shall generate pre-split mesh files using a standard input file combined with command line arguments.
• F1.23.11The system shall use pre-split binary mesh files using a standard input file combined with command line arguments.
• F1.23.12The system shall auto-detect and use pre-split meshes using a standard input file combined with command line arguments.
• F1.23.13The system shall use pre-split ascii meshes when the command line parameter also includes the pre-split suffix.
• F1.23.14The system shall use pre-splits for several different numbers of processors auto-detected from the number of MPI processors used.
• F1.23.15The system shall use pre-splits for several different numbers of processors when the command line parameter also includes the pre-split suffix.
• F1.23.16The system shall generate a quadrilateral mesh consisting of concentric circles.
• F1.23.17The 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.
• F1.23.18MOOSE shall be able to build a 1D mesh in parallel
• F1.23.19MOOSE shall be able to build a 2D mesh in parallel
• F1.23.20MOOSE shall be able to build a 3D mesh in parallel
• F1.23.21DistributedGeneratedMesh shall allow mesh biasing
• F1.23.22The system shall read GMesh (.msh) format file meshes.
• F1.23.23The system shall read GMesh (.msh) format file meshes containing multiple boundaries.
• F1.23.24The system shall support refinement of QUAD4 mesh elements.
• F1.23.25The system shall support refinement of QUAD8 mesh elements.
• F1.23.26The system shall support refinement of QUAD9 mesh elements.
• F1.23.27The system shall support refinement of TRI3 mesh elements.
• F1.23.28The system shall support refinement of TRI6 mesh elements.
• F1.23.29The system shall support refinement of HEX8 mesh elements.
• F1.23.30The system shall support refinement of HEX20 mesh elements.
• F1.23.31The system shall support refinement of HEX27 mesh elements.
• F1.23.32The system shall support refinement of TET4 mesh elements.
• F1.23.33The system shall support refinement of TET10 mesh elements.
• F1.23.34The system shall support refinement of PRISM6 mesh elements.
• F1.23.35The system shall support refinement of PRISM15 mesh elements.
• F1.23.36The system shall support refinement of PRISM18 mesh elements.
• F1.23.37The system shall support refinement of PYRAMID5 mesh elements.
• F1.23.38The system shall support refinement of PYRAMID13 mesh elements.
• F1.23.39The system shall support refinement of PYRAMID14 mesh elements.
• F1.23.40MOOSE shall generate a structured mesh on a Cartesian domain.
• F1.23.41MOOSE shall generate first-order, structured meshes with biasing in the x, y, and z directions.
• F1.23.42MOOSE shall generate second-order, structured meshes with biasing in the x, y, and z directions.
• F1.23.43MOOSEs annular mesh generator
  1. shall throw an error if the min radius is larger than the max radius.
  2. shall throw an error if the min angle is greater than or equal to the max angle.
  3. shall throw an error if the angle separation is larger than 360 degrees.
  4. shall throw an error if the number of elements in the angular direction is too small.
  5. shall throw an error if the number of elements in the angular direction is too small.
  6. shall throw an error if the quadrilateral and triangular subdomain ids are the same.
  7. shall create an annulus using quad elements.
  8. shall create an annulus sector using quad elements.
  9. shall create a circular disk using quad elements.
  10. shall create a circular disk sector using quad elements.
• F1.23.44MOOSE shall have an algorithm for meshing an annular region with triangular elements.
• F1.23.45MOOSE shall have an algorithm for generating triangular and quadrilateral meshes for the Ringleb problem.
• F1.23.46The system shall allow writing out the mesh without running a simulation.
• F1.23.47The system shall print out information about the mesh when writing out the mesh.
• F1.23.48The system shall warn when using –mesh-only and there is no clear filename to use
• F1.23.49The system shall support overriding output dimension when necessary to store coordinates in higher planes
• F1.23.50The system shall support writing parallel checkpoint files with –mesh-only
• F1.23.51The system shall support simulations on meshes containing both 1D and 2D element types.
• F1.23.52The system shall support proper material evaluations on meshes containing both 1D and 2D element types.
• F1.23.53The system shall support simulations on meshes containing both 1D and 3D element types.
• F1.23.54MOOSE shall generate meshes with different set of element integers and properly stitch them.
• F1.23.55The system shall support interchangeable use of integer and string identifiers for mesh entities.
• F1.23.56The system shall support interchangeable use of integer and string identifiers for mesh entities read from the XDA format.
• F1.23.57The system shall support interchangeable use of integer and string identifiers within the BCs/Periodic block.
• F1.23.58The system shall support the ability to assign and use string names to mesh entities during the simulation startup.
• F1.23.59The system shall support writing solution data in the Nemesis parallel file format.
• F1.23.60The system shall support the re-partitioning of mesh files input using the Nemesis format.
• F1.23.61The system shall issue an error if no Mesh block is provided.
• F1.23.62The system shall issue a diagnostic when a referenced node set does not exist in the mesh
• F1.23.63The system shall generate a mesh using one or more meshes stitched into a pattern controlled by a 2D array.
• F1.23.64The system shall read in a previously generated "patterned mesh" and run a simulation using that mesh.
• F1.23.65The system shall produce a valid periodic node map with only one periodic constraint direction.
• F1.23.66The system shall produce a valid periodic node map with two periodic constraint directions.
• F1.23.67The system shall produce a valid periodic node map with three periodic constraint directions.
• F1.23.68The system shall issue a diagnostic when a referenced side set does not exist in the mesh.
• F1.23.69The system shall have the ability to construct a side set from a set of nodes.
• F1.23.70A mesh can be split into a specified number of files using command line options.
• F1.23.71A mesh can be pre-split properly and used to generate equivalent results to running a simulation with the unsplit mesh.
• F1.23.72Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode
• F1.23.73Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode
• F1.23.74The mesh splitter will throw an error when an attempt is made to split a "DistributedMesh".
• F1.23.75The mesh splitter capability will honor geometric RelationshipManager objects.
• F1.23.76Meshes that are pre-split with active RelationshipManager objects work the same as if using an online DistributedMesh.
• F1.23.77The system shall support the creating a single mesh from multiple meshes stitched together.
• F1.23.78The system shall error if at least one mesh file is not supplied when creating a mesh from multiple meshes stitched together.
• F1.23.79The system shall produce a parallel partition based on mesh subdomains for the Mac platform.
• F1.23.80The system shall produce a parallel partition based on mesh subdomains agnostic of platform.
• F1.23.81The system shall produce a parallel partition based on mesh subdomains for the Linux platform.
• F1.23.82The system shall construct a mesh by "tiling" another mesh repeatedly.
• F1.23.83The system shall support having a truly unique_id (never recycled) for all mesh elements and nodes when using replicated mesh.
• F1.23.84The system shall support having a truly unique_id (never recycled) for all mesh elements and nodes when using distributed mes.

• framework: Meshgenerators
• F1.24.1The system shall support automatic addition of sidesets based on outward facing normals of the mesh.
• F1.24.2The system shall group automatically added sidesets when multiple surfaces share the same outward facing normal.
• F1.24.3The system shall have the capability of generating a mesh based upon an annular geometry.
• F1.24.4The system shall be capable of deleting all of the elements in a mesh based on subdomain ID.
• F1.24.5The 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.
• F1.24.6The 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.
• F1.24.7The system shall be capable of splitting existing mesh boundary sets where their underlying subdomain changes
  1. on external boundaries, and
  2. on internal boundaries.
• F1.24.8MOOSE shall be able to create separate blocks in a mesh.
• F1.24.9MOOSE shall be able to create separate blocks in a mesh.
• F1.24.10MOOSE shall be able to create separate blocks in a mesh.
• F1.24.11MOOSE shall be able to create separate blocks in a mesh.
• F1.24.12MOOSE shall be able to create separate blocks in a mesh.
• F1.24.13MOOSE shall be able to create separate blocks in a mesh.
• F1.24.14MOOSE shall generate an non-uniform mesh on a Cartesian domain.
• F1.24.15MOOSE shall generate an non-uniform mesh on a Cartesian domain.
• F1.24.16MOOSE shall generate an non-uniform mesh on a Cartesian domain.
• F1.24.17The system shall support the ability to combine multiple meshes:
  1. using a single input mesh at multiple positions,
  2. using multiple meshes at multiple positions, and
  3. using multiple meshes with no positions.
• F1.24.18The system shall error when trying to combine multiple meshes,
  1. but only one input is supplied with no positions, or
  2. the number of meshes and the number of positions is mismatched.
• F1.24.19The system shall have the capability to generate a mesh pattern consisting of concentric circles contained within a square.
• F1.24.20The system shall support the generation of meshes for both reference and displaced mesh configurations.
• F1.24.21MOOSE shall be able to use libmesh mesh generation tools.
• F1.24.22The 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.
• F1.24.23The system shall have the ability to add extra mesh node sets based on existing node IDs.
• F1.24.24The system shall be able to extrude a mesh with variable height elevations, with variable numbers of layers, and swap subdomain IDs
• F1.24.25The system shall have the ability to generate a mesh by reading it from a file.
• F1.24.26The 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.
• F1.24.27The system shall support selecting an earlier generation state of the mesh generator system used to generate the final mesh for a simulation.
• F1.24.28The 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.
• F1.24.29MOOSE shall be able to use libmesh mesh generation tools.
• F1.24.30MOOSE shall generate a warning if Mesh Generators are used with a mesh type that does not accept them
• F1.24.31The system shall support the ability to import meshes written using the General Mesh Viewer format.
• F1.24.32The system shall have the ability to read boundary information from Gmsh formatted mesh files.
• F1.24.33MOOSE shall be able to read in an image.
• F1.24.34The system shall be able to create different subdomains
  1. using boundary ids.
  2. using boundary names.
• F1.24.35The system shall be able to combine multiple meshes into a single unconnected mesh.
• F1.24.36The 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.
• F1.24.37MOOSE shall be able to create sidesets.
• F1.24.38The system shall support the ability for mesh generators to save attributes to a stateful data store available for use when recovering a simulation.
• F1.24.39The system shall issue an error when mesh meta-data properties are requested but never declared.
• F1.24.40The system shall have the ability to assign mesh side sets based on parsed spatial functions.
• F1.24.41The system shall have the ability to assign mesh subdomains based on parsed spatial functions.
• F1.24.42The system shall be able to create a patch test mesh with:
  1. quad4 elements,
  2. quad8 elements,
  3. hex8 elements, and
  4. hex20 elements.
• F1.24.43The system shall have the ability to stetch multiple input meshes together into a new mesh based upon a user-defined pattern.
• F1.24.44The system shall provide a method for deleting mesh elements lying on one side of a user-defined plane.
• F1.24.45The 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.
• F1.24.46The shall be able to rename or renumber mesh boundaries prior to running the simulation:
  1. by identifying both old and new boundaries by ID,
  2. by identifying old boundaries by ID and new boundaries by name,
  3. by identifying old boundaries by name and new boundaries by ID, and
  4. by identifying both old and new boundaries by name.
• F1.24.47The system shall throw and error when renaming boundaries when an existing boundary cannot be found on the mesh.
• F1.24.48The system shall support the ability to create a mesh for a "Ringleb" geometry.
• F1.24.49The 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.
• F1.24.50The 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.
• F1.24.51The 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.
• F1.24.52The 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.
• F1.24.53The system shall be able to generate mesh side sets for all external surfaces on the mesh for each unique normal.
• F1.24.54The system must be able to replace the side sets when applying side sets during mesh generation.
• F1.24.55The 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.
• F1.24.56MOOSE shall be able to create sidesets.
• F1.24.57MOOSE shall be able to use libmesh mesh mdification tools.
• F1.24.58MOOSE shall be able to create meshes.
• F1.24.59MOOSE shall be able to generate new meshes by stacking up existing meshes.
• F1.24.60MOOSE shall be able to generate new meshes by stacking up existing meshes.
• F1.24.61MOOSE shall be able to generate new meshes by stacking up existing meshes.
• F1.24.62MOOSE shall be able to use libmesh mesh modification tools.
• F1.24.63MOOSE shall be able to use libmesh mesh modification tools.
• F1.24.64MOOSE shall be able to use the BoundingBox class.
• F1.24.65MOOSE shall be able to use the BoundingBox class.
• F1.24.66MOOSE shall be able to use the BoundingBox class.
• F1.24.67The system shall have the ability to change or overwrite the subdomain IDs of all elements in a mesh.
• F1.24.68MOOSE shall be able to use libmesh mesh modification tools.
• F1.24.69MOOSE shall be able to use libmesh mesh modification tools.

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

• framework: Misc
• F1.26.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
• F1.26.2Coupling an auxiliary variable into a DGKernel shall not destroy the Jacobian
• F1.26.3We shall be able to do NL variable coupling into a DGKernel
• F1.26.4We shall be able to do NL variable coupling into a DGKernel and have a good Jacobian
• F1.26.5The compiled application shall be capable of returning the name used for registering objects.
• F1.26.6The system shall report an error when a material property is not defined on a boundary.
• F1.26.7The system shall report an error when a material property requested by a UserObject is not defined on a boundary.
• F1.26.8The system shall report an error when a material property requested by a DGKernel is not defined on a boundary.
• F1.26.9The system shall report an error when a material property requested by a DGKernel is not defined on a subdomain.
• F1.26.10The system shall verify that objects that use subdomain restricted variables are defined on a subset of the restricted domain area.
• F1.26.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.
• F1.26.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.
• F1.26.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.
• F1.26.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.
• F1.26.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.
• F1.26.16The system shall report an error when the system solver is unable to find a converged solution.
• F1.26.17The system shall report an error message when a range-checked parameter is out of range.
• F1.26.18The system shall report an error when a null pointer-checked parameter is retrieved from the InputParameters object.
• F1.26.19The system shall report an error when multiple AuxVariables are added to the system with conflicting types.
• F1.26.20The system shall report an error when multiple Scalar AuxVariables are added to the system with conflicting types.
• F1.26.21The system shall report an error when an attempt to is made to instantiate a non-existent BoundaryCondition object.
• F1.26.22The system shall report an error when a non-existent nonlinear variable name is used by a MooseObject.
• F1.26.23The system shall report an error message when an invalid enumeration is supplied in any MooseEnum type.
• F1.26.24The system shall report an error message when an invalid Executioner is specified.
• F1.26.25The system shall report an error message when an invalid Kernel is specified.
• F1.26.26The system shall report an error message when a Kernel object attempts to access a non-existent variable.
• F1.26.27The system shall report an error when an invalid Material is specified.
• F1.26.28The system shall report an error when a previously undeclared variable is used in a parsed function expression.
• F1.26.29The system shall report an error when a first order element is used with a second order discretization.
• F1.26.30The system shall report an error message when a deprecated input file block is used.
• F1.26.31The system shall report a warning when a deprecated parameter with a default value is explicitly set by the user.
• F1.26.32The system shall report a warning when an optional deprecated parameter is explicitly set by the user.
• F1.26.33The system shall report an error when conflicting domain restrictions are applied to a single object.
• F1.26.34The system shall report an error when the number of ids and corresponding block names are mismatched.
• F1.26.35The system shall report an error when a duplicate name is provided for a set of unique block ids.
• F1.26.36The system shall report an error when the number of ids and corresponding boundary names are mismatched.
• F1.26.37The system shall report an error when a duplicate name is provided for a set of unique boundary ids.
• F1.26.38The system shall report an error when the linear interpolation utility is supplied with bad domain values.
• F1.26.39The system shall report an error when the Piecewise utility encounters an unexpected column data format.
• F1.26.40The system shall report an error when the Piecewise utility encounters an unexpected row data format.
• F1.26.41The system shall report an error when the Piecewise utility encounters inconsistent domain and range data.
• F1.26.42The system shall report an error when an invalid enumeration is supplied in the Piecewise utility.
• F1.26.43The system shall report an error when the Piecewise data is over-specified with the data file option.
• F1.26.44The system shall report an error when the Piecewise data is over-specified with row/column data.
• F1.26.45The system shall report an error when either the domain or range is missing when using the domain/range option in the Piecewise utility.
• F1.26.46The system shall report and error if the supplied domain/range pairs are not even in the Piecewise utility.
• F1.26.47The system shall report an error if no function is supplied in the Piecewise utility.
• F1.26.48The system shall report an error if the xy_data is supplied but the function is missing in the Piecewise utility.
• F1.26.49The system shall report an error when the number of columns appears incorrect in the Piecewise utility.
• F1.26.50The system shall report an error when an out of range y-column index is supplied in the Piecewise utility.
• F1.26.51The system shall report an error when an out of range x-column index is supplied in the Piecewise utility.
• F1.26.52The system shall report an error if too many rows are supplied when the data is expected to contain row information.
• F1.26.53The system shall report an error when an out of range x-row index is supplied in the Piecewise utility.
• F1.26.54The system shall report an error when an out of range y-row index is supplied in the Piecewise utility.
• F1.26.55The system shall report an error when the x and y index in file are equal in the Piecewise utility.
• F1.26.56The system shall report an error if one or more domain blocks do not have any active Kernels objects assigned.
• F1.26.57The system shall report an error if one or more variables do not have any active Kernel objects assigned.
• F1.26.58The system shall report an error when an elemental variable (no continuity) is coupled to a variable with continuity.
• F1.26.59The system shall report an error when an active input block section is specified but missing.
• F1.26.60The system shall report an error when a material property is requested but not supplied on a mesh block.
• F1.26.61The system shall report an error when a coupled variable is supplied that was not added as a valid parameter.
• F1.26.62The system shall report an error when the data file is non-existent or not-readable in the Piecewise utility.
• F1.26.63The system shall report an error when the coupled function does not exist or can not be parsedfor the Piecewise utility.
• F1.26.64The system shall report an error when one or more material properties are missing from any mesh block.
• F1.26.65The system shall report an error when a material property is supplied on some blocks but missing on other blocks where it is requested.
• F1.26.66The system shall report an error when only "old" properties are supplied but current properties are requested.
• F1.26.67The system shall report an error when only "older" properties are supplied but current properties are requested.
• F1.26.68The system shall report an error when the mesh file cannot be found.
• F1.26.69The system shall report an error when a required parameter is not supplied in an Action.
• F1.26.70The system shall report an error when a specific mesh required parameter is not supplied.
• F1.26.71The system shall report an error when the special "type" parameter is not supplied for a MooseObject.
• F1.26.72The system shall report an error when a required parameter is not supplied in a MooseObject.
• F1.26.73The system shall report an error when a required coupling parameter is missing.
• F1.26.74The system shall report an error when more than one preconditioner block is supplied.
• F1.26.75The system shall abort the solve and report a floating point error when a NaN is produced during user computation with the Steady executioner.
• F1.26.76The system shall abort the solve and report a floating point error when a NaN is produced during user computation with the Transient executioner.
• F1.26.77The system shall report an error when a nodal AuxKernel attempts to access a material property.
• F1.26.78The system shall report an error when the same named parameter appears multiple times in the same input file.
• F1.26.79The system shall report an error when the coordinate transformation conflicts with the underlying element types.
• F1.26.80The system shall report an error when nonlinear and auxiliary variables are declared with the same name.
• F1.26.81The system shall report an error when an AuxKernel is applied outside of the domain where a restricted variable exists.
• F1.26.82The system shall report an error when a Kernel is applied outside of the domain where a restricted variable exists.
• F1.26.83The system shall report a warning when an unused parameter is provided through the input file or an Action.
• F1.26.84The system shall report a warning when an unused parameter is supplied on the command line.
• F1.26.85The system shall report an error when a UserObject and a Postprocessor are added with the same names.
• F1.26.86The system shall report and error when a UserObject and a VectorPostprocessor are added with the same names.
• F1.26.87The 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.
• F1.26.88The system shall report an error when a Postprocessor value is requested from a non-existent Postprocessor.
• F1.26.89The system shall report a standard Unix usage statement when an invalid command line switch is used.
• F1.26.90The system shall report an error when a required variable is missing from the ICs input file block.
• F1.26.91The system shall report an error when a boundary restriction is applied to a non-nodal variable discretization.
• F1.26.92The system shall report an error when coupling to old temporal solution vectors in a Steady (no time) Executioner.
• F1.26.93The system shall report an error when coupling to a time derivative solution vector in a Steady (no time) Executioner.
• F1.26.94The system shall report an error when an older scalar solution variable is accessed in a Steady (no time) Executioner.
• F1.26.95The system shall report an error when an older time derivative scalar solution variable is accessed in a Steady (no time) Executioner.
• F1.26.96The system shall report an error when a coupled variable is not defined in the same region as the variable performing the coupling.
• F1.26.97The system shall report the successful parsing and interpretation of input file syntax when using the "–check-input" command line flag.
• F1.26.98The system shall report an error when performing nodal constraints when there is a mismatch in the number of constrained nodes.
• F1.26.99The system shall report an error when requested to check the syntax in an input file but no input file is supplied.
• F1.26.100The system shall report an error when multiple time schemes are specified in the same input file.
• F1.26.101The system shall report an error when there is a mismatch between the parameter for an object and the type of object are mismatched.
• F1.26.102The system shall report an error when the variables representing displacement are of a lower order than the mesh.
• F1.26.103The 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").
• F1.26.104The system shall report an error when floating point input parameter types fail to parse as floating point numbers.
• F1.26.105The system shall report an error when a scalar variable is used where a spatial variable is expected.
• F1.26.106The system shall report an error when a field variable is used where a scalar variable is expected.
• F1.26.107The system shall report an error when an invalid coupled spatial variable is requested.
• F1.26.108The system shall report an error when an invalid coupled scalar variable is requested.
• F1.26.109The system shall report an error when an attempt is made to couple a variable with itself.
• F1.26.110The system shall report an error when an input file cannot be opened and read.
• F1.26.111The system shall report an error when a Kernel attempts to use an auxiliary variable.
• F1.26.112The system shall report an error when a boundary condition object attempts to use an auxiliary variable.
• F1.26.113The system shall report an error when an AuxKernel specifies a non-existent variable.
• F1.26.114The system shall report an error when a scalar Kernel specifies a non-existent variable.
• F1.26.115The system shall report an error when a nodal Kernel attempts to use an auxiliary variable.
• F1.26.116The system shall report an error when a constraint attempts to use an auxiliary variable.
• F1.26.117The system shall report an error when a scalar auxiliary Kernel attempts to use a solution variable.
• F1.26.118The system shall report an error when a DiracKernel attempts to use an auxiliary variable.
• F1.26.119The system shall report an error when a discontinuous Galerkin Kernel attempts to use a solution variable.
• F1.26.120The system shall report an error when an interface Kernel attempts to use an auxiliary variable.
• F1.26.121The system shall report an error when a Kernel attempts to retrieve an empty string variable.
• F1.26.122The system shall report an error when a vector Kernel attempts to use a scalar solution variable.
• F1.26.123The system shall report an error when a Kernel attempts to use a vector solution variable.
• F1.26.124The system shall report an error if users try to get nodal values of non-nodal variables.
• F1.26.125The system shall report an error if users try to get old nodal values of non-nodal variables.
• F1.26.126The system shall report an error if users try to get older nodal values of non-nodal variables.
• F1.26.127The system shall have an integrity check that ensures an Executioner object exists in the system.
• F1.26.128The system shall report an error when nodal boundary condition is applied on a non-nodal variable.
• F1.26.129The system shall produce a warning when non-expired deprecated code is executed.
• F1.26.130The system shall produce a warning when expired deprecated code is executed.
• F1.26.131The system shall produce an error when the –no-deprecated-flag is passed and deprecated code is executed.
• F1.26.132The system shall produce a warning indicating a possible replacement when deprecated code is superseded.
• F1.26.133The system allow coupling between variables on or off displaced meshes
  1. not using automatic differentiation methods
  2. using automatic differentiation methods
• F1.26.134The system shall support throwing an exception during the residual calculation, which will cut back the time step.
• F1.26.135The system shall support throwing an exception during the residual calculation on a non-zero rank, which will cut back the time step.
• F1.26.136The system shall support throwing an exception during the Jacboain calculation, which will cut back the time step.
• F1.26.137The system shall support throwing an exception during the Jacobian calculation on a non-zero rank, which will cut back the time step.
• F1.26.138The system shall support throwing an exception during the initial condition calculation, which will terminate the solve.
• F1.26.139The system shall support throwing an error during a residual calculation, which will terminate the solve.
• F1.26.140The system shall support throwing an error during a Jacobian calculation, which will terminate the solve.
• F1.26.141The system shall allow users to skip exception checks to avoid global communication.
• F1.26.142The system shall maintain a flag available for inspection indicating the current "execution stage" enumeration.
• F1.26.143The system shall verify equality among the current, old, and older solution vectors prior to running the simulation.
• F1.26.144The system shall support a testing mechanism that fails intermittently.
• F1.26.145We shall be able the scrape the DOFMapOutput and determine when the Jacobian is slightly off
• F1.26.146We shall be able the scrape the DOFMapOutput and determine when the Jacobian is questionable
• F1.26.147We shall throw no errors if the off-diagonal Jacobian is wrong if we are only testing the on-diagonal Jacobian
• F1.26.148If use_displaced_mesh = false then MOOSE will not throw an exception if elements are inverted to produce a negative element Jacobian, in 3D simulations
• F1.26.149A 3D simulation shall throw an exception if there is a zero element Jacobian, when use_displaced_mesh = true
• F1.26.150A 3D simulation shall throw an exception if there is a negative element Jacobian, when use_displaced_mesh = true
• F1.26.151If use_displaced_mesh = false then MOOSE will not throw an exception if elements are inverted to produce a negative element Jacobian, in 2D simulations
• F1.26.152If use_displaced_mesh = false then MOOSE will not throw an exception if elements are distored to produce a zero element Jacobian, in 2D simulations
• F1.26.153A 2D simulation shall throw an exception if there is a zero element Jacobian, when use_displaced_mesh = true
• F1.26.154The PETSc Jacobian test shall reveal nans if there are nans in the matrix
• F1.26.155The system shall support embedding a 1D block inside of a 3D block.
• F1.26.156The maximum number of degrees of freedom for a single variable on a 1D EDGE2 elem shall be 2
• F1.26.157The maximum number of degrees of freedom for a single variable on a 2D QUAD4 elem shall be 4
• F1.26.158The maximum number of degrees of freedom for a single variable on a 2D QUAD9 elem shall be 9
• F1.26.159The maximum number of degrees of freedom for a single variable on a 2D TRI3 elem shall be 3
• F1.26.160The maximum number of degrees of freedom for a single variable on a 2D TRI6 elem shall be 6
• F1.26.161The maximum number of degrees of freedom for a single variable on a 3D HEX8 elem shall be 8
• F1.26.162The testing system shall support the ability to disable geometrical mapping of mesh elements for comparison purposes.
• F1.26.163The system shall be capable of storing residual contributions as an auxiliary field variable for
  1. continuous Galerkin and
  2. discontinuous Galerkin methods.
• F1.26.164The system shall error if the residual calculation contribution is assigned to the incorrect variable for
  1. on-diagonal and
  2. off-diagonal terms.
• F1.26.165The system shall only reinitialize variables values that are consumed by other active objects in the system.
• F1.26.166The system shall make a serialized solution vector available when requested by objects in the system.
• F1.26.167The system shall make a serialized solution vector available when requested by objects in the system when uniform refinement is active.
• F1.26.168The system shall make a serialized solution vector available when requested by objects in the system when adaptivity is active.
• F1.26.169The test system shall have the ability to execute a specific input file.
• F1.26.170The test system shall have the ability to run a test that neither clears expected outputs or runs the expected executeable for multiple output testing.
• F1.26.171The system shall support pausing execution for the purpose of attaching a debugger after launch.
• F1.26.172The system shall support running a user-defined subroutine each time a subdomain change occurs when iterating over the mesh.
• F1.26.173The application executable shall report the version with the –version command line argument.
• F1.26.174The application executable shall report the version with the -v command line argument.

• framework: Mortar
• F1.27.1The system shall support the use of constrains using the mortar method in 1D.
• F1.27.2We shall tell the user that mortar doesn't currently work in 3D
• F1.27.3We shall be able to enforce solution continuity on a conforming mesh for one variable
• F1.27.4We shall be able to enforce solution gradient continuity on a conforming mesh for one variable
• F1.27.5We shall be able to enforce solution continuity on a conforming mesh for two variables
• F1.27.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
• F1.27.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.
• F1.27.8We 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.
• F1.27.9The Jacobian for the solution continuity test case shall be perfect
• F1.27.10The 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)
• F1.27.11We shall be able to do gap conductance on a dynamic mesh using auxiliary displacements
• F1.27.12The Jacobian for the dynamic aux displacement gap conductance test case shall be perfect
• F1.27.13We shall be able to do gap conductance on a dynamic mesh using auxiliary displacements on a fine mesh
• F1.27.14We shall generate the exact expected analytic solution for the gap conductance problem
• F1.27.15We 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
• F1.27.16The Jacobian for the gap conductance test case shall be perfect
• F1.27.17We 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
• F1.27.18We shall be able to enforce periodic boundary conditions on a non-uniform mesh using the mortar method
• F1.27.19The Jacobian for mortar enforcement of periodic boundary conditions shall be perfect

• framework: Multiapps
• F1.28.1The 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.
• F1.28.2The system shall include the ability to execute a sub-application at the centroid of every element within the finite element mesh.
• F1.28.3The system shall detect input file problems with sub app input files.
• F1.28.4The system shall CLI argument problems related to sub app input files.
• F1.28.5The system show error when the number of input files is great than one and doesn't match the number of provided sub app positions.
• F1.28.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 when using CLI overrides.
• F1.28.7The system shall error when the number of sub app input files doesn't match the number of provided positions files.
• F1.28.8The system shall error when both positions are provided in the input file along with a separate file of positions.
• F1.28.9The system shall error when the multiapp positions file is malformed.
• F1.28.10The system shall error when the Multiapp parameter sub_cycling and catch_up are both set to true.
• F1.28.11The MultiApp system shall include the ability to set command line parameters for each sub application from the input file.
• F1.28.12The MultiApp system shall include the ability to set common command line parameters for all sub applications from the input file.
• F1.28.13The MultiApp system shall error when the number of command line arguments supplied in the input file differs from the number if sub apps.
• F1.28.14The system shall include the ability to halt the execution of sub-applications when steady-state is detected.
• F1.28.15The system shall be capable of executing a sub-application that executes completely.
• F1.28.16The 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
• F1.28.17The system shall be able to solve a fine mesh variational inequality problem without grid sequencing but with a lot more nonlinear iterations
• F1.28.18The system shall error if the execution of a sub-application fails during the initial execution.
• F1.28.19The system shall support creating a Multiapp that is not initially enabled
• F1.28.20The 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.
• F1.28.21The system shall support limiting the number of processors for sub-applications.
• F1.28.22The system shall support the ability to re-position sub-applications at a specified time
  1. for single and
  2. multi-level sub-applications.
• F1.28.23The 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.
• F1.28.24The 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,
• F1.28.25The system shall support writing screen output from multi-level sub-applications to a file.
• F1.28.26The system shall be capable of running multiple sub-applications that are defined by input and position file pairs.
• F1.28.27The system shall support outputting sub-application data in a specified position
  1. for single and
  2. multi-level sub-applications.
• F1.28.28The system shall support the the ability to set solver options within sub-applications.
• F1.28.29The system shall allow transient multiapps to use Picard iterations to rerun the time step
• F1.28.30The system shall support adaptive time stepping for transient multiapps with Picard iterations controlled by tolerances
• F1.28.31The system shall reject the solve if the maximum number of Picard iterations is reached without converging
• F1.28.32The system shall allow transient multiapps with Picard iterations controlled by relative tolerances
• F1.28.33The system shall allow transient multiapps with Picard iterations controlled by absolute tolerances
• F1.28.34The system shall allow function-defined time stepping for transient multiapps
• F1.28.35The system shall allow steady-state Picard iteration with multiapps
• F1.28.36The system shall allow fixed number of Picard iterations
• F1.28.37The system shall allow custom convergence check on Picard iteration with derived executioners
• F1.28.38The system shall allow steady-state Picard iteration with pseudo-transient multiapps
• F1.28.39The system shall support performing iterative solves of sub-applications that perform additional time steps to maintain time step consistency with the master application.
• F1.28.40The 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.
• F1.28.41Multiapps shall be able to be restored when a subapp encounters a solve failure.
• F1.28.42CSV file writing should remain unaffected when a subapp encounters a solve failure.
• F1.28.43Multiapps shall be able to cut the master app time step when any subapp encounters a solve failure.
• F1.28.44The system shall support Picard iteration with a FullSolveMultiApp at the root with multiple multiapp levels.
• F1.28.45The system shall support Picard iteration with multiple levels of Multiapps.
• F1.28.46The 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.
• F1.28.47The system shall support performing iterative solves of sub-applications that used smaller time steps than master application.
• F1.28.48The system shall support evaluating sub-applications at spatial positions specified in a file.
• F1.28.49The system shall provide an ability to perform iterative solves with sub-applications.
• F1.28.50The system shall provide an ability to relax solutions with iterative solves with sub-applications.
• F1.28.51The system shall provide an ability to relax sub-applications solutions along with the master solution for during iterative solves.
• F1.28.52The system shall error if provided relaxation factor that is less than or equal to 0 or greater than or equal to 2.
• F1.28.53The 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.
• F1.28.54The system shall support simulations that
  1. that execute sub-applications, which
  2. are capable of being restarted from a previous simulation.
• F1.28.55The system shall support simulations that
  1. that execute with multi-level sub-applications, which
  2. are capable of being restarted from a previous simulation.
• F1.28.56The 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.
• F1.28.57The 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.
• F1.28.58The 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.
• F1.28.59The system shall support the output of sub-application data that operate with smaller time steps then the master application.
• F1.28.60The system shall support the execution of sub-application that operate with adaptive time steps that differ from the master application.
• F1.28.61The 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.
• F1.28.62The system shall support a time offset between the master and a subapp when using the Multiapp system.
• F1.28.63The 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.

• framework: Nodalkernels
• F1.29.1The system shall include ability to include contributions to the residual nodes of a finite element mesh
  1. on a single and
  2. multiple threads.
• F1.29.2The 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
• F1.29.3The 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
• F1.29.4The 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. have a non-singular matrix, and
  3. be incompataible with algebraic multigrid
• F1.29.5The 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
• F1.29.6The system shall show violation of bounds when a non-variational-inequality solver is used
• F1.29.7The system shall support the use of Crank-Nicolson time integration scheme.
• F1.29.8The system shall include ability to include contributions to the residual nodes of a finite element mesh using an LU preconditioner.
• F1.29.9The 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.
• F1.29.10MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method for nodesets.
• F1.29.11The system shall apply scaling to residuals and Jacobians for volumetric PDE terms applied at nodes

• framework: Outputs
• F1.30.1The system shall support the ability to append the date to output filenames.
• F1.30.2The 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.
• F1.30.3The 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.
• F1.30.4The 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.
• F1.30.5The system shall support outputting of simulation data using the ExodusII format using simplified input file syntax.
• F1.30.6The system shall by default display data on the console from:
  1. the Postprocessor system and
  2. the scalar variable system.
• F1.30.7The system shall output a running list of Picard norms during Picard iteration.
• F1.30.8The system shall only output Picard TIMESTEP_BEGIN norms when there are no TIMESTEP_END Multiapps.
• F1.30.9The system shall only output Picard TIMESTEP_END norms when there are no TIMESTEP_BEGIN Multiapps.
• F1.30.10The system shall output Picard norms for TIMESTEP_BEGIN and TIMESTEP_END Multiapps when both exist in the simulation.
• F1.30.11The system shall run a simulation without producing any file-based output.
• F1.30.12The system shall support outputting table based Postprocessor data.
• F1.30.13The system shall output Scalar Variables on the console in a table.
• F1.30.14The system shall warning when multiple console outputs attempt to write to the screen simultaneously.
• F1.30.15The system shall support outputting console information to a file.
• F1.30.16The system shall output Scalar Variables on the console in a table.
• F1.30.17The system shall support outputting Scalar Variables to a file.
• F1.30.18The system shall support writing the console solve log to an output file.
• F1.30.19The system shall support writing norms to the console for each nonlinear variable in the simulation.
• F1.30.20The system shall output a Performance log based on a command line flag.
• F1.30.21The system shall support writing negative time information in the console.
• F1.30.22The system shall support outputting the Performance Log at user specified intervals.
• F1.30.23The system shall support writing to a buffered console object from every MooseObject-derived object.
• F1.30.24The system shall support writing to a buffered console object from const methods in MooseObject-derived objects.
• F1.30.25The system shall support outputting a transformed input file to the screen.
• F1.30.26The system shall support disabling the linear residual output.
• F1.30.27The system shall output a Performance Log based on a single input file parameter.
• F1.30.28The system shall override Performance Log output when conflicting values appear on the command line and input file.
• F1.30.29The system shall support adding an additional output time option without clobbering existing default options.
• F1.30.30The system shall output a "final" label at the end of the simulation before additional screen output occurs.
• F1.30.31The system shall error when specifying an invalid table fit width option.
• F1.30.32The system shall support disabling all console output to the screen.
• F1.30.33The system shall support the output of postprocessors and scalars to CSV files for steady state problems.
• F1.30.34The system shall support the output of postprocessors and scalars to CSV files for transient propblems.
• F1.30.35The system shall support the output of postprocessors and scalars to CSV files for transient problems without a time column.
• F1.30.36The system shall support the output of postprocessors and scalars to Exodus files for transient problems.
• F1.30.37The 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.
• F1.30.38The system shall support CSV output aligned columns and a custom delimiter.
• F1.30.39The system shall support CSV output to the console that is sorted by the variable name.
• F1.30.40The 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.
• F1.30.41The 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.
• F1.30.42The CSV output object 'create_final_symlink' parameter shall be able to disable the creation of the final symlink.
• F1.30.43The CSV output object shall create a symlink to the most recent output with with a '_LATEST' suffix for VectorPostprocessor data.
• F1.30.44The CSV output object 'create_latest_symlink' parameter shall be able to disable the creation of the latest symlink.
• F1.30.45The system shall be include the ability to display variable residual norms.
• F1.30.46The system shall include debug syntax that includes the ability to enable variable residual norm output.
• F1.30.47The system shall be include the ability to display material property information.
• F1.30.48The system shall include debug syntax that includes the ability to enable material property information output.
• F1.30.49The system shall be include the ability to display residual information for variables.
• F1.30.50The system shall include debug syntax that includes the ability to enable variable residual information.
• F1.30.51The system shall be include the ability to display residual information for variables that is limited to non-linear iterations.
• F1.30.52The system shall be include the ability to display residual information for scalar variables.
• F1.30.53The system shall be able to output the displaced mesh for a model with adaptive mesh refinement.
• F1.30.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.
• F1.30.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
• F1.30.56The Output system shall be capable of applying displacements directly to the outputted mesh for steady problems.
• F1.30.57The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems with Kernels using the displaced configuration.
• F1.30.58The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems.
• F1.30.59The 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.
• F1.30.60The system shall error when two outputs with the same name are created.
• F1.30.61The system shall error when two outputs produce a file with the same name.
• F1.30.62The system shall reserve names for output objects:
  1. "none" and
  2. "all."
• F1.30.63The system shall support ExodusII output.
• F1.30.64The system shall support including the executed input file within the ExodusII output.
• F1.30.65The system shall support inclusion of initial condition data within the ExodusII output.
• F1.30.66The system shall support writing non-linear, auxililary, scalar, and postprocessor variables to ExodusII format.
• F1.30.67The system shall support the exclusion of non-linear, scalar, and postprocessor variables from ExodusII output.
• F1.30.68The system shall error if the supplied names for including or excluding variables is invalid.
• F1.30.69The system shall support outputting elemental and scalar variables as nodal variables within ExodusII output.
• F1.30.70The system shall support outputting discontinuous finite element types with the ExodusII format.
• F1.30.71Nemesis output shall work
• F1.30.72GMV output shall work
• F1.30.73We shall be able to dump YAML data
• F1.30.74Executioner output shall only be given once
• F1.30.75Tecplot output shall work
• F1.30.76If tecplot api is available, tecplot output will be given in tecplot binary format
• F1.30.77If tecplot api is not available, tecplot output will be given in ASCII format
• F1.30.78We shall be able to generate gnuplot postscript output
• F1.30.79We shall be able to generate gnuplot png output
• F1.30.80We shall be able to generate gnuplot gif output
• F1.30.81If a postprocessor utilizes the "outputs" parameter, but postprocessor output is disable for the console object, we shall warn the user
• F1.30.82–show-input shall print parameters
• F1.30.83Solution history output shall work
• F1.30.84MOOSE shall support XDR output
• F1.30.85The system shall be able to dump input file syntax in JSON format
• F1.30.86The system shall be able to dump input file syntax in JSON format and exclude test object syntax.
• F1.30.87The system shall be able to dump a subset of JSON formatted syntax.
• F1.30.88The system shall dump line information along with JSON formatted syntax.
• F1.30.89The system shall not include RESIDUAL and JACOBIAN template arguments in the JSON syntax format.
• F1.30.90The system shall be able to dump input file (HIT) syntax.
• F1.30.91The system shall be able to dump a subset of input file (HIT) syntax.
• F1.30.92MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExistsIn
• F1.30.93MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ChildAtLeastOne
• F1.30.94MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ValEnums
• F1.30.95MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check active parameter
• F1.30.96MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check normal_sub
• F1.30.97MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check type_sub
• F1.30.98MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check default type
• F1.30.99MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check MinValInc
• F1.30.100MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExpressionsAreOkay
• F1.30.101MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check Block type MaxOccurs NoLimit
• F1.30.102MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check FunctionName type MaxOccurs NoLimit
• F1.30.103MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check Array type MinOccurs zero
• F1.30.104The system shall support outputting data to the general mesh viewer format.
• F1.30.105The system shall support limiting vector postrocessor data to a specific CSV output object.
• F1.30.106The system shall support specifying an output interval for an output input file block.
• F1.30.107The system shall support specifying an output interval for all outputs.
• F1.30.108The system shall support limiting output to the final timestep of a simulation.
• F1.30.109The system shall support output at specific simulation times.
• F1.30.110The system shall support multiple output objects that have different simulation synchronization times specified.
• F1.30.111The system shall support the disabling of an output object by restricting the execution settings.
• F1.30.112The system shall support the ability to limit output objects only at the beginning and end of a simulation.
• F1.30.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.
• F1.30.114The system shall support output during linear and non-linear iterations during transient simulations using the ExodusII format.
• F1.30.115The 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.
• F1.30.116The system shall support output during linear and non-linear iterations during transient simulations using the VTK format.
• F1.30.117The system shall support output during linear and non-linear iterations during transient simulations using the CSV format.
• F1.30.118The 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.
• F1.30.119The system shall provide an API for retrieving an output object by type and name.
• F1.30.120The system shall provide an API for retrieving all output objects of a type.
• F1.30.121The system shall provide an API for retrieving output objects for the given names and type.
• F1.30.122The system shall provide an API for retrieving all output object names of a type.
• F1.30.123The system shall support the naming of output files based on the input file block name.
• F1.30.124The Nemesis Output object shall output separate files per process for visualization purposes.
• F1.30.125The Nemesis Output object shall support writing elemental variables.
• F1.30.126The Nemesis Output object shall support writing elemental variables with the same numbering on DistributedMesh.
• F1.30.127The Nemesis Ouput object shall support writing scalar variables.
• F1.30.128The Nemesis Ouput object shall support writing scalar variables when using DistributedMesh.
• F1.30.129The system shall support the ability to specify the output dimension when outputting in ExodusII format.
• F1.30.130The system shall support the ability to limit output to certain sub-applications based on name.
• F1.30.131The system shall include the ability to limit automatic output of adaptivity objects, including
  1. indicators and
  2. markers.
• F1.30.132The system shall allow the user to select different console output intervals.
• F1.30.133The system shall display active output information with corresponding execute flags.
• F1.30.134The 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.
• F1.30.135The system shall include an example demonstrating the use of oversampling.
  1. without and
  2. with mesh adaptivity.
• F1.30.136The system shall include the ability to overwrite existing timesteps when writing ExodusII format.
• F1.30.137MOOSE shall output a performance log for multiapps with sub_cycling enabled.
• F1.30.138MOOSE shall output a performance log for multiapps with sub_cycling enabled.
• F1.30.139MOOSE shall output a performance log for multiapps with sub_cycling enabled.
• F1.30.140MOOSE shall have the ability to output a detailed performance log
• F1.30.141MOOSE shall be able to produce png images:
  1. for 2D square images,
  2. arbitrary shapped domains,
  3. and complex shapes with periodic boudary conditions.
• F1.30.142The system shall support offseting the spatial position of a domain during output.
• F1.30.143The system shall support the ability to specify the output object for postprocessor data from within the input file block defining the postprocessor.
• F1.30.144The system shall error if an invalid output name is provided within the postprocessor input file block.
• F1.30.145The system shall support limiting postprocessor output to the screen.
• F1.30.146The system shall support limiting postprocessor output to from within the input file syntax of an output object.
• F1.30.147The system shall error if a postprocessor variable is listed for suppression and inclusion within an output object block in the input file.
• F1.30.148The 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.
• F1.30.149Correctly set up initial recover files for the part2 test.
• F1.30.150A simulation executed using the "–recover" flag successfully runs a simulation using the specified recover file argument.
• F1.30.151Correctly set up initial recover files for the part2_latest test.
• F1.30.152A 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.
• F1.30.153The system shall support the ability to output the residual norms of individual variables.
• F1.30.154The system shall support writing file to sub-directories.
• F1.30.155The system shall print the various components of the simulation information header to the screen
• F1.30.156The system shall print the mesh information to the screen when the mesh changes
• F1.30.157The system shall print the auxiliary system information to the screen when the mesh changes
• F1.30.158The system shall print the nonlinear system information to the screen when the mesh changes
• F1.30.159The system shall support Tecplot output.
• F1.30.160The system shall support appending Tecplot output files.
• F1.30.161The system shall optionally support writing binary Teckplot files.
• F1.30.162The system shall guarantee that scalar variables are in the proper state for output when outputting:
  1. ExodusII format and
  2. CSV format.
• F1.30.163The system shall support outputting field and scalar data to the ExodusII format.
• F1.30.164The system shall error if a variable is marked for output and output suppression.
• F1.30.165The system shall error if a variable is perscribed for output but does not exist.
• F1.30.166The system shall test that output of an auxiliary field can be disabled within the input block defining the variable.
• F1.30.167The system shall support a system for including or suppressing output variables the operates when only a single variable for each type exists.
• F1.30.168The system shall support a system for including or suppressing output variables.
• F1.30.169The variables specified in an Output object's 'hide = ' list shall not appear in the output file.
• F1.30.170The system shall optionally support output of files using the VTK format:
  1. in serial and
  2. in parallel.
• F1.30.171The system shall optionally support output of solution data using the VTK format:
  1. in serial with a replicated mesh,
  2. in parallel with a replicated mesh, and
  3. in parallel with a distributed mesh.
• F1.30.172The system shall support the output of data using native libMesh formats:
  1. in XDA (ASCII) format and
  2. in XDR (binary) format.
• F1.30.173The system shall support simultaneous output of the ASCII and binary forms of the libMesh native format.

• framework: Parser
• F1.31.1The system shall support active/inactive parameters to selectively enable/disable subblocks within all input file blocks.
• F1.31.2The system shall produce an error when the active parameter refers to a non-exiseant block.
• F1.31.3The system shall produce an error when the inactive parameter refers to a non-existent block.
• F1.31.4The system shall produce an error when both the active and inactive parameters are present in the same block.
• F1.31.5The system shall honor the active or inactive parameters at the top (root) level.
• F1.31.6The system shall support the ability to override input file parameters from the command line.
• F1.31.7The system shall support the ability to globally change MultiApp input file syntax from the command line.
• F1.31.8The system shall support the ability to change a whole MultiApp's (multiple SubApps) input file syntax from the command line.
• F1.31.9The system shall support the ability to change individual SubApp input file syntax from the command line.
• F1.31.10The system shall produce an error when a SubApp command line override index is not valid.
• F1.31.11The system shall output all registered objects in HIT format.
• F1.31.12The system shall output all registered objects in single line format.
• F1.31.13The system shall support parameter substitution in input files using command line variable expressions.
• F1.31.14The system shall support parameter substitution in input files using variable expressions from within the same input file.
• F1.31.15The system shall support reading in jagged double-indexed arrays from the input file using two delimiters for columns and rows respectively.
• F1.31.16The system shall support vector size checking on input parameter vectors:
  1. for ints,
  2. for Reals.
• F1.31.17The 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.
• F1.31.18The system shall support vector bounds checking on input parameter vectors.
• F1.31.19The system shall support checking for non-empty input parameter vectors.

• framework: Partitioners
• F1.32.1The system shall support a block-weighted partitioner
  1. when using ReplicatedMesh
  2. and when using DistributedMesh.
• F1.32.2MOOSE shall provide a simple regular grid-based partitioner
• F1.32.3MOOSE shall error if the GridPartitioner is run on an incompatible number of processors
• F1.32.4Make MOOSE support ptscotch via PETSc
• F1.32.5ptscotch shall support element-weighted graphs for balancing workload
• F1.32.6ptscotch shall support side-weighted graphs for minimizing communication
• F1.32.7ptscotch shall take both side weights and element weights into consideration
• F1.32.8Make MOOSE support parmetis via PETSc
• F1.32.9Parmetis shall support element-weighted graphs for balancing workload
• F1.32.10Parmetis shall support side-weighted graphs for minimizing communication
• F1.32.11Parmetis shall take side weights and element weights into consideration
• F1.32.12Parmetis shall support presplit
• F1.32.13MOOSE shall support a serial partitioner Chaco
• F1.32.14MOOSE shall support a serial partitioner party
• F1.32.15MOOSE shall provide a random partitioner

• framework: Postprocessors
• F1.33.1The AreaPostprocessor shall compute the "area" or dimension - 1 "volume" of sides.
• F1.33.2The 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.
• F1.33.3The system shall compute the average value of a quantity along the axis of rotation in an axisymmetric coordinate system.
• F1.33.4The system shall support calculating the value change over time
  1. with respect to the previous calculation and
  2. with respect to the initial calculation.
• F1.33.5The 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.
• F1.33.6The system shall allow for the retrieval of raw elemental degree-of-freedom values directly for elemental evaluations.
• F1.33.7The system shall have the ability to accumulate a scalar value over time.
• F1.33.8The 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.
• F1.33.9The system shall report an error when a request for a non-existant Postprocessor value is made.
• F1.33.10The system shall support computing the difference between two scalar Postprocessor values.
• F1.33.11The system shall execute dependent Postprocessors first when computing the difference between two Postprocessors.
• F1.33.12The system shall support running Postprocessors on the the mesh containing displacements:
  1. elemental and
  2. side.
• F1.33.13The system shall contain a "Postprocessor" that computes the average value of a variable
  1. one a single block and
  2. on multiple blocks.
• F1.33.14The system shall compute the the extreme (min/max) values of an elemental field variable over the domain.
• F1.33.15The system shall compute the H1-seminorm between a field variable and a analytical function.
• F1.33.16The system shall compute the element integral of a variable
  1. over the whole domain and
  2. over a subset of the domain.
• F1.33.17The system shall compute the average integral quantity over an element of a scalar material property.
• F1.33.18The system shall support computing the integral of a variable quantity over the domain on the mesh
  1. during the initial setup step and
  2. at the end of each time step.
• F1.33.19The system shall compute the element-wise L2 difference between two field variables.
• F1.33.20The system shall compute the L2-error (Euclidean) between a field variable and a analytical function.
• F1.33.21The system shall compute the volumetric L2 norm of a variable over the mesh.
• F1.33.22The system shall compute the average time derivative of a solution value computed per element in 2D.
• F1.33.23The system shall compute the average time derivative of a solution value computed per element in 1D.
• F1.33.24The system shall support sampling a specific quantity integrated over a single element.
• F1.33.25The system shall compute the Vector L2 Error of three scalar variables simultaneously as three orthogonal components of a vector.
• F1.33.26Postprocessor objects shall be able to execute and output after the simulation is complete.
• F1.33.27The system shall support an attribute (scalar value) reporter through the "Execution" system.
• F1.33.28The system shall be capable of find a value on a monotonically changing line.
• F1.33.29The system shall report and error when the target value is lower than one of the sampled endpoints.
• F1.33.30The system shall report and error when the target value is greater than one of the sampled endpoints.
• F1.33.31The system shall report and error when the sampling line extends beyond the mesh bounding box.
• F1.33.32The system shall report and error when the line sampling algorithm fails to converge within the desired depth.
• F1.33.33The system shall integrate functions over volume.
• F1.33.34The system shall compute the integral of a function over a boundary.
• F1.33.35The system shall support evaluating a function of space and time at a single point as a Postprocessor value.
• F1.33.36Testing the implementation of the InterfaceIntegralVariableValuePostprocessorBy 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 (master minus slave) of 6, a singed material propertyjump (slave minus master) of -6, a material property value on the master side of 10, a material property value on the master side of 4
• F1.33.37Testing the implementation of the InterfaceIntegralVariableValuePostprocessorBy design at the end of the first step we should observe: an intergal material property of 21, an intergal material property absolute jump fo 18,a singed intergal material property jump (master minus slave) of 18, a singed intergal material propertyjump (slave minus master) of -18, a material intergal property value on the master side of 30, a material intergal property value on the master side of 12
• F1.33.38The system shall support retrieving solution values from neighboring elements for use in internal side calculations.
• F1.33.39The system shall support the ability to compute a linear combination of scalar values (Postprocessors).
• F1.33.40The system shall allow a mix of postprocessor names and real numbers to be provided to PostprocessorName parameters.
• F1.33.41MOOSE 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
• F1.33.42MOOSE 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
• F1.33.43The system shall verify calculations using the method of manufactured solutions using a higher order polynomial function for linear elements.
• F1.33.44The 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.
• F1.33.45The system shall verify calculations using the method of manufactured solutions using a functional form of an equation outside of the shape function space.
• F1.33.46The system shall compute the the extreme (min/max) values of a nodal field variable over the domain.
• F1.33.47The system shall compute the maximum value of a field variable by sampling nodes
  1. over the whole domain and
  2. within a subdomain.
• F1.33.48The 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.
• F1.33.49The system shall report the value of a variable at a specified node
  1. for auxiliary variables and
  2. for primary (nonlinear) variables.
• F1.33.50The system shall support selecting the output for a single Postprocessor
  1. to a file and
  2. to the console.
• F1.33.51The system shall be capable of running multiple adaptivity cycles in a single solve step.
• F1.33.52They system shall be capable of toggling adaptivity at the start of the simulation.
• F1.33.53They system shall be capable of toggling adaptivity during the simulation.
• F1.33.54The NumDOFs Postprocessor shall report the number of degrees of freedom (DOFS) from one or more equations systems in the simulation.
• F1.33.55The NumElems Postprocessor shall report the number of elements (active or total) in the simulation.
• F1.33.56The NumElems Postprocessor shall report the number of elements (active or total) in the simulation when using distributed (pre-split) mesh.
• F1.33.57The 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. four stage, L-stable DIRK;
  15. four stage, L-stable DIRK;
  16. and Ralston methods.
• F1.33.58The NumNodes Postprocessor shall report the number of nodes (replicated or distributed) in the simulation.
• F1.33.59The NumNodes Postprocessor shall report the number of nodes in the simulation when using distributed (pre-split) mesh.
• F1.33.60The system shall be capable of outputting the number of Residual evaluations
• F1.33.61The NumVars Postprocessor shall report the number of variables from one or more equation systems in the simulation.
• F1.33.62The 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).
• F1.33.63The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors.
• F1.33.64The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors while maintaining vector history.
• F1.33.65MOOSE shall have the abililty to pull time from the PerfGrahp into a Postprocessor
• F1.33.66The system shall support the ability to sample a field variable value anywhere within the domain.
• F1.33.67The system shall report an error when a field variable sample location is outside of the domain.
• F1.33.68The 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.
• F1.33.69The system shall support evaluating Postprocessors (UserObjects) in the following order: Elemental, Side, Internal Side, Nodal, and General.
• F1.33.70The system shall support outputting the scalar Postprocessor values at specific intervals
  1. to a file and
  2. to the console.
• F1.33.71The system shall support outputting the scalar Postprocessor values to multiple locations with different intervals.
• F1.33.72The system shall have the ability to output performance data to a file.
• F1.33.73The system shall calculate performance time when the data is only used by a Postprocessor.
• F1.33.74The system shall calculate performance time even when the performance graph isn't printed to any output format.
• F1.33.75The 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.
• F1.33.76The system shall support the ability to report an input parameter on the screen or to an input file.
• F1.33.77The system shall report an error when a requested parameter for reporting does not exist.
• F1.33.78The 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.
• F1.33.79The 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.
• F1.33.80The system shall be capable of computing the relative norm of the solution difference between two consecutive time steps.
• F1.33.81The system shall support coupling in a scalar variable to the Postprocessing system for calculating values.
• F1.33.82The system shall support reporting scalar variables as Postprocessor (scalar output) values.
• F1.33.83The system shall support the scaling of a post processor quantity by another post processor quantity.
• F1.33.84The system shall compute the area-weighted average of the integral of a variable over a side.
• F1.33.85The system shall be capable of computing the average of the integral through a specified boundary on the mesh.
• F1.33.86The system shall support computing the integral of a variable quantity over a side on the mesh.
• F1.33.87The system shall compute an aggregate scalar quantity when applied along multiple boundaries.
• F1.33.88The TableOutput object shall allow the user to override tolerance checks when determining whether new rows should be added (independent variable delta)
• F1.33.89The system shall have the ability to record a minimum or maximum value of a field variable over time.
• F1.33.90The system shall include the ability to compute the inner product of two variables.
• F1.33.91The system shall compute the difference between the test and trial functions (Residual) for a specified variable.
• F1.33.92Vector 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.
• F1.33.93The system shall have the capability of computing the volume of the mesh domain.

• framework: Preconditioners
• F1.34.1The system shall support the disabling of an automatically created preconditioning object when preforming a Newton solve.
• F1.34.2The system shall automatically create the correct preconditioning object when preforming a Newton solve.
• F1.34.3The system shall not automatically create a preconditioning object when preforming a Newton solve if the auto preconditioning capability is disabled.
• F1.34.4The system shall produce a perfect coloring for the Jacobian when using the finite difference preconditioner.
• F1.34.5The system shall produce a perfect Jacobian when using the stadard finite difference preconditioner.
• F1.34.6The system shall detect missing off-diagonal Jacobian entries when using a full finite different preconditioner.
• F1.34.7The system shall support the use of field split preconditioner on
  1. a single subdomain and
  2. multiple subdomains.
• F1.34.8The system shall support the ability to use multiple cycles within hypre during preconditioning with PETSc.
• F1.34.9The system shall support the use of a physics based preconditioner
  1. without and
  2. with mesh adaptivity.
• F1.34.10The system shall support the ability to add arbitrary options to the solver when using a physics based precondioner.
• F1.34.11The system shall support the ability to control the variable solve order when using a physics base preconditioner.
• F1.34.12The system shall support the ability to use the conjugate gradient method for preconditioning with PETSc.
• F1.34.13The system shall support the use of a single matrix preconditioner
  1. without and
  2. with mesh adaptivity.
• F1.34.14The system shall support the ability to group variables when using a single matrix preconditioner.

• framework: Predictors
• F1.35.1The system shall include a means for predicting future solution based on previous solutions.
• F1.35.2The system shall include a means for predicting future solution based on previous solutions and print the scale factor to the output stream.
• F1.35.3The system shall support the ability to skip performing solution predictions
  1. using solution times or
  2. previous solution times.

• framework: Problems
• F1.36.1The system shall allow the creation of a custom problem through a user-defined Action.
• F1.36.2The system shall support the creation of a custom problem with parameters in Problem block.
• F1.36.3The system shall error out when Problem block type is not specified.
• F1.36.4The system shall support the creation of a custom problem through Problem block with type specified.
• F1.36.5The system shall support the ability to extend the basic "Problem" interface.
• F1.36.6MOOSE shall have a capability to dump the equivalent input file syntax for all objects added by a given action.
• F1.36.7Eigenvalue system should support standard eigenvalue problems
• F1.36.8Eigenvalue system should support generalized eigenvalue problems
• F1.36.9Eigenvalue system should support IntegratedBC
• F1.36.10Eigenvalue system should not allow users to use inhomogeneous nodal boundary conditions
• F1.36.11Eigenvalue system should use homogeneous boundary conditions only
• F1.36.12Eigenvalue system requires SLEPc installed
• F1.36.13Eigenvalue system should be able to solve a nonlinear eigenvalue problem
• F1.36.14Eigenvalue system should be able to solve a nonlinear eigenvalue problem using Newton
• F1.36.15Eigenvalue system should be able to solve a deficient eigenvalue problem
• F1.36.16Eigenvalue system should be able to compute a nonlinear eigenvalue problem
• F1.36.17Eigenvalue system should be able to compute a coupled nonlinear eigenvalue problem
• F1.36.18Eigenvalue system should be able to handle scalar kernels
• F1.36.19Eigenvalue system should be able to handle DG kernels
• F1.36.20Eigenvalue system shall support Picard iteration using eigenvalue executioner as a master
• F1.36.21Eigenvalue system shall support Picard iteration using eigenvalue executioner as a sub app
• F1.36.22Eigenvalue system should be able scale eigenvector such that postprocessor is a certain value
• F1.36.23MOOSE shall support an code coupling interface that can trigger external solves.
• F1.36.24MOOSE shall support an code coupling interface that can trigger external solves for transient simulations.
• F1.36.25The system shall support different coordinate systems on different subdomains within the mesh.
• F1.36.26The system shall support the ability to disable the check for PDE operators in all or some parts of the domain.
• F1.36.27The system shall support the ability to disable the check for active materials in all parts of the domain.
• F1.36.28The system shall have the ability to disable the actual nonlinear system solve in a simulation.
• F1.36.29The system shall have the ability to base convergence on the comparison of individual variables to reference quantities of those variables.
• F1.36.30The system shall fail to find a converged solution when basing convergence on individual variable reference quantities with poor scaling.
• F1.36.31The system shall have the ability to automatically scale a originally poorly scaled problem and achieve convergence based on individual reference quantities

• framework: Quadrature
• F1.37.1The system shall support the use of Gauss-Lobatto quadrature for numerical integration.
• F1.37.2The system shall support the ability to manually increase the quadrature order used for numerical integration.
• F1.37.3The system shall support the ability to control the volumetric and side quadrature orders used for numerical integration.

• framework: Relationship Managers
• F1.38.1The CouplingFunctorCheckAction shall add a default coupling functor if it's needed and hasn't already been added by another Action
• F1.38.2The system shall indicate when libMesh Ghosting Functors are in use.
• F1.38.3MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager
• F1.38.4MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager and using DistributedMesh
• F1.38.5MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh
• F1.38.6MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh with 3D
• F1.38.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
• F1.38.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
• F1.38.9MOOSE shall allow multiple active RelationshipManagers to manage ghosting for the same object
• F1.38.10MOOSE shall allow multiple active RelationshipManagers to manage ghosting for the same object

• framework: Restart
• F1.39.1The system shall support reading and writing solutions on meshes containing duplicate or overlapping mesh nodes.
• F1.39.2The system shall support the ability to
  1. perform residual calculations that accumulate state and
  2. restart the calculation using the accumulated state.
• F1.39.3The system shall support the ability to
  1. to name problem objects in a simulation and
  2. restart the calculation using the defined name.
• F1.39.4The system shall error when
  1. a simulation is started with multiple processors but
  2. restarted with a different number processors.
• F1.39.5The system shall error when
  1. a simulation is started with multiple threads but
  2. restarted with a different number threads.
• F1.39.6The system shall support running a transient test for the purposed of changing a restart time step size.
• F1.39.7The system shall support changing the time step size during a recover operation.
• F1.39.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.
• F1.39.9The system shall store a custom type that contains a data serialization routine that is declared as restartable.
• F1.39.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.
• F1.39.11The systen shall support running and saving off a transient solution with stateful material properties for a restart test.
• F1.39.12The systen shall support restart with a solution containing only a subset of the variables in the restart simulation.
• F1.39.13The system shall support outputting a mesh with refinement to Exodus format for restart testing.
• F1.39.14The system shall support reading solution information from an Exodus file.
• F1.39.15The system shall support reading solution information from an Exodus file with initial uniform refinement.
• F1.39.16The system shall support outputting a mesh to checkpoint format for restart testing.
• F1.39.17The system shall support starting a transient simulation from a steady simulation result.
• F1.39.18The system shall support renaming a variable read from a solution file upon restart.
• F1.39.19The system shall support writting out several timesteps to a solution file to test reading from a specific point.
• F1.39.20The system shall support restarting from the last timestep using the keyword "LATEST".
• F1.39.21The system shall issue a useful error message stating the valid options when a user requests an invalid time step number or keyword.
• F1.39.22The system shall support running and saving off a transient solution for using in a steady state restart.
• F1.39.23The system shall support restarting a steady state solve from a transient simulation solution.
• F1.39.24The system shall support solving a transient problem as a reference solution for a two part multiapp solve.
• F1.39.25The system shall support writing out checkpoint directly from a subapp, a subtree of the multiapp tree of the master solve.
• F1.39.26The system shall support restarting a subapp, a subtree of the multiapp tree of a master solve without restarting the master application.
• F1.39.27The system shall support outputting a mesh with refinement to Exodus format for restart testing.
• F1.39.28The system shall support restarting a transient simulation from a steady solution file.
• F1.39.29The system shall support outputting a mesh with refinement to checkpoint files for restart testing with sub apps.
• F1.39.30The system shall support restarting a transient simulation from a steady solution file with sub apps.
• F1.39.31The 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.
• F1.39.32The system shall be capable, in parallel, of
  1. writing data to a restart file
  2. and restarting the simulation from the restart file.
• F1.39.33The system shall support outputting a mesh to checkpoint format for restart testing with "start_time".
• F1.39.34The system shall use the the final time as the "start_time" from the restart file.
• F1.39.35The system shall support resetting "start_time" when restarting from a checkpoint mesh format.
• F1.39.36The system shall support overriding "start_time" when restarting from a checkpoint mesh format to an arbitrary time.

• framework: Restrictable
• F1.40.1The system shall include an interface to allow objects to be restricted to subdomains.
• F1.40.2The system shall error if an object is restricted to a set of subdomains that differs from a dependant object.
• F1.40.3The 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.
• F1.40.4The 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.
• F1.40.5The 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.
• F1.40.6The 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.
• F1.40.7The 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.
• F1.40.8The 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.
• F1.40.9The 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.
• F1.40.10The system shall support the ability to restrict user defined calculations to sides of a subdomain.
• F1.40.11The system shall issue an error when a referenced subdomain does not exist in the mesh.

• framework: Samplers
• F1.41.1The 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.
• F1.41.2The 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.
• F1.41.3The system shall include a random number sampling system that errors
  1. if the number of rows is set after object construction,
  2. if the number of cols is set after object construction,
  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.
• F1.41.4The 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
• F1.42.1We shall be able to couple a scalar variable into AD objects and do some meaningful physics: depleting boundary source diffusion problem
• F1.42.2We shall be able to couple a scalar variable into AD objects and get the correct Jacobian

• framework: Tag
• F1.43.1The 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.
• F1.43.2The 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, and
  6. the nodal kernel system.

• framework: Time Integrators
• F1.44.1The system shall include an option that aborts the solve immediately if a solve fails.
• F1.44.2The 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.
• F1.44.3The 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.
• F1.44.4The 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;
• F1.44.5The system shall correctly solve a time dependent ordinary differential equation using an explicit first-order, forward Euler scheme.
• F1.44.6The system shall support the use of the Adams Bashforth predictor for time integration.
• F1.44.7The system shall support the second-order backward difference method for time integration
  1. with and
  2. without mesh adaptivity.
• F1.44.8The 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.
• F1.44.9The 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.
• F1.44.10The 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.
• F1.44.11The 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.
• F1.44.12The 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.
• F1.44.13The 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.
• F1.44.14The 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.
• F1.44.15The 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.
• F1.44.16The 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.
• F1.44.17The system shall support the second-order Crank-Nicolson method for time integration
  1. with and
  2. without mesh adaptivity.
• F1.44.18The system shall support the L-stable DIRK method for time integration
  1. with and
  2. without mesh adaptivity.
• F1.44.19The 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.
• F1.44.20The system shall include the strong-stability-preserving Runge-Kutta method of
  1. 1st order
  2. 2nd order
  3. 3rd order
• F1.44.21The system shall support the use of an implicit Euler solver with
  1. with and
  2. without mesh adaptivity.
• F1.44.22The system shall support the use of an implicit Euler solver with discontinuous (first-order Monomial) shape functions.
• F1.44.23Multi-stage time integrators shall check convergence for all stages
• F1.44.24The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using the default beta and gamma parameters.
• F1.44.25The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using user provided beta and gamma parameters.
• F1.44.26The 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.
• F1.44.27The 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.
• F1.44.28The 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.
• F1.44.29The 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.
• F1.44.30The 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
• F1.45.1The 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.
• F1.45.2The system shall include a means for performing simulations with a constant time step.
• F1.45.3The system shall support the ability to regrow a time step that has been previously cut due to a solve failure.
• F1.45.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.
• F1.45.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.
• F1.45.6The system shall include an adaptive, error-estimate based multi-step time step calculation scheme.
• F1.45.7The system shall suppport the ability to sample a piecewise linear function for time step sizes while supporting a minimum time step size.
• F1.45.8The 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.
• F1.45.9MOOSE shall support the ability to force time steps consistent with points specified in a function.
• F1.45.10MOOSE shall check that a timestep limiting function has been defined when a user specifies the 'force_step_every_function_point' parameter as true.
• F1.45.11MOOSE shall check that a timestep limiting function has been defined when a user specifies a value for the 'max_function_change' parameter.
• F1.45.12MOOSE shall support the ability to grow the time step size when specifying the initial value of dt in the TimeStepper.
• F1.45.13MOOSE shall support the ability to grow the time step size when specifying the initial value of dt in the TimeStepper after a restart.
• F1.45.14MOOSE shall support the ability to grow the time step size when specifying the values of t and dt in the TimeStepper.
• F1.45.15MOOSE shall support the ability to grow the time step size when specifying the values of t and dt in the TimeStepper after a restart.
• F1.45.16MOOSE shall support the ability to limit the time step size based on the optimal iterations and linear_iteration ratio.
• F1.45.17MOOSE shall support the ability to limit the time step size based on the optimal iterations and linear_iteration ratio after a restart.
• F1.45.18MOOSE shall support the ability to limit the time step size based on a postprocessor value.
• F1.45.19MOOSE 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.
• F1.45.20MOOSE shall support the ability to force time steps to resolve sudden changes in piecewise linear functions.
• F1.45.21The system shall support the ability to select a time step size based upon a scaled log-constant calculation.
• F1.45.22The system shall support the ability to use a scalar value computed after a solve to be used as a scaled time step size.
• F1.45.23The 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.
• F1.45.24The 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.
• F1.45.25The system shall support the ability to override time sequence time step sizes when solves fail.
• F1.45.26The 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.
• F1.45.27The 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.
• F1.45.28The system shall report an error if the initial time step size is calculated to be zero.

• framework: Transfers
• F1.46.1The system shall support the transfer of data from a completed solve within sub-application to the master application.
• F1.46.2The system shall include an interface for retrieving objects that pertain to transferring data between applications.
• F1.46.3The system shall support conservative transfers
• F1.46.4The system shall support conservative transfers using regular postprocessors
• F1.46.5The system shall support conservative transfers with nearestpoint VectorPostprocessors
• F1.46.6The system shall be able to output the adjusting values in conservative transfers
• F1.46.7The system shall support conservative transfers in MultiAppUserObjectTransfer
• F1.46.8The system shall be able to output the adjusting values in conservative transfers for MultiAppUserObjectTransfer
• F1.46.9The system shall support direct copy of array variables from a sub-application to the main application.
• F1.46.10The system shall support the transfer of auxiliary field variables between identical meshes:
  1. from a sub-application and
  2. to a sub-application.
• F1.46.11The 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.
• F1.46.12The 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.
• F1.46.13The 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.
• F1.46.14The system shall error when the MultiAppCopyTransfer object is used on non-identical meshes.
• F1.46.15The system shall error when the MultiAppCopyTransfer object is used on meshes with different variable types.
• F1.46.16The system shall support direct copy of a linear Lagrange nonlinear variable from a sub-application to the main application.
• F1.46.17The system shall support direct copy of a linear Lagrange nonlinear variable to a sub-application from the main application.
• F1.46.18The system shall support direct copy of multiple nonlinear variables from a sub-application to the main application.
• F1.46.19The system shall support direct copy of a second-order Lagrange nonlinear variable from a sub-application to the main application.
• F1.46.20The system shall support direct copy of a second-order Lagrange nonlinear variable to a sub-application from the main application.
• F1.46.21The 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.
• F1.46.22The 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.
• F1.46.23The system shall support mesh to mesh interpolation with the first order elemental variable
• F1.46.24The system shall support mesh to mesh interpolation with the first order elemental variable when a different mesh is used in sub
• F1.46.25The system shall support nearest node transfer with the first order elemental variable
• F1.46.26The system shall support interpolation transfer with the first order elemental variable
• F1.46.27The system shall support user object transfer with the first order elemental variable
• F1.46.28The system shall support conservative transfer with L2 nonlinear variable
• F1.46.29The system shall allow to interpolate variables from the master app to the sub apps
• F1.46.30The system shall allow to interpolate variables from the sub apps to the master app
• F1.46.31The system shall allow to interpolate block restricted variables from the sub apps to the master app
• F1.46.32The 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.
• F1.46.33The 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.
• F1.46.34The system shall transfer both nodal and elemental fields to a SubApp from the Master App.
• F1.46.35The system shall transfer both nodal and elemental fields from SubApps to the Master App.
• F1.46.36The system shall transfer values from SubApps which set the displaced_source_mesh flag to true.
• F1.46.37The system shall transfer values from SubApps which set the displaced_target_mesh flag to true.
• F1.46.38The system shall support the 'fixed_meshes' flag which allows caching of nearest neighbors.
• F1.46.39The system shall transfer values to multiple SubApps from the Master App's boundary.
• F1.46.40The system shall transfer values from a SubApp boundary to the Master App.
• F1.46.41The system shall work when there are multiple SubApps present.
• F1.46.42The system shall work in parallel between meshes with different spatial dimensions.
• F1.46.43The system shall support the transfer of scalars to a field variable between an application and sub-applications:
  1. using a inverse distance algorithm,
  2. using a radial basis algorithm,
  3. with multi-level sub-applications,
  4. with multiple sub-application files, and
  5. with a single sub-application file.
• F1.46.44The system shall report an error if a data transfer is requested for a data variable that is not defined.
• F1.46.45The 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.
• F1.46.46The 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.
• F1.46.47The 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.
• F1.46.48The system shall support the transfer of scalar post processing data from a single sub-application.
• F1.46.49The 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.
• F1.46.50The system shall support the transfer of field data using L2 projection for first order shaped monomial shape functions.
• F1.46.51The system shall support the transfer of field data using L2 projection and include optimization for non deforming meshes.
• F1.46.52The system shall include the ability to transfer scalar variables to an applications from sub-applications.
• F1.46.53The system shall error if the variable order does not match when transferring scalar variables to an application from sub-applications.
• F1.46.54The system shall include the ability to transfer scalar variables from an applications to sub-applications.
• F1.46.55The system shall error if the variable order does not match when transferring scalar variables from an application to sub-applications.
• F1.46.56The 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.
• F1.46.57MultiAppUserObjectTransfer shall generate an error if a master node/element is not contained within any sub application domains.
• F1.46.58MultiAppUserObjectTransfer shall allow skipping the bounding box test.
• F1.46.59The 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.
• F1.46.60The 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.
• F1.46.61The system shall support the ability to disable the use of parallel barriers when streaming text to the screen.
• F1.46.62The system shall support the ability transfer vectors of post processing data between the master application and sub-applications.
• F1.46.63The system shall support support the ability to perform interpolation between time steps when transferring field data between a master application and sub-applications.
• F1.46.64The Transfer system shall support execution with the EXEC_FINAL flag.
• F1.46.65The system shall support the transfer of data between a master application and sub-applications after a sub-application as been reset.

• framework: Userobjects
• F1.47.1The system shall be able to terminate the execution of a solve based on post-processing calculations performed within the simulation.
• F1.47.2The system shall support the use of data produced by a custom user object calculations within a kernel object.
• F1.47.3The 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.
• F1.47.4The 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.
• F1.47.5The 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.
• F1.47.6Testing 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 (master-slave) of 6 a singed material propertyjump (slave-master) of -6 a material property value on the master side of 10 a material property value on the master side of 4
• F1.47.7The 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.
• F1.47.8MOOSE shall allow taking averages of variables along a coordinate axis in layers
• F1.47.9MOOSE shall allow specifying boundaries and numbers of layers for layered averages
• F1.47.10MOOSE shall allow specifying boundaries and numbers of layers for layered averages
• F1.47.11MOOSE shall allow specifying boundaries and numbers of layers for layered averages
• F1.47.12MOOSE shall allow specifying boundaries and numbers of layers for layered averages
• F1.47.13MOOSE shall allow interpolating between layers for layered averages
• F1.47.14MOOSE shall respect mesh displacements in layered average
• F1.47.15MOOSE shall respect block restriction for layered averages
• F1.47.16MOOSE shall respect block restriction for layered averages
• F1.47.17MOOSE shall respect block restriction for layered averages even when using num_layers
• F1.47.18MOOSE shall allow bounds for layered averages when using num_layers to come from a block different than the block restriction
• F1.47.19The 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.
• F1.47.20The 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.
• F1.47.21MOOSE shall correctly compute layered integrals along a specified boundary
• F1.47.22MOOSE shall allow taking averages of variables along a coordinate axis in layers on a boundary
• F1.47.23MOOSE shall allow taking averages of the flux of variables along a coordinate axis in layers on a boundary
• F1.47.24MOOSE shall not allow both the block and boundary parameter to be specified for layered side integrals
• F1.47.25The 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.
• F1.47.26The system shall compute layered averages that computed from the closest values for a list of points that are explicitly specified in an input file
• F1.47.27The system shall compute layered averages that computed from the closest values for a list of points that are specified in an external file
• F1.47.28The system shall report an error when points are not specified in an input file nor an external file when computing nearest point layered averages
• F1.47.29The system shall report an error when points are specified both in an input file and an external file when computing nearest point layered averages
• F1.47.30The 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
• F1.47.31The system shall compute layered side averages that computed from the closest values for a list of points
• F1.47.32The 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.
• F1.47.33The system shall support optionally initializing shape function data structures for use in custom algorithm (UserObject) calculations.
• F1.47.34The 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.
• F1.47.35The system shall error if the boundary is not specified when computing the average value of a variable on a boundary.
• F1.47.36The 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.
• F1.47.37The system shall be capable of reading in field information and producing gradient values from both continuous and discontinuous fields.
• F1.47.38The 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.
• F1.47.39The 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
• F1.48.1The system shall support a piecewise bilinear interpolation object to be constructed from x, y data read from an external file.
• F1.48.2The system shall support a piecewise bilinear interpolation object to be constructed from x, y data.
• F1.48.3The system shall error when a file and data are supplied simultaneously in the PiecewiseBilinear object.
• F1.48.4The system shall error when there is a mismatch in vector lengths in the PiecewiseBilinear object.
• F1.48.5The system shall error when there are insufficient parameters supplied for the PiecewiseBilinear object.
• F1.48.6The system shall provide a method for transferring common parameters from one object to another.
• F1.48.7The system shall prevent the user from copying InputParameters objects inside of MooseObject-derived objects.
• F1.48.8Moose shall have a function that evaluates the polynomial and derivative of polyonimal of varying degree and arbitrary coefficients
• F1.48.9Moose shall have a clamp function that returns a value limited to upper and lower bounds
• F1.48.10Moose shall have a smootherstep function that returns a smooth transition value between an upper and lower bound
• F1.48.11The system shall support the use of the Dennis-Schnabel method for computing the finite difference parameter for matrix free finite difference solver.
• F1.48.12The system shall include a utility for computing spline functions.
• F1.48.13The 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
• F1.49.1MOOSE shall provide an ability to add array variables with constant initial conditions.
• F1.49.2The system shall support direct calculation of field variables on multiple mesh subdomains.
• F1.49.3The 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).
• F1.49.4The system shall support the ability to use a default value when an optional scalar coupling is requested but not supplied.
• F1.49.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.
• F1.49.6The system shall support "curvilinear" elements (elements that contain curved edges.
• F1.49.7The system shall support the hierarchical family of shape functions on mesh
  1. in 1D,
  2. in 2D, and
  3. in 3D.
• F1.49.8The 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.
• F1.49.9The 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.
• F1.49.10The 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.
• F1.49.11The 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).
• F1.49.12The system shall support second and third order Monomial family of shape functions.
• F1.49.13The system shall support the ability to have mixed field variable orders on the same mesh.
• F1.49.14The system shall support the ability to have multiple independent block restricted variables in a mesh contain multiple blocks.
• F1.49.15Allow optional variable coupling where a default constant value is assumed when the user omits specifying a variable.
• F1.49.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.
• F1.49.17Simulations with second derivative variable coupling shall not crash due to access to uninitialized data structures.
• F1.49.18Coupleable shall provide an interface that allows providing default values for a vector of coupled variables
• F1.49.19Coupleable shall provide an interface that allows providing default values for a vector of coupled variables
• F1.49.20The system shall report an error when users couple constant values and variables together
• F1.49.21The system shall report an error when requested default vector value is out of range.
• F1.49.22The system shall report an error when requested default vector value is out of range.
• F1.49.23The 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.
• F1.49.24The system shall ensure that coupled second derivative calculations are only performed when requested and are only performed on the minimum required fields.
• F1.49.25The system shall compute time derivatives on a neighbor element for constant monomials

• framework: Vectorpostprocessors
• F1.50.1Line sampling shall account for floating point precision error.
• F1.50.2The system shall be able to produce arbitrary vectors of values for use in other calculations.
• F1.50.3The system shall be able to produce multiple arbitrary vectors of values for use in other calculations.
• F1.50.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.
• F1.50.5The system shall support the ability to read CSV data on only one processor and broadcast it to other ranks.
• F1.50.6The system shall error if the broadcast CSV data does not match on all ranks in a parallel job.
• F1.50.7The system shall issue an error if the CSVReader is used in a UserObjectTransfer because the former does not have any notion of "spatial" information.
• F1.50.8MOOSE shall support the computation of averages of variables over cylindrical shells.
• F1.50.9The system shall support dynamic numbers of sample points during the simulation.
• F1.50.10The system shall support dynamic numbers of sample points during the simulation with move semantics of the points vector.
• F1.50.11The 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.
• F1.50.12The 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.
• F1.50.13The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 1D mesh
• F1.50.14The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 2D mesh
• F1.50.15The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 3D mesh
• F1.50.16The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 1D mesh
• F1.50.17The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 2D mesh
• F1.50.18The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 3D mesh
• F1.50.19The system shall be able to compute a histogram of each vector of data produced by a vector data producer (VectorPostprocessor).
• F1.50.20The system shall support finding all of the elements intersected by a line:
  1. in 1D,
  2. in 2D, and
  3. in 3D.
• F1.50.21The system shall have late binding producers of vector quantities (VectorPostprocessors) that may be declared after system initialization.
• F1.50.22The 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
• F1.50.23The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a zeroth-rder polynomial with data provided by a CSVReader
• F1.50.24The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a first-rder polynomial with data provided by a CSVReader
• F1.50.25The LeastSquaresFit vectorpostprocessor shall compute a least squares fit of a second-rder polynomial with data provided by a CSVReader
• F1.50.26The LeastSquaresFit vectorpostprocessor shall generate an error if a fit for a third-order polynomial is requested and only three data points are provided
• F1.50.27The system shall support computing the least squares fit of a set of time values obtained from an aggregate operation defined by the developer.
• F1.50.28The system shall support sampling one or more spatial functions along a line with fixed sampling intervals.
• F1.50.29The system shall support the ability to sample a scalar material along an arbitrary line through the mesh domain.
• F1.50.30MOOSE shall allow to sample variables at equally spaced points for outputting.
• F1.50.31MOOSE shall allow to sample variables at equally spaced points in parallel.
• F1.50.32MOOSE shall allow to scale the line value sampler with a postprocessor.
• F1.50.33MOOSE shall allow to sample auxvariables at equally spaced points with CSV delimiter and precision setting.
• F1.50.34The system shall be able to output material properties calculated at quadrature points on user-defined elements in a comma separated format.
• F1.50.35The 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.
• F1.50.36The system shall support sampling of a field variable at every node in the domain.
• F1.50.37The system shall issue an error when a nodal sampler is used on a field that does not have values defined at the nodes.
• F1.50.38MOOSE shall provide VectorPostprocessor results to all processors as scattered data
• F1.50.39MOOSE shall provide VectorPostprocessor results to all processors as replicated data
• F1.50.40The system shall support the ability to sample field variables at user specified points.
• F1.50.41The system shall report an error when requested sample points do not fall within the mesh domain.
• F1.50.42The 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.
• F1.50.43The system shall be capable of sampling one or more field variables along a side at each quadrature point along the side.
• F1.50.44The system shall allow outputting relevant information about sidesets
• F1.50.45The system shall support computing the spherical average of a variable as a function of radius throughout the mesh domain.
• F1.50.46The system shall be capable of computing the statics of a vector of data.
• F1.50.47The system shall support the ability to output a separate comma separated value file containing time and time time information corresponding to vector Postprocessor output.
• F1.50.48The system shall be able to aggregate an arbitrary set of scalar data producers (Postprocessors) into a single vector of Postprocessors.
• F1.50.49The system shall allow support the creation of histogram or binned data of volume fractions with respect to variable values.
• F1.50.50The 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.

Performace Requirements

• P1.0

  The system will support multi-process distributed memory execution.

• P1.1

  The system will support multi-process shared memory execution.

• P1.2

  The system will support execution on Unix-based laptops.

• P1.3

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

• P1.4

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

System Interfaces

• S1.0

  The system shall support POSIX compliant systems.

• S1.1

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

• S1.2

  The system shall support POSIX pthreads''.

• S1.3

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

• S1.4

  The system shall support the OpenMP threading interface.

System Operations

System Modes and States

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

Phyisical Characteristics

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

Environmental Conditions

Not Applicable

System Security

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

Information Management

The core framework in its entirety will be made publicly available on an appropriate repository hosting site. Backups and security services will be provided by the hosting service. !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.