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, or Intel)

  • Python 2.6+

  • Git

Functional Requirements

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