MOOSE System Requirements Specification

Introduction

System Purpose

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

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

System Scope

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

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

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

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

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

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

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

System Overview

System Context

error:Missing Template Item: "system-context"help_outline

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

System Functions

error:Missing Template Item: "system-functions"help_outline

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

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

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

Example

Use Case: Submit Timesheet

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

Initial Step-By-Step Description:

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

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

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

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

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

User Characteristics

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

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

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

Assumptions and Dependencies

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

References

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

Definitions and Acronyms

Definitions

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

Acronyms

AcronymDescription
MOOSEMultiphysics Object Oriented Simulation Environment
LGPLGNU Library General Public License
FEMFinite Element Method
INLIdaho National Laboratory
POSIXPortable Operating System Interface
PDEpartial differential equation
PDEspartial differential equations
JFNKJacobian-Free Newton-Krylov

System Requirements

under construction

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

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

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

  • 100 GB disk space

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

  • Python 2.6+

  • Git

Functional Requirements

  • Time Integrators
  • F1.1MOOSE shall allow efficient execution of explicit solves
  • F1.2MOOSE shall allow efficient execution of explicit solves
  • F1.3MOOSE shall allow efficient execution of explicit solves
  • F1.4MOOSE shall allow efficient execution of explicit solves
  • F1.5MOOSE shall allow efficient execution of explicit solves
  • F1.6MOOSE shall allow efficient execution of explicit solves
  • F1.7MOOSE shall allow efficient execution of explicit solves
  • F1.8Multi-stage time integrators shall check convergence for all stages
  • F1.9The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using the default beta and gamma parameters.
  • F1.10The NewmarkBeta time integrator shall correctly compute the first and second time derivatives of a variable using user provided beta and gamma parameters.
  • Dirackernels
  • F2.1MOOSE shall support the coupling of scalar aux variables for the purpose of sharing data and reporting values.
  • F2.2MOOSE shall support a constant point source implemented as a Dirac function in 2D.
  • F2.3MOOSE shall support a constant point source implemented as a Dirac function in 1D.
  • F2.4MOOSE shall support a constant point source implemented as a Dirac function in 3D.
  • F2.5The DiracKernel system shall allow for source locations to be set by a coupled UserObject.
  • F2.6MOOSE shall have the ability to set the value of point source from a function.
  • F2.7The DiracKernel system shall allow material properties to be utilized.
  • F2.8DiracKernel objects shall report an error if a material property from a previous timestep is requested.
  • F2.9DiracKernel objects shall report an error if a material property from two previous timesteps is requested.
  • F2.10The DiracKernel system shall allow for duplicate source locations to be defined.
  • F2.11DiracKernel objects shall support the computation of off diagonal Jacobian terms.
  • F2.12The DiracKernel system shall support source location caching using element ids.
  • F2.13The DiracKernel system shall report an error if a location does not correspond with the supplied element id.
  • F2.14The DiracKernel system shall support source location caching using element ids with uniform mesh refinement.
  • F2.15The DiracKernel system shall support source location caching using element ids with mesh refinement.
  • F2.16The DiracKernel system shall support source location caching using element ids with a displaced mesh.
  • Variables
  • F3.1Coupleable shall provide an interface that allows providing default values for a vector of coupled variables
  • F3.2Coupleable shall provide an interface that allows providing default values for a vector of coupled variables
  • F3.3The system shall report an error when users couple constant values and variables together
  • F3.4The system shall report an error when requested default vector value is out of range.
  • F3.5The system shall report an error when requested default vector value is out of range.
  • F3.6The system shall compute time derivatives on a neighbor element for constant monomials
  • Parser
  • F4.1The system shall output all registered objects in HIT format.
  • F4.2The system shall output all registered objects in single line format.
  • Misc
  • F5.1The compiled application shall be capable of returning the name used for registering objects.
  • F5.2The system shall report an error if users try to get nodal values of non-nodal variables.
  • F5.3The system shall report an error if users try to get old nodal values of non-nodal variables.
  • F5.4The system shall report an error if users try to get older nodal values of non-nodal variables.
  • F5.5The system shall have an integrity check that ensures an Executioner object exists in the system.
  • F5.6We shall be able the scrape the DOFMapOutput and determine when the Jacobian is slightly off
  • F5.7We shall be able the scrape the DOFMapOutput and determine when the Jacobian is questionable
  • F5.8We shall throw no errors if the off-diagonal Jacobian is wrong if we are only testing the on-diagonal Jacobian
  • F5.9A simulation shall run fine if there are no negative element Jacobians
  • F5.10A simulation shall throw an exception if there is a zero element Jacobians
  • F5.11A simulation shall throw an exception if there is a negative element Jacobians
  • F5.12The PETSc Jacobian test shall reveal nans if there are nans in the matrix
  • F5.13The maximum number of degrees of freedom for a single variable on a 1D EDGE2 elem shall be 2
  • F5.14The maximum number of degrees of freedom for a single variable on a 2D QUAD4 elem shall be 4
  • F5.15The maximum number of degrees of freedom for a single variable on a 2D QUAD9 elem shall be 9
  • F5.16The maximum number of degrees of freedom for a single variable on a 2D TRI3 elem shall be 3
  • F5.17The maximum number of degrees of freedom for a single variable on a 2D TRI6 elem shall be 6
  • F5.18The maximum number of degrees of freedom for a single variable on a 3D HEX8 elem shall be 8
  • F5.19The application executable shall report the version with the –version command line argument.
  • F5.20The application executable shall report the version with the -v command line argument.
  • Actions
  • F6.1The system shall be capable of reporting Action object dependencies.
  • F6.2The system shall be capable of reporting Action object task information.
  • F6.3The system shall be able to retrieve other Action objects from within another Action object.
  • F6.4The Action system shall allow Action objects to create other Action objects.
  • F6.5The Action system shall allow the creation of Action objects with multiple tasks.
  • F6.6The Postprocessor data shall be initialized by the SetupPostprocessorDataAction object and the PostprocessorInterface::hasPostprocessor shall return true when called with a defined postprocessor name.
  • F6.7The system PostprocessorInterface::hasPostprocessor method shall return false when called with an undefined postprocessor name.
  • Tag
  • F7.1tagging system shall be able to have vector tags
  • F7.2tagging system shall be able to have matrix tags
  • F7.3tagging system shall be able to have more than one vector tags
  • F7.4tagging system shall be able to have more than one matrix tags
  • F7.5tagging system shall support scalar kernels
  • F7.6tagging system shall support DG kernels
  • F7.7tagging system shall support integratedBCs
  • F7.8tagging system shall support interface kernels
  • F7.9tagging system shall support Dirac kernels
  • F7.10tagging system shall support nodal kernels
  • Controls
  • F8.1The MOOSE control system shall allow parameters from differing objects, with differing names to be associated and changed together.
  • F8.2The MOOSE control system shall allow parameters from objects to be assigned aliases for the purpose of changing the value.
  • F8.3The Control system shall support explicitly defined dependencies.
  • F8.4The Control system shall error if an attempt to alter a non-controllable parameter is performed.
  • F8.5The Control system shall error if multiple controllable parameters exists, but only a single parameter is expected to be controlled.
  • F8.6The Control system shall error if an unknown parameter is supplied for control.
  • F8.7The Control system shall error if a thread id greater than the number of threads available is supplied when retrieving a Control object.
  • F8.8The Control system shall error if an attempt is made to disable the Executioner.
  • F8.9The Control system shall error if an invalid control name is supplied to the Control dependency resolution procedure.
  • F8.10The Control system shall support the modification of a single parameter using the objects base class name, object name, and parameter name.
  • F8.11The Control system shall support the modification of multiple parameters using the objects base class and the parameter name.
  • F8.12The Control system shall include a means to output information regarding the controlled parameters.
  • F8.13The 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.
  • F8.14MOOSE shall include a command line flag for displaying controllable parameter information.
  • F8.15The Control system shall include a means to output information regarding the objects with controllable parameters.
  • F8.16The Control system shall allow a scalar parameter to be controlled with a function.
  • F8.17The Control system shall allow multiple scalar parameters to be controlled with a function.
  • F8.18The MOOSE control system shall be capable of restricting parameters to be controlled for specific execution flags.
  • F8.19The Control system shall allow multiple parameters to be changed by the parameter name alone using input syntax format.
  • F8.20The Control system shall allow multiple parameters to be changed given the object and parameter names using input syntax format.
  • F8.21The Control system shall allow for a single parameter to be changes given the input syntax, object name, and parameter name.
  • F8.22The Control system shall allow for multiple parameters to be changed given input syntax and a parameter name.
  • F8.23The Control system shall allow multiple parameters to be changed by the parameter name alone using a tag.
  • F8.24The Control system shall allow multiple parameters to be changed given a tag and parameter names, given a tag assigned across input blocks.
  • F8.25The 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.
  • F8.26The 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.
  • F8.27The Control system shall be capable of activating or deactivating AuxKernel objects with time.
  • F8.28The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given identical start end times.
  • F8.29The Control system shall be capable of activating or deactivating AuxScalarKernel objects with time, given differing start end times.
  • F8.30The Control system shall be capable of activating or deactivating NodalBC objects with time.
  • F8.31The Control system shall be capable of activating or deactivating IntegratedBC objects with time.
  • F8.32The Control system shall be capable of activating and deactivating NodalBC objects with time within a single TimePeriod block.
  • F8.33The Control system shall be capable of activating or deactivating Constraint objects with time.
  • F8.34MOOSE shall support the disabling an object using an input parameter.
  • F8.35MOOSE shall support the enabling an object using an input parameter.
  • F8.36The Control system shall be capable of activating or deactivating Damper objects with time.
  • F8.37The Control system shall be capable of activating or deactivating DGKernel objects with time.
  • F8.38The Control system shall be capable of activating or deactivating DiracKernel objects with time.
  • F8.39The TimePeriod object shall error when used with a steady state problem.
  • F8.40The TimePeriod object shall error when the start and end time parameters are not the same length.
  • F8.41The TimePeriod object shall error when start and end time parameters differ in length than the supplied object list.
  • F8.42The TimePeriod object shall error when a list of objects to control is omitted.
  • F8.43The TimePeriod object shall error when start time is greater than the end time.
  • F8.44The Control system shall be capable of activating or deactivating Kernel objects with time.
  • F8.45The Control system shall be capable of activating or deactivating MultiApp objects with time.
  • F8.46The Control system shall be capable of activating or deactivating NodalKernel objects with time.
  • F8.47The Control system shall be capable of activating or deactivating Transfer objects with time.
  • F8.48The Control system shall be capable of activating or deactivating UserObject objects with time.
  • Adaptivity
  • F9.1The Adaptivity system shall allow for multiple mesh adaptivity steps per timestep.
  • F9.2The Adaptivity system shall support mesh adaptivity during initial setup.
  • F9.3The Adaptivity system shall support marking elements for refinement during initial setup using a different marker than used during execution.
  • F9.4The Adaptivity system shall be capable of restricting the element refinement level.
  • F9.5The Adaptivity system shall allow for Marker objects to be recomputed with each adaptivity cycle.
  • Geomsearch
  • F10.1MOOSE shall be capable of computing the distance between two disjoint boundaries on a 1D domain.
  • F10.2MOOSE shall be capable of computing the distance as well as transfer data between interior boundaries on a 2D domain.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.27The 'geomsearch/2d_moving_penetration/restart' shall create the necessary files for testing restart of the PenetrationAux object.
  • F10.28The PenetrationAux object shall be capable of restarting from a previous simulation.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.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.
  • F10.45The 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.
  • F10.46The 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.
  • F10.47The NearestNodeDistanceAux object shall be capable of computing the shortest distance between a boundary and subdomain.
  • F10.48The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries.
  • F10.49The NearestNodeDistanceAux shall be capable of computing the shortest distance between two boundaries with adaptivity.
  • F10.50MOOSE shall support a means for updating the geometric search patch dynamically that may be disabled.
  • F10.51MOOSE shall support a means for updating the geometric search patch dynamically that automatically determines when an update to the patch shall occur.
  • F10.52MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each solve.
  • F10.53MOOSE shall support a means for updating the geometric search patch dynamically that updates the patch prior to each iteration.
  • F10.54The MOOSE penetration locator system shall error if penetration is not detected.
  • F10.55The PenetrationAux object shall compute the distance between two boundaries in 3D that overlap.
  • F10.56The PenetrationAux object shall compute, in parallel, the distance between two boundaries in 3D that overlap.
  • F10.57The NearestNodeDistanceAux object shall compute the shortest distance between nodes on two overlapping boundaries using a constant monomial auxiliary variable.
  • F10.58The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable.
  • F10.59The PenetrationAux object shall compute the distance between two overlapping boundaries using a constant monomial auxiliary variable in 1D.
  • Meshgenerators
  • F11.1The system shall support automatic addition of sidesets based on outward facing normals of the mesh.
  • F11.2The system shall group automatically added sidesets when multiple surfaces share the same outward facing normal.
  • F11.3MOOSE shall generate a mesh based on elements.
  • F11.4MOOSE shall be able to create different subdomains.
  • F11.5MOOSE shall be able to use the BoundingBox class.
  • F11.6MOOSE shall be able to crate different subdomains
  • F11.7MOOSE shall be able to crate different subdomains
  • F11.8MOOSE shall be able to create separate blocks in a mesh.
  • F11.9MOOSE shall be able to create separate blocks in a mesh.
  • F11.10MOOSE shall be able to create separate blocks in a mesh.
  • F11.11MOOSE shall be able to create separate blocks in a mesh.
  • F11.12MOOSE shall be able to create separate blocks in a mesh.
  • F11.13MOOSE shall be able to create separate blocks in a mesh.
  • F11.14MOOSE shall generate an non-uniform mesh on a Cartesian domain.
  • F11.15MOOSE shall generate an non-uniform mesh on a Cartesian domain.
  • F11.16MOOSE shall generate an non-uniform mesh on a Cartesian domain.
  • F11.17
  • F11.18
  • F11.19
  • F11.20
  • F11.21
  • F11.22
  • F11.23MOOSE shall be able to create a mesh based on elements.
  • F11.24The MeshGenerator system shall work with displaced mesh
  • F11.25blockMOOSE shall be able to use libmesh mesh generation tools.
  • F11.26MOOSE shall be able to create a mesh based on elements.
  • F11.27MOOSE shall be able to create a mesh based on elements.
  • F11.28MOOSE shall be able to create different subdomains.
  • F11.29MOOSE shall be able to create nodesets.
  • F11.30MOOSE shall be able to read in a file.
  • F11.31MOOSE shall be able to use the BoundingBox class.
  • F11.32MOOSE shall be able to use the BoundingBox class.
  • F11.33MOOSE shall be able to create different subdomains.
  • F11.34MOOSE shall be able to create different subdomains.
  • F11.35MOOSE shall be able to create different subdomains.
  • F11.36MOOSE shall be able to create nodesets.
  • F11.37MOOSE shall be able to create nodesets.
  • F11.38MOOSE shall be able to use the BoundingBox class.
  • F11.39MOOSE shall be able to use the BoundingBox class.
  • F11.40MOOSE shall be able to use the BoundingBox class.
  • F11.41MOOSE shall be able to use the BoundingBox class.
  • F11.42MOOSE shall be able to use the BoundingBox class.
  • F11.43MOOSE shall be able to use the BoundingBox class.
  • F11.44MOOSE shall be able to use the BoundingBox class.
  • F11.45MOOSE shall be able to use libmesh/fe_base.h.
  • F11.46MOOSE shall be able to create different subdomains.
  • F11.47MOOSE shall be able to use libmesh mesh generation tools.
  • F11.48
  • F11.49
  • F11.50
  • F11.51MOOSE shall be able to read in an image.
  • F11.52MOOSE shall be able to read in an image.
  • F11.53MOOSE shall be able to read in an image.
  • F11.54MOOSE shall be able to create different subdomains.
  • F11.55MOOSE shall be able to use libmesh mesh modification tools.
  • F11.56MOOSE shall be able to use libmesh mesh modification tools.
  • F11.57MOOSE shall be able to use libmesh mesh modification tools.
  • F11.58MOOSE shall be able to use libmesh mesh modification tools.
  • F11.59MOOSE shall be able to use libmesh mesh modification tools.
  • F11.60MOOSE shall be able to create sidesets.
  • F11.61
  • F11.62
  • F11.63
  • F11.64MOOSE shall be able to create sidesets.
  • F11.65MOOSE shall be able to create different subdomains.
  • F11.66MOOSE shall be able to create meshes.
  • F11.67MOOSE shall be able to crate different subdomains.
  • F11.68MOOSE shall be able to crate different subdomains.
  • F11.69MOOSE shall be able to rename boundary ids and names.
  • F11.70MOOSE shall be able to create meshes.
  • F11.71MOOSE shall be able to create sidesets.
  • F11.72MOOSE shall be able to create sidesets.
  • F11.73MOOSE shall be able to create sidesets.
  • F11.74MOOSE shall be able to create sidesets.
  • F11.75MOOSE shall be able to create sidesets.
  • F11.76MOOSE shall be able to create sidesets.
  • F11.77MOOSE shall be able to create sidesets.
  • F11.78MOOSE shall be able to use the BoundingBox class.
  • F11.79MOOSE shall be able to use the BoundingBox class.
  • F11.80MOOSE shall be able to use the BoundingBox class.
  • F11.81MOOSE shall be able to use the BoundingBox class.
  • F11.82MOOSE shall be able to use the BoundingBox class.
  • F11.83MOOSE shall be able to use the BoundingBox class.
  • F11.84MOOSE shall be able to use the BoundingBox class.
  • F11.85MOOSE shall be able to use libmesh/fe_base.h.
  • F11.86MOOSE shall be able to create sidesets.
  • F11.87MOOSE shall be able to create sidesets.
  • F11.88MOOSE shall be able to create sidesets.
  • F11.89MOOSE shall be able to use libmesh mesh mdification tools.
  • F11.90MOOSE shall be able to create meshes.
  • F11.91MOOSE shall be able to generate new meshes by stacking up existing meshes.
  • F11.92MOOSE shall be able to generate new meshes by stacking up existing meshes.
  • F11.93MOOSE shall be able to generate new meshes by stacking up existing meshes.
  • F11.94MOOSE shall be able to use libmesh mesh modification tools.
  • F11.95MOOSE shall be able to use libmesh mesh modification tools.
  • F11.96MOOSE shall be able to use the BoundingBox class.
  • F11.97MOOSE shall be able to use the BoundingBox class.
  • F11.98MOOSE shall be able to use the BoundingBox class.
  • F11.99MOOSE shall be able to create different subdomains.
  • F11.100MOOSE shall be able to use libmesh mesh modification tools.
  • F11.101MOOSE shall be able to use libmesh mesh modification tools.
  • Kernels
  • F12.1MOOSE shall provide an ability to solve a 2D diffusion problem with Dirichlet boundary conditions.
  • F12.2MOOSE shall provide an ability to solve a 2D diffusion problem with Neumann boundary conditions.
  • F12.3MOOSE shall provide a diffusion kernel that obtains the diffusion coefficient from a material property
  • F12.4MOOSE shall provide an ability to solve a 2D diffusion problem including a volumetric source term.
  • F12.5MOOSE shall provide a tester that checks hand-coded Jacobian against finite difference Jacobian using -snes_type=test option.
  • F12.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.
  • F12.7MOOSE should not compute an extra residual if the linear solver is used
  • F12.8Coupled variable gradient Jacobian entries generated with AD shall be accurate
  • F12.9Coupled variable value Jacobian entries generated with AD shall be accurate
  • F12.10We shall be able to get aux variable values through adCoupledValue with the knowledge that the derivatives will always be zero
  • F12.11Getting a constant aux variable through adCoupledValue shall not destroy our Jacobian
  • F12.12Jacobian entries generated with AD for a simple diffusion problem shall be accurate
  • F12.13We shall be able to reproduce the simple_transient_diffusion results with ADTimeDerivative
  • F12.14The Jacobian from ADTimeDerivative shall be perfect
  • F12.15Jacobian entries generated with AD shall match hand-coded Jacobian entries as measured through save-in values
  • F12.16The system shall support coupling of variables with automatic differentiation and vector values.
  • F12.17The system shall support coupling to the gradient of variables with automatic differentiation and vector values.
  • F12.18The system shall support coupling of default values for variables with automatic differentiation and vector values.
  • F12.19The SMP Jacobian for a problem with a hanging-node shall be non-singular
  • F12.20The colored finite difference Jacobian for a problem with a hanging-node shall be non-singular
  • F12.21The standard finite difference Jacobian for a problem with a hanging-node shall be non-singular
  • F12.22A matrix-free operator shall be able to solve the hanging-node problem, indicating it is non-singular
  • F12.23The SMP Jacobian shall be perfect for the hanging-node problem
  • F12.24We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements
  • F12.25We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements
  • F12.26We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a cylindrical geometry
  • F12.27We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a cylindrical geometry
  • F12.28We shall automatically capture the dependence of things like JxW and grad_test on (second order) displacements for a spherical geometry
  • F12.29We shall automatically capture the dependence of things like JxW and grad_test on (first order) displacements for a spherical geometry
  • F12.30MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out.
  • F12.31MOOSE shall provide optimized kernels for residuals with the test function or its gradient factored out in the automatic differentiation system.
  • F12.32The Jacobian for the automatic differentiation problem shall be perfect
  • F12.33MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach.
  • F12.34MOOSE shall solve the constrained Neumann problem using the Lagrange multiplier approach when displacements are active.
  • F12.35MOOSE shall support the ability to set Dirichlet boundary conditions using the Lagrange multiplier approach.
  • F12.36Time kernel requires a transient executioner
  • F12.37The kernel can be only assigned to the existing vector tags in the system
  • F12.38The kernel can be only assigned to the existing matrix tags in the system
  • F12.39MOOSE shall be able to solve a curl-curl problem using NEDELEC_ONE elements
  • F12.40MOOSE shall be able to couple a vector variable into a standard kernel
  • F12.41MOOSE shall be able to assign a default value for a vector variable from the source file
  • F12.42MOOSE 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
  • F12.43MOOSE shall be able to assign a default value for a vector variable from the input file and still have the correct jacobian
  • F12.44MOOSE shall be able to solve multi-dimensional problems with LAGRANGE_VEC variables
  • F12.45MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables
  • F12.46MOOSE shall be able to solve one-dimensional problems with LAGRANGE_VEC variables and produce the correct Jacobian
  • F12.47MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and reproduce the hand-coded result
  • F12.48MOOSE shall be able to solve multi-d LAGRANGE_VEC problems with automatic differentiation and have a perfect Jacobian
  • F12.49MOOSE shall be able to couple a vector variable into a standard kernel and produced the correct Jacobian
  • F12.50MOOSE shall be able to couple a standard variable into a vector kernel. Additionally, MOOSE shall be able to calculate time derivatives of variable gradients.
  • F12.51MOOSE shall be able to compute the correct Jacobian when coupling a standard variable into a vector kernel and taking time derivatives of variable gradients.
  • F12.521) MOOSE shall be able to asign 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
  • Functions
  • F13.1The Function system shall include a constant function.
  • F13.2The Function system shall include the ability to set default values for input parameters expecting a function name.
  • F13.3The Function system shall include the ability to read comma or space separated data and perform linear interpolation using the supplied data.
  • F13.4MOOSE shall include an InitialCondition object capable of setting values base on a supplied function.
  • F13.5The Function object shall include a callback executed during each timestep.
  • F13.6The Material system shall support defining properties within the input file that are associated with functions.
  • F13.7MOOSE shall include the ability to define a function based on a 2D image and initialize a nodal variable.
  • F13.8MOOSE shall include the ability to define a function based on a 2D image and initialize a elemental variable.
  • F13.9MOOSE shall include the ability to define a function based on a stack of images and initialize a nodal variable.
  • F13.10MOOSE shall include the ability to define a function based on a subset stack of images and initialize a nodal variable.
  • F13.11The ImageFunction object shall allow the image data to be set as one of two values based on a threshold value.
  • F13.12MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data.
  • F13.13MOOSE shall be capable of initializing a variable from image data and perform initial adaptivity based on the data, in parallel.
  • F13.14MOOSE 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.
  • F13.15The ImageFunction object shall be capable of limiting the supplied data to a single component of the RGB image data.
  • F13.16The ImageFunction object shall be capable of shifting and scaling the supplied data.
  • F13.17The ImageFunction object shall be capable of operating on domains that are larger than the image size.
  • F13.18The ImageFunction object shall be capable of flipping the data along the vertical axis.
  • F13.19The ImageFunction object shall be capable of flipping the data along vertical axis and shifting the origin.
  • F13.20The ImageFunction object shall be capable of flipping the data along vertical and horizontal axis.
  • F13.21The ImageFunction object shall be capable of operating on domains that are smaller than the image size.
  • F13.22The ImageMesh object shall be capable of generating a 3D mesh based on a stack of 2D images.
  • F13.23The ImageMesh object shall be capable of generating a 2D mesh based on an image.
  • The ImageFunction shift and scale options shall operate independently.
  • F13.25The LinearCombinationFunction shall report an error if the parameters listing the functions differs in size than the list of coefficients.
  • F13.26The LinearCombinationFunction shall be capable of computing the sum of function values, each multiplied by a scale factor.
  • F13.27The LinearCombinationFunction shall be capable of computing the sum of function gradients, each multiplied by a scale factor.
  • F13.28The LinearCombinationFunction shall be capable of computing the sum of vector functions, each multiplied by a scale factor.
  • F13.29The Function system shall support the creation of objects that execute a function defined within the input file.
  • F13.30The ParsedFunction object shall be capable of defining function within the input file for use with the method of manufactured solutions.
  • F13.31The Function system shall support the creation of objects that execute a vector function defined within the input file.
  • F13.32The Function system shall support the creation of objects that execute a function defined within the input file that includes a scalar variable.
  • F13.33The ParsedFunction object shall support the use of other functions specified by their names in its expression.
  • F13.34The ParsedFunction object shall support the use of functions, scalar values and postprocessor values specified by their names in its expression at the same time.
  • F13.35The 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).
  • F13.36The PiecewiseMultilinear object will error if the supplied file fails to open.
  • F13.37The PiecewiseMultiInterpolation object shall error if the supplied data is not monotonically increasing.
  • F13.38The PiecewiseMultiInterpolation object shall error if the number of requested functions differ than the number available from the file.
  • F13.39The PiecewiseMultiInterpolation errors if the axes supplied are not independent.
  • F13.40The PiecewiseMultilinear shall error if the axis lines are not located in the supplied data.
  • F13.41The PiecewiseMultilinear object shall perform interpolation on a 1D domain.
  • F13.42The PiecewiseMultilinear object shall perform interpolation on a 1D domain that compares to an equivalent known function.
  • F13.43The PiecewiseMultilinear object shall perform interpolation of time-dependent data.
  • F13.44The PiecewiseMultilinear object shall perform interpolation on a 2D domain.
  • F13.45The PiecewiseMultilinear object shall perform interpolation on a 2D domain that compares to an equivalent known function.
  • F13.46The PiecewiseMultilinear object shall perform constant interpolation on a 2D domain.
  • F13.47The PiecewiseMultilinear object shall perform interpolation on a 3D domain with time-dependent data.
  • F13.48The Function object shall support the ability to couple Postprocessor values.
  • F13.49The SolutionFunction object shall be capable of evaluating a solution read from XDA mesh and solution files.
  • F13.50The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file with temporal interpolation.
  • F13.51The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file.
  • F13.52The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the z-axis.
  • F13.53The SolutionFunction object shall be capable of evaluating a solution read from an Exodus file and rotated 45 degrees about the y-axis.
  • F13.54The 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.
  • F13.55The 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.
  • F13.56The 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.
  • F13.57The 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.
  • F13.58The SolutionFunction object shall error if a variable that does not exist is requested.
  • F13.59The 'functions/solution_function/solution_function_grad_p1' test shall create an output for the 'solution_function_grad_p2' test.
  • F13.60The SolutionFunction object shall be capable of evaluating the gradient of a solution read from an Exodus file.
  • F13.61The VectorPostprocessorFunction shall be capable of linear interpolating data generated by a VectorPostprocessor object.
  • Relationship Managers
  • F14.1MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager
  • F14.2MOOSE shall ghost additional solution information when running in parallel with an active RelationshipManager and using DistributedMesh
  • F14.3MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh
  • F14.4MOOSE shall ghost additional neighboring elements surrounding a partition when running in parallel with DistributedMesh with 3D
  • F14.5MOOSE shall ghost additional neighboring elements without also supplying solution information when a developer registers a RelationshipManager with an optional second argument to restrict functionality
  • F14.6MOOSE shall ghost additional neighboring elements without also supplying solution information when a developer registers a RelationshipManager with an optional second argument to restrict functionality in 3D
  • DGKernel Objects
  • F15.1MOOSE shall support solving 1D advection using the discontinous Galerkin method.
  • F15.2MOOSE shall support solving 2D diffusion using the discontinuous Galerkin method.
  • F15.3DGKernels shall coexist with stateful material properties
  • F15.4MOOSE shall support solving 3D diffusion using the discontinuous Galerkin method.
  • F15.5Adaptivity shall work with dg kernels as long as stateful properties are not used.
  • F15.6The system shall error if the triad of dg kernels, adaptivity, and stateful properties are used together.
  • F15.7MOOSE shall be able to solve the advection diffusion equation using the discontinuous Galerkin method.
  • F15.8MOOSE shall compute the correct Jacobian for the advection diffusion equation using the discontinuous Galerkin method.
  • F15.9The DGKernel system shall support restriction to subdomains, in 1D.
  • F15.10The DGKernel system shall support restriction to subdomains, in 2D.
  • F15.11The DGKernel system shall operate with displaced meshes.
  • F15.12The DGCoupledDiffusion object shall compute the correct Jacobian.
  • Checkpoint
  • F16.1MOOSE shall support output suitable for restarting an application.
  • F16.2MOOSE shall be capable of restarting a simulation from previously exported data.
  • Executioners
  • F17.1The Executioner system shall support the ability to create custom objects with custom execution callbacks.
  • F17.2The Executioner system shall support the creation of custom objects with arbitrary execution flags.
  • F17.3MOOSE shall support solving an Eigen value problem using the inverse power method.
  • F17.4MOOSE shall support solving an Eigen value problem using Newton's method.
  • F17.5MOOSE shall support solving an Eigen value problem using Newton's method in parallel.
  • F17.6MOOSE shall support the use of material properties during an Eigen problem solve.
  • F17.7MOOSE shall be capable of solving a diffusion problem using an Eigen value solver.
  • F17.8MOOSE shall be capable of solving a nonlinear diffusion problem using an Eigen value solver.
  • F17.9MOOSE shall be capable of solving a coupled nonlinear diffusion problem using an Eigen value solver.
  • F17.10The EigenKernel object shall be capable of using coupled variables.
  • F17.11MOOSE shall support adaptive solves for steady-state execution.
  • F17.12MOOSE shall be able to detect steady state conditions during execution.
  • F17.13MOOSE shall be capable of solving a steady state diffusion problem.
  • F17.14MOOSE shall be capable of solving a transient diffusion problem.
  • F17.15MOOSE shall correctly compute Jacobians when boundary conditions are disabled.
  • F17.16MOOSE shall compute the solution of rank-deficient linear equations if the right hand side is within the range of the linear operator.
  • F17.17MOOSE 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.
  • F17.18Executioner objects shall be capable of coupling to Postprocessor values.
  • F17.19MOOSE shall not change the system time during steady-state execution.
  • F17.20MOOSE shall be able to set the system time for steady-state execution.
  • F17.21MOOSE shall support controlling what objects are executing based on start and end times.
  • F17.22MOOSE shall support explicit definition of execution times.
  • F17.23MOOSE shall support output using a time interval.
  • Postprocessors
  • F18.1The AreaPostprocessor shall compute the "area" or dimension - 1 "volume" of sides.
  • F18.2The system shall contain a Postprocessor that computes the average value of a variable.
  • F18.3The system shall support sampling a specific quantity integrated over a single element.
  • F18.4Postprocessor objects shall be able to execute and output after the simulation is complete.
  • F18.5MOOSE 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
  • F18.6MOOSE 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
  • F18.7The NumDOFs Postprocessor shall report the number of degrees of freedom (DOFS) from one or more equations systems in the simulation.
  • F18.8The NumElems Postprocessor shall report the number of elements (active or total) in the simulation.
  • F18.9The NumElems Postprocessor shall report the number of elements (active or total) in the simulation when using distributed (pre-split) mesh.
  • F18.10Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.11Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.12Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.13Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.14Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.15Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.16Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.17Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.18Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.19Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.20Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.21Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.22Time integrators shall report the correct number of nonlinear and linear iterations, even if there are multiple stages.
  • F18.23The NumNodes Postprocessor shall report the number of nodes (replicated or distributed) in the simulation.
  • F18.24The NumNodes Postprocessor shall report the number of nodes in the simulation when using distributed (pre-split) mesh.
  • F18.25The NumVars Postprocessor shall report the number of variables from one or more equation systems in the simulation.
  • F18.26The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors.
  • F18.27The VectorPostprocessor system shall provide a mechanism to retrieve references to old vectors while maintaining vector history.
  • F18.28MOOSE shall have the abililty to pull time from the PerfGrahp into a Postprocessor
  • F18.29The TableOutput object shall allow the user to override tolerance checks when determining whether new rows should be added (independent variable delta)
  • InterfaceKernel Objects
  • F19.1Interface kernels shall provide integrated conditions between subdomains, and shall work with boundary restricted materials with stateful properties.
  • F19.2The interface diffusion penalty method should reproduce the analytic solution
  • F19.3Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side a (block 0) of the interface.
  • F19.4Save-in shall record the correct residuals and Jacobians representing the interface kernel. This applies the DirichletBC to side b (block 1) of the interface.
  • F19.5The InterfaceKernel system shall operate with coupled variables in 2D. This uses a penalty implementation that is optimally convergent.
  • F19.6Allow the interface to impose the same time derivative on two neighboring variables. This uses a penalty implementation that is optimally convergent.
  • F19.7The Jacobian evaluation for InterfaceKernel objects in 2D shall be analytically correct.
  • F19.8The finite difference preconditioner shall work in parallel.
  • F19.9The InterfaceKernel system shall operate with coupled variables in 3D. This uses a penalty implementation that is optimally convergent.
  • F19.10Adaptivity shall work with interface kernels as long as stateful properties are not used.
  • F19.11The system shall error if the triad of interface kernels, adaptivity, and stateful properties are used together.
  • Ics
  • F20.1MOOSE shall generate parallel agnostic random initial conditions
  • F20.2MOOSE shall generate threaded agnostic random initial conditions
  • F20.3The system shall allow to set constant vector-valued initial conditions.
  • Mesh Modifiers
  • F21.1check the results of BreakMeshByBlock for a 2D case
  • F21.2compare results obtained with the manual autoamtic mesh splitprocedure matches for the 2D Case
  • F21.3same as 2D4ElementJunctionBreakMeshAuto_test but with the prameter split_interface=true
  • F21.4For a 2D case, the MeshModifier should break the mesh into multiple unconnected grains and create an interface on all grain boundaries
  • F21.5same as 2D4ElementJunctionBreakMeshtingCompare_test but with the prameter split_interface=true
  • F21.6check the results of BreakMeshByBlock for a 3D case
  • F21.7compare results obtained with the manual autoamtic mesh splitprocedure matches for the 3D Case
  • F21.8same as 3D3BlocksBreakMeshAuto_test but with the prameter split_interface=true
  • F21.9For a 3D case, the MeshModifier should break the mesh into multiple unconnected grains and create an interface on all grain boundaries
  • F21.10same as 3D3BlocksBreakMeshManualSplitInterface_test but with the prameter split_interface=true
  • F21.11A LowerDBlockFromSideset mesh modifier shall create a lower dimensional element block from a list of sidesets
  • F21.12A LowerDBlockFromSideset mesh modifier shall create a second order lower dimensional block from second order parents
  • F21.13MOOSE shall allow the smoothing of existing meshes to improve mesh quality
  • Multiapps
  • F22.1The system shall detect input file problems with sub app input files.
  • F22.2The system shall CLI argument problems related to sub app input files.
  • F22.3The system show error when the number of input files is great than one and doesn't match the number of provided sub app positions.
  • F22.4The 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.
  • F22.5The system shall error when the number of sub app input files doesn't match the number of provided positions files.
  • F22.6The system shall error when both positions are provided in the input file along with a separate file of positions.
  • F22.7The system shall error when the multiapp positions file is malformed.
  • F22.8The system shall error when the Multiapp parameter sub_cycling and catch_up are both set to true.
  • F22.9The MultiApp system shall include the ability to set command line parameters for each sub application from the input file.
  • F22.10The MultiApp system shall include the ability to set common command line parameters for all sub applications from the input file.
  • F22.11The MultiApp system shall error when the number of command line arguments supplied in the input file differs from the number if sub apps.
  • F22.12The system shall support creating a Multiapp that is not initially enabled
  • F22.13The system shall allow transient multiapps to use Picard iterations to rerun the time step
  • F22.14The system shall support adaptive time stepping for transient multiapps with Picard iterations controlled by tolerances
  • F22.15The system shall reject the solve if the maximum number of Picard iterations is reached without converging
  • F22.16The system shall allow transient multiapps with Picard iterations controlled by relative tolerances
  • F22.17The system shall allow transient multiapps with Picard iterations controlled by absolute tolerances
  • F22.18The system shall allow function-defined time stepping for transient multiapps
  • F22.19The system shall allow steady-state Picard iteration with multiapps
  • F22.20The system shall allow steady-state Picard iteration with pseudo-transient multiapps
  • F22.21Multiapps shall be able to be restored when a subapp encounters a solve failure.
  • F22.22CSV file writing should remain unaffected when a subapp encounters a solve failure.
  • F22.23Multiapps shall be able to cut the master app time step when any subapp encounters a solve failure.
  • F22.24The system shall support Picard iteration with multiple levels of Multiapps.
  • F22.25The 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.
  • F22.26MOOSE shall provide an ability to do Picard iteration.
  • F22.27MOOSE shall provide an ability to relex solutions for Picard iteration.
  • F22.28MOOSE shall provide an ability to relex subapp solutions along with the master solution for Picard iteration.
  • F22.29MOOSE shall error out if provided relaxation factor is less than or equal to 0 or greater than or equal to 2.
  • F22.30The system shall support a time offset between the master and a subapp when using the Multiapp system.
  • Auxkernels
  • F23.1MOOSE shall support auxiliary calculations for scalar variables at nodes.
  • F23.2The AuxScalarKernel system shall automatically resolve dependencies between objects.
  • F23.3The ConstantScalarAux object shall set the value of an scalar auxiliary variable to a constant value.
  • F23.4The DiffusionFluxAux object shall compute the components of the flux vector for diffusion problems.
  • F23.5The variable data created by a MaterialRealAux object shall support being limited to boundaries.
  • F23.6Kernel objects shall be capable of coupling to an auxiliary variable.
  • F23.7AuxKernel object dependencies shall be resolved automatically.
  • F23.8AuxKernel objects shall operate on higher-order monomial basis functions.
  • F23.9AuxKernel objects shall operate on first-order L2 basis functions.
  • F23.10AuxKernel object dependencies shall be resolved between block and non-block restricted variables.
  • F23.11MOOSE shall include an AuxKernel object for returning the element length.
  • F23.12MOOSE shall be able to compute and visualize element quality metrics
  • F23.13MOOSE shall support the computation of a single value per element within the auxiliary system.
  • F23.14MOOSE shall include the ability to compute the Lp, L2, and H1 error norms for each element.
  • F23.15MOOSE shall allow objects that depend on each other but have differing execution flags to run without error.
  • F23.16MOOSE shall include the ability to access the normal of a coupled variable within an AuxKernel object.
  • F23.17MOOSE shall include the ability to set the value of a scalar variable using a function.
  • F23.18MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap.
  • F23.19MOOSE shall include the ability to report values on a boundary from a boundary across a mesh gap for a block restricted variable.
  • F23.20MOOSE shall include the ability to extract a component of a linear Largrange variable gradient as an auxiliary variable.
  • F23.21MOOSE shall include the ability to extract a component of a first order monomial variable gradient as an auxiliary variable.
  • F23.22MOOSE shall include the ability to compute the linear combination of variables as an auxiliary variable.
  • F23.23MOOSE shall include the ability to compute the shortest distance from a nodes across boundaries.
  • F23.24MOOSE shall have the ability to restrict AuxKernel objects with coupled variables to a boundary.
  • F23.25MOOSE shall include the ability to limit the execution of an AuxKernel object to initial setup.
  • F23.26MOOSE shall include the ability to couple auxiliary variables.
  • F23.27MOOSE shall be capable of resolving dependencies between AuxKernel objects regardless of input file order.
  • F23.28The AuxKernel objects shall be capable of coupling to multiple variables.
  • F23.29The MOOSE auxiliary system shall be capable of updating multiple auxiliary variables within a single AuxKernel object.
  • F23.30The MOOSE auxiliary system shall be capable of coupling to nonlinear variables at the end of a timestep.
  • F23.31MOOSE shall include the ability to normalize a variable based on a Postprocessor value.
  • F23.32MOOSE shall include the ability to normalize and shift a variable based on a Postprocessor value.
  • F23.33AuxKernel objects shall support the use of material properties from the previous two timesteps.
  • F23.34MOOSE shall include an AuxKernel object capable of computing values from a functional expression.
  • F23.35Execution of a UserObject shall occur after the execution of the AuxKernel objects if the former depends on the latter.
  • F23.36MOOSE shall support the ability to compute the quotient of two variables.
  • F23.37The 'auxkernels/solution_aux/build' test shall create an output file for testing the 'SolutionAux' object.
  • F23.38The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution.
  • F23.39The SolutionAux object shall be capable of initializing an auxiliary variable from an existing solution using a direct degree-of-freedom copy for identical meshes.
  • F23.40The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file.
  • F23.41The SolutionAux object shall be capable of populating an auxiliary variable from an ExodusII file with a custom extension (e.g., *.e-s003).
  • F23.42The SolutionAux object shall be capable of reading elemental data for the largest timestep.
  • F23.43The SolutionAux object shall be capable of reading elemental data for a specific timestep.
  • F23.44The SolutionAux object shall be capable of restricting reading to a single elemental variable.
  • F23.45The 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.
  • F23.46The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation.
  • F23.47The 'auxkernels/solution_aux/exodus_interp_restart1' shall create a restart file for subsequent tests.
  • F23.48The SolutionAux object shall be capable of restart.
  • F23.49The SolutionAux object shall be capable of setting an auxiliary variable with temporal interpolation using a direct degree-of-freedom copy for identical meshes.
  • F23.50The SolutionAux object shall be capable of accessing specific variables from a SolutionUserObject.
  • F23.51The SolutionAux object shall produce an error if the 'from_variable' parameter is not set and the supplied UserObject has multiple variables.
  • F23.52The SolutionUserObject object shall be capable of scaling and translating the supplied data.
  • F23.53The SolutionAux object shall error if data for the supplied variable is not found in the SolutionUserObject data.
  • F23.54The 'auxkernels/solution_aux/aux_nonlinear_solution' test shall create an XDA and XDR output file for testing the 'SolutionAux' object with auxiliary variables.
  • F23.55The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file.
  • F23.56The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDR file.
  • F23.57The 'auxkernels/solution_aux/aux_nonlinear_solution_adapt' test shall create an XDA output file for testing the 'SolutionAux' object with adaptivity.
  • F23.58The SolutionAux object shall be capable of setting values using an auxiliary variable from an XDA file with adaptivity.
  • F23.59The SolutionAux object shall be capable to reading auxiliary variables when operating on multiple threads.
  • F23.60Kernel objects shall be able to couple to the time derivative of an auxiliary variable.
  • F23.61AuxKernel objects shall be able to couple to the time derivative of a nonlinear variable.
  • F23.62Error an AuxKernel object attemps to couple to the time derivative of an auxiliary variable.
  • F23.63MOOSE shall include the ability to compute the integral of a variable over time.
  • F23.64MOOSE shall include the ability to compute the Euclidean norm of three coupled variables.
  • F23.65MOOSE shall be capable of populating an auxiliary variable from VectorPostprocessor data sized to the number of processors.
  • F23.66AuxKernel objects shall be capable of coupling to VectorPostprocessor objects.
  • Dampers
  • F24.1MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on elements.
  • F24.2MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on elements.
  • F24.3MOOSE shall include the ability to reduce the change in nonlinear residual based on a maximum value on nodes.
  • F24.4MOOSE shall include the ability to reduce the change in nonlinear residual based on a minimum value on nodes.
  • F24.5MOOSE shall include the ability to reduce the change in nonlinear residual based on a constant value.
  • F24.6The Damper system shall use the minimum of NodalDamper and ElementDamper, when the later computes the minimum.
  • F24.7The Damper system shall use the minimum of NodalDamper and ElementDamper, when the former computes the minimum.
  • F24.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.
  • F24.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.
  • F24.10The BoundingValueNodalDamper object shall report if the minimum value is greater than the maximum value.
  • F24.11The BoundingValueElementDamper object shall report if the minimum value is greater than the maximum value.
  • F24.12The Damper system shall error if the damping value is below a minimum.
  • Fixedbugs
  • F25.1The Material objects provided on all subdomains shall satisfy requests for objects on all subdomains.
  • Problems
  • F26.1The system shall allow the creation of a custom problem through a user-defined Action.
  • F26.2The system shall support the creation of a custom problem with parameters in Problem block.
  • F26.3The system shall error out when Problem block type is not specified.
  • F26.4The system shall support the creation of a custom problem through Problem block with type specified.
  • F26.5MOOSE shall have a capability to dump the equivalent input file syntax for all objects added by a given action.
  • F26.6MOOSE shall support an code coupling interface that can trigger external solves.
  • F26.7MOOSE shall support an code coupling interface that can trigger external solves for transient simulations.
  • Partitioners
  • F27.1MOOSE shall provide a simple regular grid-based partitioner
  • F27.2MOOSE shall error if the GridPartitioner is run on an incompatible number of processors
  • F27.3Make MOOSE support ptscotch via PETSc
  • F27.4ptscotch shall support element-weighted graphs for balancing workload
  • F27.5ptscotch shall support side-weighted graphs for minimizing communication
  • F27.6ptscotch shall take both side weights and element weights into consideration
  • F27.7Make MOOSE support parmetis via PETSc
  • F27.8Parmetis shall support element-weighted graphs for balancing workload
  • F27.9Parmetis shall support element-weighted graphs for balancing workload
  • F27.10Parmetis shall support side-weighted graphs for minimizing communication
  • F27.11Parmetis shall support side-weighted graphs for minimizing communication
  • F27.12Parmetis shall take side weights and element weights into consideration
  • F27.13Parmetis shall take side weights and element weights into consideration
  • F27.14MOOSE shall support a serial partitioner Chaco
  • F27.15MOOSE shall support a serial partitioner party
  • Mesh
  • F28.1MOOSE shall be able to build a 1D mesh in parallel
  • F28.2MOOSE shall be able to build a 2D mesh in parallel
  • F28.3MOOSE shall be able to build a 3D mesh in parallel
  • F28.4DistributedGeneratedMesh shall allow mesh biasing
  • F28.5MOOSE shall generate a structured mesh on a Cartesian domain.
  • F28.6MOOSE shall generate first-order, structured meshes with biasing in the x, y, and z directions.
  • F28.7MOOSE shall generate second-order, structured meshes with biasing in the x, y, and z directions.
  • F28.8MOOSE's annular mesh generator shall throw an error if the min radius is larger than the max radius.
  • F28.9MOOSE's annular mesh generator shall throw an error if the min angle is >= the max angle.
  • F28.10MOOSE's annular mesh generator shall throw an error if the angle separation is larger than 2*pi.
  • F28.11MOOSE's annular mesh generator shall throw an error if the number of elements in the angular direction is too small.
  • F28.12MOOSE's annular mesh generator shall throw an error if the number of elements in the angular direction is too small.
  • F28.13MOOSE's annular mesh generator shall throw an error if the quadrilateral and triangular subdomain ids are the same.
  • F28.14MOOSE shall have an algorithm for quad meshing an annulus.
  • F28.15MOOSE shall have an algorithm for quad meshing an annular sector.
  • F28.16MOOSE shall have an algorithm for quad meshing a circular region, including the origin.
  • F28.17MOOSE shall have an algorithm for quad meshing a circular sector, including the origin.
  • F28.18MOOSE shall have an algorithm for meshing an annular region with triangular elements.
  • F28.19MOOSE shall have an algorithm for generating triangular and quadrilateral meshes for the Ringleb problem.
  • F28.20The system shall allow writing out the mesh without running a simulation.
  • F28.21The system shall print out information about the mesh when writing out the mesh.
  • F28.22The system shall warn when using –mesh-only and there is no clear filename to use
  • F28.23The system shall support overriding output dimension when necessary to store coordinates in higher planes
  • F28.24MOOSE shall support writing out a solution in a parallel file format (domain decomposition solution files).
  • F28.25The system shall issue an error if no Mesh block is provided.
  • F28.26The system shall issue an error if no Mesh block is provided even when MeshGenerators are provided.
  • F28.27A mesh can be split into a specified number of files using command line options.
  • F28.28A mesh can be pre-split properly and used to generate equivalent results to running a simulation with the unsplit mesh.
  • F28.29Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode
  • F28.30Console output should include an indicator that a pre-split mesh is being used when using –split-mesh in distributed = auto mode
  • F28.31The mesh splitter will throw an error when an attempt is made to split a "DistributedMesh".
  • F28.32The mesh splitter capability will honor geometric RelationshipManager objects.
  • F28.33Meshes that are pre-split with active RelationshipManager objects work the same as if using an online DistributedMesh.
  • Coord Type
  • F29.1MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction.
  • F29.2MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction.
  • F29.3MOOSE shall support cylindrical coordinates with the radial direction in the 'x' direction with discontinous Galkerin and integrated boundary conditions.
  • F29.4MOOSE shall support cylindrical coordinates with the radial direction in the 'y' direction with discontinous Galkerin and integrated boundary conditions.
  • Transfers
  • F30.1The system shall allow to interpolate variables from the master app to the sub apps
  • F30.2The system shall allow to interpolate variables from the sub apps to the master app
  • F30.3The system shall allow to interpolate block restricted variables from the sub apps to the master app
  • F30.4The system shall transfer both nodal and elemental fields to a SubApp from the Master App.
  • F30.5The system shall transfer both nodal and elemental fields from SubApps to the Master App.
  • F30.6The system shall transfer values from SubApps which set the displaced_source_mesh flag to true.
  • F30.7blockThe system shall transfer values from SubApps which set the displaced_target_mesh flag to true.
  • F30.8The system shall support the 'fixed_meshes' flag which allows caching of nearest neighbors.
  • F30.9The system shall transfer values to multiple SubApps from the Master App's boundary.
  • F30.10The system shall transfer values from a SubApp boundary to the Master App.
  • F30.11The system shall work when there are multiple SubApps present.
  • F30.12The system shall work in parallel between meshes with different spatial dimensions.
  • F30.13MultiAppUserObjectTransfer shall generate an error if a master node/element is not contained within any sub application domains.
  • F30.14The Transfer system shall support execution with the EXEC_FINAL flag.
  • Outputs
  • F31.1The system shall output a running list of Picard norms during Picard iteration.
  • F31.2The system shall only output Picard TIMESTEP_BEGIN norms when there are no TIMESTEP_END Multiapps.
  • F31.3The system shall only output Picard TIMESTEP_END norms when there are no TIMESTEP_BEGIN Multiapps.
  • F31.4The system shall output Picard norms for TIMESTEP_BEGIN and TIMESTEP_END Multiapps when both exist in the simulation.
  • F31.5blockDisabling Console objects should result in no output to the screen.
  • F31.6The 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.
  • F31.7The 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.
  • F31.8The CSV output object 'create_final_symlink' parameter shall be able to disable the creation of the final symlink.
  • F31.9The CSV output object shall create a symlink to the most recent output with with a '_LATEST' suffix for VectorPostprocessor data.
  • F31.10The CSV output object 'create_latest_symlink' parameter shall be able to disable the creation of the latest symlink.
  • F31.11The system shall be able to output the displaced mesh for a model with adaptive mesh refinement.
  • F31.12If the user requested the output of a displaced problem and there is none present, the system shall fallback to using the non-displaced problem.
  • F31.13If 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
  • F31.14The Output system shall be capable of applying displacements directly to the outputted mesh for steady problems.
  • F31.15The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems with Kernels using the displaced configuration.
  • F31.16The Output system shall be capable of applying displacements directly to the outputted mesh for transient problems.
  • F31.17Nemesis output shall work
  • F31.18GMV output shall work
  • F31.19We shall be able to dump YAML data
  • F31.20Executioner output shall only be given once
  • F31.21Tecplot output shall work
  • F31.22If tecplot api is available, tecplot output will be given in tecplot binary format
  • F31.23If tecplot api is not available, tecplot output will be given in ASCII format
  • F31.24We shall be able to generate gnuplot postscript output
  • F31.25We shall be able to generate gnuplot png output
  • F31.26We shall be able to generate gnuplot gif output
  • F31.27If a postprocessor utilizes the "outputs" parameter, but postprocessor output is disable for the console object, we shall warn the user
  • F31.28–show-input shall print parameters
  • F31.29Solution history output shall work
  • F31.30MOOSE shall support XDR output
  • F31.31The system shall be able to dump input file syntax in JSON format
  • F31.32The system shall be able to dump input file syntax in JSON format and exclude test object syntax.
  • F31.33The system shall be able to dump a subset of JSON formatted syntax.
  • F31.34The system shall dump line information along with JSON formatted syntax.
  • F31.35The system shall be able to dump input file (HIT) syntax.
  • F31.36The system shall be able to dump a subset of input file (HIT) syntax.
  • F31.37MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExistsIn
  • F31.38MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ChildAtLeastOne
  • F31.39MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ValEnums
  • F31.40MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check active parameter
  • F31.41MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check normal_sub
  • F31.42MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check type_sub
  • F31.43MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check default type
  • F31.44MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check MinValInc
  • F31.45MOOSE shall be able to convert a JsonSyntaxTree into Standard Object Notation (SON) for use by the NEAMS workbench. Check ExpressionsAreOkay
  • F31.46The Nemesis Output object shall output separate files per process for visualization purposes.
  • F31.47The Nemesis Output object shall support writing elemental variables.
  • F31.48The Nemesis Output object shall support writing elemental variables with the same numbering on DistributedMesh.
  • F31.49The Nemesis Ouput object shall support writing scalar variables.
  • F31.50The Nemesis Ouput object shall support writing scalar variables when using DistributedMesh.
  • F31.51The system shall allow the user to select different console output intervals.
  • F31.52The system shall display active output information with corresponding execute flags.
  • F31.53MOOSE shall output a performance log for multiapps with sub_cycling enabled.
  • F31.54MOOSE shall output a performance log for multiapps with sub_cycling enabled.
  • F31.55MOOSE shall output a performance log for multiapps with sub_cycling enabled.
  • F31.56MOOSE shall have the ability to output a detailed performance log
  • F31.57Correctly set up initial recover files for the part2 test.
  • F31.58A simulation executed using the "–recover" flag successfully runs a simulation using the specified recover file argument.
  • F31.59Correctly set up initial recover files for the part2_latest test.
  • F31.60A 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.
  • F31.61The variables specified in an Output object's 'hide = ' list shall not appear in the output file.
  • Markers
  • F32.1The adaptivity system shall create an auxiliary field variable that marks elements for refinement within a rectangular region.
  • F32.2The adaptivity system shall adapt the mesh within a rectangular region.
  • F32.3It shall not be possible to specify Markers to run on the displaced mesh.
  • Userobjects
  • F33.1MOOSE shall allow taking averages of variables along a coordinate axis in layers
  • F33.2MOOSE shall allow specifying boundaries and numbers of layers for layered averages
  • F33.3MOOSE shall allow specifying boundaries and numbers of layers for layered averages
  • F33.4MOOSE shall allow specifying boundaries and numbers of layers for layered averages
  • F33.5MOOSE shall allow specifying boundaries and numbers of layers for layered averages
  • F33.6MOOSE shall allow interpolating between layers for layered averages
  • F33.7MOOSE shall respect mesh displacements in layered average
  • F33.8MOOSE shall respect block restriction for layered averages
  • F33.9MOOSE shall respect block restriction for layered averages
  • F33.10MOOSE shall respect block restriction for layered averages even when using num_layers
  • F33.11MOOSE shall allow bounds for layered averages when using num_layers to come from a block different than the block restriction
  • F33.12MOOSE shall correctly compute layered integrals along a specified boundary
  • F33.13MOOSE shall allow taking averages of variables along a coordinate axis in layers on a boundary
  • F33.14MOOSE shall allow taking averages of the flux of variables along a coordinate axis in layers on a boundary
  • F33.15MOOSE shall not allow both the block and boundary parameter to be specified for layered side integrals
  • F33.16The system shall compute layered averages that computed from the closest values for a list of points that are explicitly specified in an input file
  • F33.17The system shall compute layered averages that computed from the closest values for a list of points that are specified in an external file
  • F33.18The system shall report an error when points are not specified in an input file nor an external file when computing nearest point layered averages
  • F33.19The system shall report an error when points are specified both in an input file and an external file when computing nearest point layered averages
  • F33.20The 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
  • Materials
  • F34.1The Jacobian from a material property declared as AD and gotten as AD shall be accurate
  • F34.2The Jacobian from a material property declared as regular and gotten as AD shall be inaccurate
  • F34.3The Jacobian from a material property declared as AD and gotten as regular shall be inaccurate
  • F34.4The Jacobian from a material property declared as regular and gotten as regular shall be inaccurate
  • F34.5AD shall work with stateful material properties and the Jacobian shall be beautiful
  • F34.6The time evolution of the stateful diffusivity property shall show that AD works with stateful material properties
  • F34.7The system shall provide material properties in boundary restricted objects acting on nodal variables.
  • F34.8The system shall provide material properties in boundary restricted objects acting on elemental variables.
  • Vectorpostprocessors
  • F35.1Line sampling shall account for floating point precision error.
  • F35.2The system shall support dynamic numbers of sample points during the simulation.
  • F35.3The system shall support dynamic numbers of sample points during the simulation with move semantics of the points vector.
  • F35.4The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 1D mesh
  • F35.5The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 2D mesh
  • F35.6The ElementsAlongLine VectorPostprocessor shall output the IDs of all elements intersected by a line on a 3D mesh
  • F35.7The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 1D mesh
  • F35.8The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 2D mesh
  • F35.9The ElementsAlongPlane VectorPostprocessor shall output the IDs of all elements intersected by a plane on a 3D mesh
  • F35.10MOOSE shall allow to sample variables at equally spaced points for outputting.
  • F35.11MOOSE shall allow to sample variables at equally spaced points in parallel.
  • F35.12MOOSE shall allow to scale the line value sampler with a postprocessor.
  • F35.13MOOSE shall allow to sample auxvariables at equally spaced points with CSV delimiter and precision setting.
  • F35.14MOOSE shall provide VectorPostprocessor results to all processors as scattered data
  • F35.15MOOSE shall provide VectorPostprocessor results to all processors as replicated data
  • F35.16The VectorPostprocessor system takes a parameter "contains_complete_history" which guarentees the vector state is left alone between invocations resulting in a single CSV output file.
  • Constraints
  • F36.1MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface using Lagrange multipliers.
  • F36.2MOOSE shall include the ability to constrain the values on a boundary to a value at a prescribed node.
  • F36.3MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.
  • F36.4MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a penalty formulation.
  • F36.5MOOSE shall support embedded constraints between a 1D and 2D subdomain, using a kinematic formulation.
  • F36.6MOOSE shall support embedded constraints between a 1D and 3D subdomain, using a penalty formulation.
  • F36.7MOOSE shall support embedded constraints between 2D subdomains, using a kinematic formulation.
  • F36.8MOOSE shall support embedded constraints between 2D subdomains, using a penalty formulation.
  • F36.9MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a kinematic formulation.
  • F36.10MOOSE shall support embedded constraints between a 2D and 3D subdomain, using a penalty formulation.
  • F36.11MOOSE shall support embedded constraints between 3D subdomains, using a kinematic formulation.
  • F36.12MOOSE shall support embedded constraints between 3D subdomains, using a penalty formulation.
  • F36.13MOOSE shall support the ability to constrain nodal values.
  • F36.14MOOSE shall support the ability to constrain nodal values using a displaced mesh.
  • F36.15MOOSE shall include ability to force the value of a variable to be the same on both sides of an interface.
  • Bcs
  • F37.1MOOSE shall support Neumann type boundary conditions for a 1D problem.
  • F37.2MOOSE shall support Neumann type boundary conditions for a 1D problem using an imported mesh.
  • F37.3We shall be able to produce the expected result using ADKernel, ADNodalBC, and ADIntegratedBC
  • F37.4We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a first order variable
  • F37.5We shall be able to produce the exact Jacobian using ADKernel, ADNodalBC, and ADIntegratedBC with a second order variable
  • F37.6We shall be able to produce the expected result using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC
  • F37.7We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a first order variable
  • F37.8We shall be able to produce the exact Jacobian using ADVectorKernel, ADVectorNodalBC, and ADVectorIntegratedBC with a second order variable
  • F37.9MOOSE shall support setting Dirichlet type boundary conditions, supplied as a function, directly to the solution vector prior to the solve.
  • F37.10MOOSE shall support setting Dirichlet type boundary conditions directly to the solution vector prior to the solve.
  • F37.11MOOSE shall support the creation of BoundaryCondition objects that support conditional activation.
  • F37.12MOOSE shall support the creation of BoundaryCondition objects that couple to nonlinear variables.
  • F37.13MOOSE shall support Dirichlet type boundary conditions defined by a function.
  • F37.14MOOSE shall support matching variable values on a boundary.
  • F37.15MOOSE shall support the ability to create convective flux boundary conditions.
  • F37.16MOOSE shall support a vacuum boundary condition for neutron diffusion on the boundary.
  • F37.17MOOSE 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., ).
  • F37.18MOOSE shall support the 'no boundary condition' type boundary condition (Griffiths, 1997).
  • F37.19MOOSE shall be capable of computing the nodal normals for triangle elements.
  • F37.20MOOSE shall be capable of computing the nodal normals for quadrilateral elements.
  • F37.21MOOSE shall be capable of computing the nodal normals for first order hexahedron elements.
  • F37.22MOOSE shall be capable of computing the nodal normals for second order hexahedron elements.
  • F37.23MOOSE shall be capable of computing the first order nodal normals for second order hexahedron elements.
  • F37.24MOOSE shall be capable of computing the nodal normals for quadrilateral elements on a square domain.
  • F37.25MOOSE shall support the application of Dirichlet type boundary conditions using the penalty method.
  • F37.26MOOSE shall support the application of Dirichlet type boundary conditions, defined by a function, using the penalty method.
  • F37.27MOOSE shall support periodic boundary conditions with transforms defined as functions.
  • F37.28MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions.
  • F37.29MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x' and 'y' directions using a non-generated mesh.
  • F37.30The PeriodicDistanceAux object shall produce an error when a point is provided that is outside the mesh domain.
  • F37.31MOOSE shall support periodic boundary conditions with transforms that are computed automatically in the 'x', 'y', and 'z' directions.
  • F37.32MOOSE shall support periodic boundary conditions on orthogonal boundaries with transforms defined as functions.
  • F37.33MOOSE shall support periodic boundary conditions on parallel boundaries with transforms defined as functions.
  • F37.34blockMOOSE shall support periodic boundary conditions on subdomain restricted variables.
  • F37.35MOOSE shall support periodic boundary conditions with mesh adaptivity.
  • F37.36MOOSE shall support periodic boundary conditions with transforms prescribed as a translation.
  • F37.37MOOSE shall support periodic boundary conditions with displacements.
  • F37.38MOOSE shall support periodic boundary conditions on a trapezoid domain with transforms prescribed as functions.
  • F37.39Calls to periodic distance and bounds methods on the mesh shall work when periodic boundary conditions are not used.
  • F37.40MOOSE shall support periodic boundary conditions on a wedge domain with transforms prescribed as functions.
  • F37.41MOOSE shall support periodic boundary conditions for a single variable on a wedge domain with transforms prescribed as functions.
  • F37.42MOOSE shall support periodic boundary conditions for input meshes that have repeated element ids.
  • F37.43The Periodic Boundary system shall not attempt to add periodic boundary conditions to scalar variables.
  • F37.44MOOSE shall support the application of a Neumann boundary condition computed via Postprocessor object.
  • F37.45MOOSE shall properly compute second derivatives within BoundaryCondition objects.
  • F37.46MOOSE shall support creating sidesets from nodesets for hexahedron elements to use with Boundary Condition objects.
  • F37.47MOOSE shall support creating sidesets from nodesets for tetrahedron elements to use with Boundary Condition objects.
  • F37.48MOOSE shall include the ability to apply a Neumann boundary condition according to a sin function.
  • F37.49MOOSE shall include the ability to apply a Dirichlet boundary condition according to a sin function.
  • F37.50BoundaryCondition objects shall support retrieval of VectorPostprocessor data.

Usability Requirements

  • U1.0

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

  • U1.1

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

  • U1.2

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

  • U1.3

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

Performace Requirements

  • P1.0

    The system will support multi-process distributed memory execution.

  • P1.1

    The system will support multi-process shared memory execution.

  • P1.2

    The system will support execution on Unix-based laptops.

  • P1.3

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

  • P1.4

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

System Interfaces

  • S1.0

    The system shall support POSIX compliant systems.

  • S1.1

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

  • S1.2

    The system shall support POSIX pthreads''.

  • S1.3

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

  • S1.4

    The system shall support the OpenMP threading interface.

System Operations

Human System Integration Requirements

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

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

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

Maintainablity

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

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

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

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

Reliability

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

System Modes and States

error:Missing Template Item: "system-modes"help_outline

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

note

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

Phyisical Characteristics

error:Missing Template Item: "physical-characteristics"help_outline

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

Environmental Conditions

error:Missing Template Item: "environmental-conditions"help_outline

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

System Security

error:Missing Template Item: "system-security"help_outline

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

Information Management

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

Polices and Regulations

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

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

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

System Life Cycle Sustainment

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

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

Packaging, Handling, Shipping and Transportation

error:Missing Template Item: "packaging"help_outline

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

Verification

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