Phase Field System Requirements Specification

This template follows INL template TEM-135, "IT System Requirements Specification".

note

This document serves as an addendum to Framework System Requirements Specification and captures information for SRS specific to the Phase Field application.

Framework System Requirements Specification

Introduction

System Purpose

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

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

System Scope

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

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

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

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

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

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

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

System Overview

System Context

MOOSE is a command-line driven application. This is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all of the usage of the software is through any standard terminal program generally available on all supported operating systems. Similarly, for the purpose of interacting through the software, there is only a single user, "the user", which interacts with the software through the command-line. MOOSE does not maintain any back-end database or interact with any system daemons. It is a executable, which may be launched from the command line and writes out various result files as it runs.

Figure 1: Usage of MOOSE and MOOSE-based applications.

System Functions

Since MOOSE is a command-line driven application, all functionality provided in the framework is operated through the use of standard UNIX command line flags and the extendable MOOSE input file. The framework is completely extendable so individual design pages should be consulted for specific behaviors of each user-defined object.

User Characteristics

Framework Developers: These are the core developers of the framework. They will be responsible for following and enforcing the appropriate software development standards. They will be responsible for designing, implementing and maintaining the software.
Developers: A Scientist or Engineer that utilizes the framework to build his or her own application. This user will typically have a background in modeling and simulation techniques and/or numerical analysis but may only have a limited skill-set when it comes to object-oriented coding and the C++ language. This is our primary focus group. In many cases these developers will be encouraged to give their code back to the framework maintainers.
Analysts: These are users that will run the code and perform various analysis on the simulations they perform. These users may interact with developers of the system requesting new features and reporting bugs found and will typically make heavy use of the input file format.

Assumptions and Dependencies

The Phase Field application is developed using MOOSE and is based on various modules, as such the SRS for Phase Field is dependent upon the files listed at the beginning of this document.

References

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

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

ASME NQA-1. ASME NQA-1-2008 with the NQA-1a-2009 addenda: Quality Assurance Requirements for Nuclear Facility Applications. first edition, August 31 2009.

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

Definitions and Acronyms

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

Definitions

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

Acronyms

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

System Requirements

- A Portable Operating System Interface (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++17 compatible compiler (GCC, Clang) - Python 3.7+ - Git

Functional Requirements

phase_field: Adchsoretdiffusion
8.1.1A temperature gradient driving force for diffusion shall be added to the split form of the Cahn-Hilliard equation and solved using automatic differentiation.
8.1.2The Jacobians for the automatic differentiation ADCHSplitChemicalPotential and ADCHSplitConcentration kernels shall be accurate.

phase_field: Adchsplitchemicalpotential
8.2.1ADCHSplitChemicalPotential and ADCHSplitConcentration shall solve a simple Cahn-Hilliard problem using automatic differentiation.
8.2.2The Jacobians for the automatic differentiation ADCHSplitChemicalPotential and ADCHSplitConcentration kernels shall be accurate.

phase_field: Chsplitchemicalpotential
8.3.1

phase_field: Deformedgrain
8.4.1

phase_field: Ebsdmeshgenerator
8.5.1
The system shall detect invalid or inconsistent EBSD file parameters
1. if the EBSD data step size is zero,
2. if the EBSD grid size is zero,
3. if the EBSD data is zero dimensional,
4. if the requested pre_refine levels are not possible

phase_field: Gbanisotropy
8.6.1A material shall be provided to compute anisotropic grain boundary energies and mobilities.
8.6.2A material shall be provided to compute anisotropic grain boundary energies and mobilities.
8.6.3A material shall be provided to compute anisotropic grain boundary energies and mobilities with an inclination dependence.
8.6.4The anisotropic grain boundary system shall allow the user to specify grain boundary widths independently for each interface between grains.

phase_field: Grain Velocity Computation
8.7.1The system shall be able to provide a velocity vector field indicating grain boundary movement for visualization purposes.

phase_field: Grandpotentialpfm
8.8.1The system shall provide classes to implement a Grand Potential phase field formulation
8.8.2The system shall provide a Grand Potential based multiphase model
8.8.3The system shall provide a Grand Potential based dendritic solidification capability in 2D
8.8.4The system shall provide a material to automatically compute grand potential model interface parameters based on provided interfacial free energies and widths
8.8.5The system shall provide a Grand Potential based dendritic solidification capability for alloy with antitrapping current
8.8.6The system shall provide a Grand Potential based sintering model
8.8.7The system shall provide a Grand Potential based sintering model with parabolic defect free energies
8.8.8The system shall provide a Grand Potential based sintering model with dilute solution defect free energies
8.8.9The system shall provide a Grand Potential based sintering model with ideal solution defect free energies

phase_field: Kks System
8.9.1The Kim-Kim-Suzuki model implementation shall use free energy densities provided by DerivativeParsedMaterials
8.9.2A non-split version of the Kim-Kim-Suzuki shall be provided
8.9.3A split version of the Kim-Kim-Suzuki shall be provided
8.9.4The split version of the Kim-Kim-Suzuki shall be yield the correct results with asymmetric free energies
8.9.5A multi component Kim-Kim-Suzuki model shall be implemented
8.9.6A multi component Kim-Kim-Suzuki model shall be implemented

phase_field: Maskedbodyforce
8.10.1

phase_field: Multiphase
8.11.1The system shall provide a material to combine two free energies materials into a WBM two phase free energy
8.11.2The system shall provide a materials to generate barrier and switching function in a WBM multiphase model
8.11.3The system shall provide a free energy penalty class that suppresses the formation of a third phase in grain boundaries
8.11.4The system shall provide a material for computing barrier values in multiphase systems
8.11.5The system shall provide a material for computing independent barrier values for each phase pair in a multiphase system
8.11.6The system shall provide a material for computing independent barrier values for each phase pair in a multiphase system with asymmetric interface profiles
8.11.7The system shall provide a lagrange multiplier based constraint for keeping the sum of all phase order parameters equal to one
8.11.8The system shall provide a penalty based constraint for keeping the sum of all phase order parameters equal to one
8.11.9The system shall provide an AuxKernel to compute the free energy contribution form pairwise phase barrier functions
8.11.10The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions
8.11.11The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions, and some order parameters may be aux variables
8.11.12The system shall provide switching functions for three-phase KKS phase-field model
8.11.13The system shall provide switching functions for multi-phase KKS phase-field model
8.11.14The system shall provide mixed switching functions with order 234 and 246 and an adjustable weight
8.11.15The system shall provide order 246 polynomials in the two phase barrier function

phase_field: Multismoothcircleic
8.12.1We shall be able to generate multiple smooth circle initial conditions with uniform radius variation type
8.12.2We shall be able to generate multiple smooth circle initial conditions with normal radius variation type
8.12.3We shall be able to produce a lattice of smooth circle initial conditions, allowing the circles to exist on the simulation cell boundaries and using a uniform radius variation type
8.12.4We shall be able to produce a lattice of smooth circle initial conditions, using a uniform radius variation type
8.12.5We shall be able to produce a lattice of smooth circle initial conditions using a normal radius variation type
8.12.6We shall be able to create multiple SpecifiedSmoothCircleICs with a small invalue
8.12.7We shall be able to create several SpecifiedSmoothCircleICs with a standard invalue

phase_field: Nucleation
8.13.1The nucleation material shall generate a free energy contribution proportional to the map value
8.13.2The nucleation system shall insert nuclei in a manner independen of the domain decomposition and parallelization
8.13.3The nucleation system shall recoverable
8.13.4The nucleation system shall recoverable
8.13.5The nucleation system shall recoverable
8.13.6The nucleation system shall recoverable
8.13.7The map shall provide the capability of defining soft interfaces for initial nuclei
8.13.8The marker shall trigger refinement of the nucleus insertion area
8.13.9The nucleation time step porocessor shall return a timestep limit that can be applied to cut the simulation timestep as new nuclei are inserted
8.13.10The nucleation data porocessor shall return the number of currently active nuclei or whether a change to the nucleus list has occurred
8.13.11The nucleation auxkernel evaluates the nucleation map onto an elemental aux variable
8.13.12The nucleation force kernel returns a forcing function based on the nucleation map
8.13.13The discrete nucleation system shall provide a deterministic nucleus inserter that uses tabulated time and location data from a file. This test assigns fixed radius
8.13.14The discrete nucleation system shall provide a deterministic nucleus inserter that uses tabulated time and location data from a file. This test assigns variable radius

phase_field: Polynomialfreeenergy
8.14.1
8.14.2
8.14.3
8.14.4
8.14.5
8.14.6

phase_field: Simpleacinterface
8.15.1
8.15.2

phase_field: Soretdiffusion
8.16.1A temperature gradient driving force for diffusion shall be added to the split form of the Cahn-Hilliard equation.
8.16.2A temperature gradient driving force for diffusion shall be added to the split form of the Cahn-Hilliard equation, where temperature is a coupled non-linear variable
8.16.3A temperature gradient driving force for diffusion shall be added to the non-split form of the Cahn-Hilliard equation.
8.16.4A temperature gradient driving force for diffusion shall be added to the non-split form of the Cahn-Hilliard equation, where temperature is a coupled non-linear variable

phase_field: Splitch
8.17.1
8.17.2

phase_field: Totalfreeenergy
8.18.1We shall be able to calculate the free energy (with one variable) using an AuxKernel
8.18.2We shall be able to calculate the free energy (with two variables) using an AuxKernel

phase_field: Actions
8.19.1The phase field module shall provide an action to set up an Allen-Cahn problem
8.19.2The NonconservedAction shall correctly set up Allen-Cahn problems with higher order elements
8.19.3The NonconservedAction shall correctly set up Allen-Cahn problems with variable dependent mobilities
8.19.4The NonconservedAction shall correctly set up Allen-Cahn problems with multiple order parameters
8.19.5The phase field module shall provide an action to set up a non-split Cahn-Hilliard problem
8.19.6The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem
8.19.7The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem with higher order elements
8.19.8The phase field module shall provide an action to set up a non-split Cahn-Hilliard problem with variable dependent mobilities
8.19.9The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem with variable dependent mobilities
8.19.10The phase field module NonconservedAction and ConservedAction can be combined to construct a coupled Allen-Chan and split Cahn-Hilliard problem
8.19.11The phase field module NonconservedAction and ConservedAction can be combined to construct a coupled Allen-Chan and non-split Cahn-Hilliard problem
8.19.12The phase field module shall provide an action to set up a forward split Cahn-Hilliard problem
8.19.13The phase field module shall provide an action to set up grain growth problems
8.19.14The action to set up grain growth problems shall be able to set up an AD version of the problem which yields the same results as the non-AD version
8.19.15The action to set up grain growth problems shall be able to set up an AD version of the problem which yields the same results as the non-AD version
8.19.16The grain growth action shall have the ability to set up problems with a pinning particle
8.19.17The grain growth action shall have the ability to set up problems with a temperature gradient
8.19.18The GrandPotentialAction shall have the ability to generate kernels

phase_field: Ad Coupled Gradient Dot
8.20.1The phase field module shall be able to compute the gradient of the rate of the variable using automatic differentiation.

phase_field: Anisotropic Interfaces
8.21.1
8.21.2

phase_field: Anisotropic Mobility
8.22.1A split Cahn-Hilliard kernel with an anisotropic mobility shall be provided
8.22.2A non-split Cahn-Hilliard kernel with an anisotropic mobility shall be provided
8.22.3A Diffusion kernel with an anisotropic material property diffusivity shall be provided
8.22.4AD Diffusion with an anisotropic material property diffusivity shall agree with the non-AD version
8.22.5AD Diffusion with an anisotropic material property diffusivity shall have a perfect Jacobian

phase_field: Automatic Differentiation
8.23.1The system shall provide an automatic differentiation mat reaction kernel
8.23.2The Jacobian for the automatic differentiation mat reaction kernel shall be perfect

phase_field: Boundary Intersecting Features
8.24.1The FeatureVolumeVectorPostprocessor shall capture volume information of individual features.
8.24.2The FeatureVolumeVectorPostprocessor shall capture whether any feature intersects the boundary, even when the non-root rank doesn't own a part of the feature that intersects the boundary.

phase_field: Conserved Noise
8.25.1A system to supply a noise field with a domain integral of zero shall be provided
8.25.2A system to supply a normal distributed noise field with a domain integral of zero shall be provided
8.25.3A system to supply a uniformly distributed noise field with a domain integral of zero shall be provided
8.25.4A system to supply a normal distributed noise field with an amplitude mask and a domain integral of zero shall be provided
8.25.5The conserved noise kernel shall error out with a helpful message if a 'seed' parameter is supplied

phase_field: Electrochem Sintering
8.26.1The system shall provide a Grand Potential based electrochemical sintering model

phase_field: Feature Flood Test
8.27.1
8.27.2
8.27.3

phase_field: Feature Volume Vpp Test
8.28.1The FeatureVolumeVectorPostprocessor shall output individual centroid locations when requested.
8.28.2The FeatureVolumeVectorPostprocessor shall output individual centroid locations when requested.
8.28.3The FeatureVolumeVectorPostprocessor shall output whether a percolated pathway exists between specified primary_percolation_boundaries and secondary_percolation_boundaries.
8.28.4The FeatureVolumeVectorPostprocessor shall output whether a percolated pathway exists between specified primary_percolation_boundaries and secondary_percolation_boundaries.
8.28.5The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by integrating the corresponding order parameter on the boundary.
8.28.6The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by calulating the area/length of boundary elements.
8.28.7The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by integrating the corresponding order parameter on the boundary.
8.28.8The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by calulating the area/length of boundary elements.
8.28.9The FeatureVolumeVectorPostprocessor shall output grain centroid locations over multiple time steps

phase_field: Flood Counter Aux Test
8.29.1
8.29.2
8.29.3
8.29.4
8.29.5
8.29.6

phase_field: Flood Counter Periodic Test
8.30.1

phase_field: Free Energy Material
8.31.1The system shall provide an object to compute the Helmholtz free energy density of an ideal gas.
8.31.2The system shall provide an object to compute the Helmholtz free energy density of a Van der Waals gas.
8.31.3
The system shall provide an object to compute a simple polynomial double well free energy
1. hardcoded in C++ and applied to a non-split Cahn-Hilliard system
2. hardcoded in C++ and applied to a split Cahn-Hilliard system
3. implemented using the ExpressionBuilder system and applied to a non-split Cahn-Hilliard system
4. implemented using the ExpressionBuilder system and applied to a split Cahn-Hilliard system
5. implemented using the ExpressionBuilder system, correctly differentiating between variable names and corresponding parser symbol names (which are input parameter names)
8.31.4
The system shall provide an object to compute the Helmholtz free energy density of a binary regular solution
1. with a coupled temperature variable
2. with a default temperature of 300K
3. with a specified constant temperature
4. with a the logarithm functions replaced by a Taylor expansion below a given threshold value
8.31.5
The system shall provide an object to compute the a free energy and its chemical potentials for up to four constituents from a set of MooseFunction objects
1. with a script for tabulating grain growth energies provided
2. using a pre-tabulated free energy through PiecewiseMultilinear functions

phase_field: Functions
8.32.1A function that returns a new periodic random field with a lower wavelength cut-off shall be provided.

phase_field: Grain Boundary Area
8.33.1
8.33.2

phase_field: Grain Growth
8.34.1The system shall provide a polycrystalline material model with grain growth
8.34.2A flat grain boundary shall not move along a temperature gradient
8.34.3A thumb shaped grain IC shall be provided for direct comparison to grain boundary mobility experiments
8.34.4A hexagonal grain structure IC shall be provided
8.34.5A hexagonal grain structure IC shall be provided using KDTree
8.34.6A bicrystal grain IC shall be provided to set up a rectangular grain in a matrix
8.34.7The grain boundary evolution model shall be able to compute the grain boundary mobility based on an activation energy
8.34.8The grain boundary evolution model shall permit specifying a constant mobility
8.34.9The grain boundary evolution model shall provide off-diagonal Jacobians
8.34.10The grain growth model shall work with explicit time integration
8.34.11A voronoi tesselation grain structure IC shall be provided
8.34.12The system shall support a faux voronoi tesselation grain structure IC without using FeatureFloodCount when the number of grains equal to the number of order parameters
8.34.13The system shall be able to apply mesh adaptivity and solve phase field equations on a mesh generated in parallel.
8.34.14The system shall be able to apply mesh adaptivity and solve phase field equations using PolycrystalVoronoi UO on a mesh generated in parallel.
8.34.15The system shall be able to apply mesh adaptivity and output evaluable and ghosting elements using distributed generator
8.34.16A columnar grain IC shall be provided based on a 2D voronoi tesselation
8.34.17The grain boundary evolution model shall provide coupling to conserved order parameters

phase_field: Grain Tracker Test
8.35.1The system shall properly create and track grains when using the Nodal mode of the GrainTracker algorithm.
8.35.2The system shall properly create and track grains when using the Elemental mode of the GrainTracker algorithm.
8.35.3The PolycrystalVoronoi object shall create a valid coloring for a given number of grains and order parameters.
8.35.4The PolycrystalUserObject base class shall error when a valid coloring cannot be found when using the simple back-tracking algorithm.
8.35.5The PolycrystalUserObject base class shall error when a valid coloring cannot be found when using the built-in PETSc based stochastic algorithms.
8.35.6The GrainTracker/PolycrystalUserObject base class shall support having only a grain halo bleeding over a periodic edge.
8.35.7The GrainTracker object shall support remapping order parameter values.
8.35.8The FeatureFloodCount object shall distribute the merging of features when the processor count exceeds number of order parameters for efficiency.
8.35.9The GrainTracker object shall properly checkpoint unique grain information in serial.
8.35.10The GrainTracker object shall properly recover unique grain information in serial.
8.35.11The GrainTracker object shall properly checkpoint unique grain information in parallel.
8.35.12The GrainTracker object shall properly recover unique grain information in parallel.
8.35.13The GrainTracker shall support reusing the data structures from the PolycrystalUserObjectBase after the initial condition for efficiency.
8.35.14The GrainTracker shall support maintaining reserve order parameters for simulations where new grains can form.
8.35.15The GrainTracker shall support beginning a simulation with no active grain structure.
8.35.16
The GrainTracker shall support reading EBSD data to create initial conditions where IDs in the data:
1. are contigious starting at zero,
2. are contigious starting not starting at zero,
3. and arbitrary with gaps.
8.35.17The GrainTracker shall support reading EBSD data to create initial conditions while supporting initial condition refinement.
8.35.18The GrainTracker shall support handling the splitting of a grain during a simulation.
8.35.19The AverageFeatureVolume Postprocessor shall calculate the average volume of each active grain in a simulation.
8.35.20The GrainTracker shall support a mode where it can continue even when it fails to remap for post-modern analysis and debugging.
8.35.21The system shall properly create PolycrystalICs with halo extensions (elements) when using DistributedMesh.
8.35.22The system shall properly handle a single feature or grain taking up the entire domain.
8.35.23The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Nodal.
8.35.24The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Elemental.
8.35.25The system shall output individual grain tracker volumes.
8.35.26The system shall output individual grain tracker volumes assigning each element to only one grain (conservative).
8.35.27The system shall output individual grain tracker volumes when the number of order parameters equals the number of grains.

phase_field: Initial Conditions
8.36.1The system shall support a ramp or linear initial condition in one dimension.
8.36.2The system shall support the creation of a smooth cross initial condition.
8.36.3
The system shall support ellipsoidal phase-field initial conditions:
1. bimodal inverse superellipsoidal structures,
2. bimodal superellipsoidal structures,
3. smooth superellipsoidal structures,
4. smooth superellipsoidal structures specified from a file,
5. smooth superellipsoidal structures in 3D,
6. multiple smooth superellipsoidal structures in 2D, and
7. multiple smooth superellipsoidal structures in 3D.
8.36.4
The system shall support polycrystal phase-field initial conditions:
1. polycrystal structure with diffused interface and periodic BC,
2. polycrystal structure with diffused interface and periodic BC using KDTree,
3. large polycrystal structure with voids,
4. polycrystal structure with voids,
5. polycrystal structure with voids on a periodic domain,
6. polycrystal structure with voids with centroids specified from a file,
7. polycrystal structure with centroids specified from a file,
8. polycrystal circles specified from a file,
9. polycrystal circles specified from a file that may not appear in the final domain,
10. polycrystal circles specified from an input vector,
11. hexagonal structure, and
12. smooth interface in a triple junction.
8.36.5
The system shall support initial adaptivity based on GB locations:
1. polycrystal structure with IC specifying the GB locations
8.36.6
The system shall support phase-field initial conditions consisting of circle patterns:
1. smooth interface circles,
2. smooth interface spheres,
3. smooth interface circles specified from a file, and
4. smooth interface circles with random noise.
8.36.7
The system shall support phase-field initial conditions consisting of close pack particle patterns:
1. in 2D, and
2. in 3D.
8.36.8
The system shall support phase-field initial conditions consiting of box patterns:
1. bounding boxes,
2. bounding boxes with random noise,
3. multiple bounding boxes in 1D,
4. multiple bounding boxes in 2D, and
5. multiple bounding boxes in 3D.
6. Diffused interface can be assigned for isolated bounding boxes in 2D,
7. 3D,
8. nested bounding boxes in 2D, and
9. 3D.
10. Using IsolatedBoundingBoxIC to create overlapping boxes will throw an error.
8.36.9The system shall be able to block-restrict crystal initial conditions.

phase_field: Misc
8.37.1A material shall be implemented that provides dt, time, and time step number as material properties
8.37.2A material shall be implemented that computes the magnitude of the gradient of a given variable
8.37.3An interface kernel shall be implemented to match gradients between two subdomains
8.37.4Demonstrate an InterfaceKernel (InterfaceDiffusionFlux) that can replace a pair of integrated DiffusionFluxBC boundary conditions.
8.37.5An InterfaceKernel set shall be implemented that can enforce the componentwise continuity of the gradient of a variable using the Lagrange multiplier method
8.37.6An initial condition shall be implemented that can set the value of a variable to the value of a function evaluated over a set of up to four coupled variables

phase_field: Mobility Derivative
8.38.1
8.38.2
8.38.3
8.38.4
8.38.5
8.38.6
8.38.7
8.38.8

phase_field: New Initial Conditions
8.39.1A smooth circle initial condition with a hyperbolic tangent profile shall be provided
8.39.2A capability to initialize polycrystal phase field variables from a file mesh shall be provided
8.39.3A capability to initialize polycrystal phase field variables from a file mesh shall be provided through the PolycrystalVariables action
8.39.4A capability to initialize polycrystal phase field variables from a file mesh shall be provided through the GrainGrowth action

phase_field: Phase Field Crystal
8.40.1
8.40.2The system shall support a tolerance approach to handing the natural log when using the Cahn-Hilliard RFF kernel
8.40.3The system shall support a cancelation approach to handing the natural log when using the Cahn-Hilliard RFF kernel
8.40.4The system shall support an expansion approach to handing the natural log when using the Cahn-Hilliard RFF kernel
8.40.5
8.40.6
8.40.7
8.40.8

phase_field: Phase Field Kernels
8.41.1The system shall provide a non-split Cahn-Hilliard formalism
8.41.2The system shall provide a split Cahn-Hilliard formalism
8.41.3The system shall provide an AD version of the split Cahn-Hilliard formalism
8.41.4The system shall provide a perfect Jacobian for the AD split Cahn-Hilliard problem.
8.41.5The system shall provide a kernel option to implement transport terms for the off-diagonal Onsager matrix components
8.41.6The system shall provide a Allen-Cahn phase field formulation.
8.41.7The system shall provide perfect Jacobian contributions for the Allen-Cahn phase field formulation.
8.41.8The system shall provide a Allen-Cahn phase field formulation with a variable dependent mobility.
8.41.9The system shall provide an AD version of the Allen-Cahn phase field formulation.
8.41.10The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem.
8.41.11The system shall provide an AD version of the Allen-Cahn phase field formulation with a variable dependent mobility.
8.41.12The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem with a variable dependent mobility.
8.41.13The system shall provide a coupled Allen-Cahn formulation.
8.41.14The system shall provide a coupled Allen-Cahn formulation with a user defined prefactor.
8.41.15The system shall provide a coupled gradient square kernel.
8.41.16The system shall provide a suite of simple to understand phase field kernels for novice users.
8.41.17The system shall provide a suite of simple to understand phase field kernels for novice users.
8.41.18The system shall provide a free energy contribution from elastic stresses in interfaces.
8.41.19The system shall provide a perfect Jacobian for the free energy contribution from elastic stresses in interfaces.
8.41.20The system shall verify that the barrier height and gradient energy parameter must be permitted to depend on non-linear variables.

phase_field: Polycrystal Diffusion
8.42.1The system shall provide a material to assign location specific diffusivities in a polycrysatal structure, compatible with multiphase switching functions
8.42.2The system shall provide a material to assign location specific diffusivities in a polycrysatal structure, compatible with any use-specified switching functions

phase_field: Reconstruction
8.43.1The system shall output an RGB field that can be interpreted as either a component or a combined Euler angle given a grain structure.
8.43.2The system shall support reading EBSD data and initializing a Polycrystal grain structure with that data.
8.43.3The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment.
8.43.4The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment on a distributed mesh.
8.43.5The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment on a distributed mesh with pre-refinement to allow for adaptive coarsening.
8.43.6The system shall support grain evolution when beginning from EBSD ICs.
8.43.7The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs.
8.43.8The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs while supporting reduced order parameter IC assignment.
8.43.9The system shall support reading EBSD data to initialize PolycrystalICs with discontinuous numbering.
8.43.10The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs while supporting reduced order parameter IC assignment and display the coloring.
8.43.11The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs and support regions within the domain that contain no grains at all.
8.43.12The system shall support grain evolution when beginning from EBSD ICs and compute average orientation of non-uniformly oriented grains.

phase_field: Rigidbodymotion
8.44.1
8.44.2
8.44.3
8.44.4
8.44.5
8.44.6
8.44.7
8.44.8
8.44.9
8.44.10

phase_field: Solution Rasterizer
8.45.1
8.45.2

Usability Requirements

Performace Requirements

System Interfaces

System Operations

Human System Integration Requirements

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

Maintainablity

- The latest working version (defined as the version that passes all tests in the current regression test suite) shall be publicly available at all times through the repository host provider. - Flaws identified in the system shall be reported and tracked in a ticket or issue based system. The technical lead will determine the severity and priority of all reported issues and assign resources at his or her discretion to resolve identified issues. - The software maintainers will entertain all proposed changes to the system in a timely manner (within two business days). - The core framework in its entirety will be made publicly available under the GNU Lesser General Public License (LGPL) version 2.0 license.

Reliability

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

System Modes and States

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

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

note

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

Phyisical Characteristics

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

Environmental Conditions

Not Applicable

System Security

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

Information Management

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

Polices and Regulations

MOOSE-based applications must comply with all export control restrictions.

System Life Cycle Sustainment

MOOSE-based development follows various agile methods. The system is continuously built and deployed in a piecemeal fashion since objects within the system are more or less independent. Every new object requires a test, which in turn requires an associated requirement and design description. Some MOOSE-based development teams follow the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing MOOSE source code. However, some MOOSE-based applications maybe be export controlled in which case all export control restrictions must be adhered to when packaging and shipping media.

Verification

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

Introduction
System Overview
References
Definitions and Acronyms
System Requirements
Verification