Phase Field System Requirements Specification

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

commentnote

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

Introduction

System Purpose

The purpose of the MOOSE Phase Field module is to provide the foundational capabilities for phase field modeling of microstructure evolution. It implements common single- and multi-phase phase field formalisms and enables the modeling of multicomponent systems. It is intended to both provide a basic set of capabilities and also be readily extensible by applications based on it to represent specialized material behavior.

System Scope

The MOOSE Phase Field module provides an extensible set of capabilities for solving for microstructural evolution of multi-phase and multi-component systems using conserved and non-conserved order parameters. It provides a set of C++ classes that define interfaces for MOOSE Kernel objects that implement various common phase field formulations including polycrystalline grain growth models. These models support one-, two-, and three-dimensional simulation domains.

For modeling nucleation events the module includes a discrete nucleation system that supports nucleation based on order parameter pinning and artificial driving force insertion which enable nucleation events in conserved and non-conserved order parameter fields. Support is provided for physics informed timestepping and mesh refinement.

Utilities for free energy extraction from thermodynamic databases are provided, as well as a phase field model that supports sublattice concentration models found in thermodynamic databases.

The module also comprises a set of initial conditions to set up common microstructures used in phase field modeling.

System Overview

System Context

The Phase Field module is command-line driven. Like MOOSE, this is typical for a high-performance software that is designed to run across several nodes of a cluster system. As such, all 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. The Phase Field module does not maintain any back-end database or interact with any system daemons. It is an executable, which may be launched from the command line and writes out various result files as it runs.

Figure 1: Usage of the Phase Field module and other MOOSE-based applications.

System Functions

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

User Characteristics

Like MOOSE, there are three kinds of users working on the Phase Field module:

  • Phase Field module Developers: These are the core developers of the Phase Field module. They are responsible for following and enforcing the software development standards of the module, as well as designing, implementing, and maintaining the software.

  • Developers: A scientist or engineer that uses the Phase Field module alongside MOOSE to build their own application. This user will typically have a background in modeling or simulation techniques (and perhaps numerical analysis) but may only have a limited skillset when it comes to code development using the C++ language. This is the primary focus group of the module. In many cases, these developers will be encouraged to contribute module-appropriate code back to the Phase Field module, or to MOOSE itself.

  • Analysts: These are users that will run the code and perform 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 module is developed using MOOSE and can itself be based on various MOOSE modules, as such the SRS for the Phase Field module is dependent upon the files listed at the beginning of this document. Any further assumptions or dependencies are outlined in the remainder of this section.

The Phase Field module has no constraints on hardware and software beyond those of the MOOSE framework. The Phase Field module provides access to a number of code objects that perform computations such as material behavior and boundary conditions. These objects each make their own physics-based assumptions, such as the units of the inputs and outputs. Those assumptions are described in the documentation for those individual objects.

References

  1. ISO/IEC/IEEE 24765:2010(E). Systems and software engineering—Vocabulary. first edition, December 15 2010.[BibTeX]
  2. 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

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

AcronymDescription
INLIdaho National Laboratory
LGPLGNU Lesser General Public License
MOOSEMultiphysics Object Oriented Simulation Environment
NQA-1Nuclear Quality Assurance Level 1
POSIXPortable Operating System Interface
SRSSoftware Requirement Specification

System Requirements

In general, the following is required for MOOSE-based development:

  • GCC/Clang C++17 compliant compiler (GCC @ 7.5.0, Clang @ 10.0.1 or greater)

    • Note: Intel compilers are not supported.

  • Memory: 8 GBs of RAM for optimized compilation (16 GBs for debug compilation), 2 GB per core execution

  • Processor: 64-bit x86 or ARM64 (specifically, Apple Silicon)

  • Disk: 30GB

  • A POSIX compliant Unix-like operating system, including the two most recent versions of MacOS and most current versions of Linux.

  • Git version control system

  • Python @ 3.7 or greater

Functional Requirements

  • phase_field: Adchsoretdiffusion
  • 12.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.
  • 12.1.2The Jacobians for the automatic differentiation ADCHSplitChemicalPotential and ADCHSplitConcentration kernels shall be accurate.
  • phase_field: Adchsplitchemicalpotential
  • 12.2.1ADCHSplitChemicalPotential and ADCHSplitConcentration shall solve a simple Cahn-Hilliard problem using automatic differentiation.
  • 12.2.2The Jacobians for the automatic differentiation ADCHSplitChemicalPotential and ADCHSplitConcentration kernels shall be accurate.
  • phase_field: Chsplitchemicalpotential
  • 12.3.1
  • phase_field: Deformedgrain
  • 12.4.1
  • phase_field: Ebsdmeshgenerator
  • 12.5.1The 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
  • 12.6.1A material shall be provided to compute anisotropic grain boundary energies and mobilities.
  • 12.6.2A material shall be provided to compute anisotropic grain boundary energies and mobilities.
  • 12.6.3A material shall be provided to compute anisotropic grain boundary energies and mobilities with an inclination dependence.
  • 12.6.4The anisotropic grain boundary system shall allow the user to specify grain boundary widths independently for each interface between grains.
  • phase_field: Gbtype
  • 12.7.1The system shall output GB type for all GBs.
  • 12.7.2The system shall assign local diffusivity.
  • phase_field: Grain Velocity Computation
  • 12.8.1The system shall be able to provide a velocity vector field indicating grain boundary movement for visualization purposes.
  • phase_field: Grandpotentialpfm
  • 12.9.1The system shall provide classes to implement a Grand Potential phase field formulation
  • 12.9.2The system shall provide a Grand Potential based multiphase model
  • 12.9.3The system shall provide a Grand Potential based dendritic solidification capability in 2D
  • 12.9.4The system shall provide classes to implement a Grand Potential phase field formulation with strict mass conservation
  • 12.9.5The system shall provide a material to automatically compute grand potential model interface parameters based on provided interfacial free energies and widths
  • 12.9.6The system shall provide a Grand Potential based dendritic solidification capability for alloy with antitrapping current
  • 12.9.7The system shall provide a Grand Potential based sintering model
  • 12.9.8The system shall provide a Grand Potential based sintering model with parabolic defect free energies
  • 12.9.9The system shall provide a Grand Potential based sintering model with dilute solution defect free energies
  • 12.9.10The system shall provide a Grand Potential based sintering model with ideal solution defect free energies
  • 12.9.11MOOSE shall provide a Grand Potential based multiphase model with AD option
  • 12.9.12The jacobian for the AD Allen-Cahn problem with a variable dependent coeffecients shall be perfect
  • phase_field: Kks System
  • 12.10.1The Kim-Kim-Suzuki model implementation shall use free energy densities provided by DerivativeParsedMaterials
  • 12.10.2A non-split version of the Kim-Kim-Suzuki shall be provided
  • 12.10.3A split version of the Kim-Kim-Suzuki shall be provided
  • 12.10.4The split version of the Kim-Kim-Suzuki shall be yield the correct results with asymmetric free energies
  • 12.10.5A multi component Kim-Kim-Suzuki model shall be implemented
  • 12.10.6A multi component Kim-Kim-Suzuki model shall be implemented
  • 12.10.7The system shall produce the same equilibrium solution for
    1. the dedicated two phase one order parameter formulation.
    2. the general Lagrange multiplier enforced multiphase formulation with two order parameters.
    3. a two order parameter system, where the second order parameter is an auxiliary variable.
    4. a two order parameter system, where the second order parameter is an prescribed nonlinear variable.
  • 12.10.8The nested solve of Kim-Kim-Suzuki shall yield the correct results with non-linear phase free energies
  • phase_field: Maskedbodyforce
  • 12.11.1
  • phase_field: Multiphase
  • 12.12.1The system shall provide a material to combine two free energies materials into a WBM two phase free energy
  • 12.12.2The system shall provide a materials to generate barrier and switching function in a WBM multiphase model
  • 12.12.3The system shall provide a free energy penalty class that suppresses the formation of a third phase in grain boundaries
  • 12.12.4The system shall provide a material for computing barrier values in multiphase systems
  • 12.12.5The system shall provide a material for computing independent barrier values for each phase pair in a multiphase system
  • 12.12.6The system shall provide a material for computing independent barrier values for each phase pair in a multiphase system with asymmetric interface profiles
  • 12.12.7The system shall provide a lagrange multiplier based constraint for keeping the sum of all phase order parameters equal to one
  • 12.12.8The system shall provide a penalty based constraint for keeping the sum of all phase order parameters equal to one
  • 12.12.9The system shall provide an AuxKernel to compute the free energy contribution form pairwise phase barrier functions
  • 12.12.10The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions
  • 12.12.11The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions, and some order parameters may be aux variables
  • 12.12.12The system shall provide switching functions for three-phase KKS phase-field model
  • 12.12.13The system shall provide switching functions for multi-phase KKS phase-field model
  • 12.12.14The system shall provide mixed switching functions with order 234 and 246 and an adjustable weight
  • 12.12.15The system shall provide order 246 polynomials in the two phase barrier function
  • phase_field: Multismoothcircleic
  • 12.13.1We shall be able to generate multiple smooth circle initial conditions with uniform radius variation type
  • 12.13.2We shall be able to generate multiple smooth circle initial conditions with normal radius variation type
  • 12.13.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
  • 12.13.4We shall be able to produce a lattice of smooth circle initial conditions, using a uniform radius variation type
  • 12.13.5We shall be able to produce a lattice of smooth circle initial conditions using a normal radius variation type
  • 12.13.6We shall be able to create multiple SpecifiedSmoothCircleICs with a small invalue
  • 12.13.7We shall be able to create several SpecifiedSmoothCircleICs with a standard invalue
  • phase_field: Nucleation
  • 12.14.1The nucleation material shall generate a free energy contribution proportional to the map value
  • 12.14.2The nucleation system shall insert nuclei in a manner independen of the domain decomposition and parallelization
  • 12.14.3The nucleation system shall recoverable
  • 12.14.4The nucleation system shall recoverable
  • 12.14.5The nucleation system shall recoverable
  • 12.14.6The nucleation system shall recoverable
  • 12.14.7The map shall provide the capability of defining soft interfaces for initial nuclei
  • 12.14.8The marker shall trigger refinement of the nucleus insertion area
  • 12.14.9The nucleation time step porocessor shall return a timestep limit that can be applied to cut the simulation timestep as new nuclei are inserted
  • 12.14.10The nucleation data porocessor shall return the number of currently active nuclei or whether a change to the nucleus list has occurred
  • 12.14.11The nucleation auxkernel evaluates the nucleation map onto an elemental aux variable
  • 12.14.12The nucleation force kernel returns a forcing function based on the nucleation map
  • 12.14.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
  • 12.14.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
  • 12.15.1
  • 12.15.2
  • 12.15.3
  • 12.15.4
  • 12.15.5
  • 12.15.6
  • phase_field: Simpleacinterface
  • 12.16.1
  • 12.16.2
  • phase_field: Soretdiffusion
  • 12.17.1A temperature gradient driving force for diffusion shall be added to the split form of the Cahn-Hilliard equation.
  • 12.17.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
  • 12.17.3A temperature gradient driving force for diffusion shall be added to the non-split form of the Cahn-Hilliard equation.
  • 12.17.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
  • 12.18.1
  • 12.18.2
  • phase_field: Totalfreeenergy
  • 12.19.1We shall be able to calculate the free energy (with one variable) using an AuxKernel
  • 12.19.2We shall be able to calculate the free energy (with two variables) using an AuxKernel
  • phase_field: Actions
  • 12.20.1The phase field module shall provide an action to set up an Allen-Cahn problem
  • 12.20.2The NonconservedAction shall correctly set up Allen-Cahn problems with higher order elements
  • 12.20.3The NonconservedAction shall correctly set up Allen-Cahn problems with variable dependent mobilities
  • 12.20.4The NonconservedAction shall correctly set up Allen-Cahn problems with multiple order parameters
  • 12.20.5The phase field module shall provide an action to set up a non-split Cahn-Hilliard problem
  • 12.20.6The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem
  • 12.20.7The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem with higher order elements
  • 12.20.8The phase field module shall provide an action to set up a non-split Cahn-Hilliard problem with variable dependent mobilities
  • 12.20.9The phase field module shall provide an action to set up a reverse split Cahn-Hilliard problem with variable dependent mobilities
  • 12.20.10The phase field module NonconservedAction and ConservedAction can be combined to construct a coupled Allen-Chan and split Cahn-Hilliard problem
  • 12.20.11The phase field module NonconservedAction and ConservedAction can be combined to construct a coupled Allen-Chan and non-split Cahn-Hilliard problem
  • 12.20.12The phase field module shall provide an action to set up a forward split Cahn-Hilliard problem
  • 12.20.13The phase field module shall provide an action to set up grain growth problems
  • 12.20.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
  • 12.20.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
  • 12.20.16The grain growth action shall have the ability to set up problems with a pinning particle
  • 12.20.17The grain growth action shall have the ability to set up problems with a temperature gradient
  • 12.20.18The GrandPotentialAction shall have the ability to generate kernels
  • phase_field: Ad Coupled Gradient Dot
  • 12.21.1The phase field module shall be able to compute the gradient of the rate of the variable using automatic differentiation.
  • phase_field: Anisotropic Interfaces
  • 12.22.1
  • 12.22.2
  • phase_field: Anisotropic Mobility
  • 12.23.1A split Cahn-Hilliard kernel with an anisotropic mobility shall be provided
  • 12.23.2A non-split Cahn-Hilliard kernel with an anisotropic mobility shall be provided
  • 12.23.3A Diffusion kernel with an anisotropic material property diffusivity shall be provided
  • 12.23.4AD Diffusion with an anisotropic material property diffusivity shall agree with the non-AD version
  • 12.23.5AD Diffusion with an anisotropic material property diffusivity shall have a perfect Jacobian
  • phase_field: Boundary Intersecting Features
  • 12.24.1The FeatureVolumeVectorPostprocessor shall capture volume information of individual features.
  • 12.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
  • 12.25.1A system to supply a noise field with a domain integral of zero shall be provided
  • 12.25.2A system to supply a normal distributed noise field with a domain integral of zero shall be provided
  • 12.25.3A system to supply a uniformly distributed noise field with a domain integral of zero shall be provided
  • 12.25.4A system to supply a normal distributed noise field with an amplitude mask and a domain integral of zero shall be provided
  • 12.25.5The conserved noise kernel shall error out with a helpful message if a 'seed' parameter is supplied
  • phase_field: Electrochem Sintering
  • 12.26.1The system shall provide a Grand Potential based electrochemical sintering model
  • phase_field: Feature Flood Test
  • 12.27.1
  • 12.27.2
  • 12.27.3
  • phase_field: Feature Volume Vpp Test
  • 12.28.1The FeatureVolumeVectorPostprocessor shall output individual centroid locations when requested.
  • 12.28.2The FeatureVolumeVectorPostprocessor shall output individual centroid locations when requested.
  • 12.28.3The FeatureVolumeVectorPostprocessor shall output whether a percolated pathway exists between specified primary_percolation_boundaries and secondary_percolation_boundaries.
  • 12.28.4The FeatureVolumeVectorPostprocessor shall output whether a percolated pathway exists between specified primary_percolation_boundaries and secondary_percolation_boundaries.
  • 12.28.5The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by integrating the corresponding order parameter on the boundary.
  • 12.28.6The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by calulating the area/length of boundary elements.
  • 12.28.7The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by integrating the corresponding order parameter on the boundary.
  • 12.28.8The FeatureVolumeVectorPostprocessor shall calculate coverage of a supplied boundary by each feature by calulating the area/length of boundary elements.
  • 12.28.9The FeatureVolumeVectorPostprocessor shall output grain centroid locations over multiple time steps
  • phase_field: Flood Counter Aux Test
  • 12.29.1The feature flood counter system shall be able to track contiguous regions in a simulation domain, based on a vaiable value
  • 12.29.2The feature flood counter system shall be able to track multiple variables at once, with features being sets of elements.
  • 12.29.3The feature flood counter system shall be able to track multiple variables at once, with features being sets of nodes.
  • 12.29.4The feature flood counter aux kernel shall throw an error when acting on a variable that is incompatible with the flood counter mode.
  • 12.29.5The feature flood counter system shall be able to track multiple variables at once with periodic boundary conditions.
  • 12.29.6The feature flood counter system shall be restrictable to a boundary.
  • 12.29.7The feature flood counter system shall be restrictable to multiple boundaries.
  • 12.29.8The system shall be able to set an elemental aux variable on elements belonging to a tracked feature to indicate whether the feature intersects a sepcified boundary.
  • 12.29.9The system shall report an error if a nodal variable is specified as the target for the intersection status.
  • phase_field: Flood Counter Periodic Test
  • 12.30.1
  • phase_field: Free Energy Material
  • 12.31.1The system shall provide an object to compute the Helmholtz free energy density of an ideal gas.
  • 12.31.2The system shall provide an object to compute the Helmholtz free energy density of a Van der Waals gas.
  • 12.31.3The 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)
    6. implemented using the compile time derivatives system and applied to a split Cahn-Hilliard system
    7. implemented using the compile time derivatives system using automatic differentiation and applied to a split Cahn-Hilliard system
    8. implemented using the compile time derivatives system using automatic differentiation, with correct dual number derivative entries
  • 12.31.4The 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
  • 12.31.5The 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
  • 12.32.1A function that returns a new periodic random field with a lower wavelength cut-off shall be provided.
  • phase_field: Grain Boundary Area
  • 12.33.1
  • 12.33.2
  • phase_field: Grain Growth
  • 12.34.1The system shall provide a polycrystalline material model with grain growth
  • 12.34.2A flat grain boundary shall not move along a temperature gradient
  • 12.34.3A thumb shaped grain IC shall be provided for direct comparison to grain boundary mobility experiments
  • 12.34.4A hexagonal grain structure IC shall be provided
  • 12.34.5A hexagonal grain structure IC shall be provided using KDTree
  • 12.34.6A bicrystal grain IC shall be provided to set up a rectangular grain in a matrix
  • 12.34.7The grain boundary evolution model shall be able to compute the grain boundary mobility based on an activation energy
  • 12.34.8The grain boundary evolution model shall permit specifying a constant mobility
  • 12.34.9The grain boundary evolution model shall provide off-diagonal Jacobians
  • 12.34.10The grain growth model shall work with explicit time integration
  • 12.34.11A voronoi tesselation grain structure IC shall be provided
  • 12.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
  • 12.34.13The system shall be able to apply mesh adaptivity and solve phase field equations on a mesh generated in parallel.
  • 12.34.14The system shall be able to apply mesh adaptivity and solve phase field equations using PolycrystalVoronoi UO on a mesh generated in parallel.
  • 12.34.15The system shall be able to apply mesh adaptivity and output evaluable and ghosting elements using distributed generator
  • 12.34.16A columnar grain IC shall be provided based on a 2D voronoi tesselation
  • 12.34.17The grain boundary evolution model shall provide coupling to conserved order parameters
  • phase_field: Grain Growth W Linearized Interface
  • 12.35.1The system executes a grain growth simulation using linearized interface substitution
  • 12.35.2Action creates the variables, kernels, bounds, etc. for linearized interface with grain growth
  • 12.35.3Initializes linearized interface variables for a voronoi tesselation IC
  • phase_field: Grain Tracker Test
  • 12.36.1The system shall properly create and track grains when using the Nodal mode of the GrainTracker algorithm.
  • 12.36.2The system shall properly create and track grains when using the Elemental mode of the GrainTracker algorithm.
  • 12.36.3The PolycrystalVoronoi object shall create a valid coloring for a given number of grains and order parameters.
  • 12.36.4The PolycrystalUserObject base class shall error when a valid coloring cannot be found when using the simple back-tracking algorithm.
  • 12.36.5The PolycrystalUserObject base class shall error when a valid coloring cannot be found when using the built-in PETSc based stochastic algorithms.
  • 12.36.6The GrainTracker/PolycrystalUserObject base class shall support having only a grain halo bleeding over a periodic edge.
  • 12.36.7The GrainTracker object shall support remapping order parameter values.
  • 12.36.8The FeatureFloodCount object shall distribute the merging of features when the processor count exceeds number of order parameters for efficiency.
  • 12.36.9The GrainTracker object shall support remapping order parameter values with nonlinear preconditioning.
  • 12.36.10The GrainTracker object shall properly checkpoint unique grain information in serial.
  • 12.36.11The GrainTracker object shall properly recover unique grain information in serial.
  • 12.36.12The GrainTracker object shall properly checkpoint unique grain information in parallel.
  • 12.36.13The GrainTracker object shall properly recover unique grain information in parallel.
  • 12.36.14The GrainTracker shall support reusing the data structures from the PolycrystalUserObjectBase after the initial condition for efficiency.
  • 12.36.15The GrainTracker shall support maintaining reserve order parameters for simulations where new grains can form.
  • 12.36.16The GrainTracker shall support beginning a simulation with no active grain structure.
  • 12.36.17The 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.
  • 12.36.18The GrainTracker shall support reading EBSD data to create initial conditions while supporting initial condition refinement.
  • 12.36.19The GrainTracker shall support handling the splitting of a grain during a simulation.
  • 12.36.20The AverageFeatureVolume Postprocessor shall calculate the average volume of each active grain in a simulation.
  • 12.36.21The GrainTracker shall support a mode where it can continue even when it fails to remap for post-modern analysis and debugging.
  • 12.36.22The system shall properly create PolycrystalICs with halo extensions (elements) when using DistributedMesh.
  • 12.36.23The system shall properly handle a single feature or grain taking up the entire domain.
  • 12.36.24The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Nodal.
  • 12.36.25The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Elemental.
  • 12.36.26The system shall output individual grain tracker volumes.
  • 12.36.27The system shall output individual grain tracker volumes assigning each element to only one grain (conservative).
  • 12.36.28The system shall output individual grain tracker volumes when the number of order parameters equals the number of grains.
  • phase_field: Initial Conditions
  • 12.37.1The system shall support a ramp or linear initial condition in one dimension.
  • 12.37.2The system shall support the creation of a smooth cross initial condition.
  • 12.37.3The 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.
  • 12.37.4The 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 in 2D,
    12. hexagonal structure in 3D, and
    13. smooth interface in a triple junction.
  • 12.37.5The system shall support initial adaptivity based on GB locations:
    1. polycrystal structure with IC specifying the GB locations
  • 12.37.6The 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.
  • 12.37.7The system shall support phase-field initial conditions consisting of close pack particle patterns:
    1. in 2D, and
    2. in 3D.
  • 12.37.8The 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.
  • 12.37.9The system shall be able to block-restrict crystal initial conditions.
  • phase_field: Misc
  • 12.38.1A material shall be implemented that provides dt, time, and time step number as material properties
  • 12.38.2A material shall be implemented that computes the magnitude of the gradient of a given variable
  • 12.38.3An interface kernel shall be implemented to match gradients between two subdomains
  • 12.38.4Demonstrate an InterfaceKernel (InterfaceDiffusionFlux) that can replace a pair of integrated DiffusionFluxBC boundary conditions.
  • 12.38.5An InterfaceKernel set shall be implemented that can enforce the componentwise continuity of the gradient of a variable using the Lagrange multiplier method
  • 12.38.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
  • 12.39.1
  • 12.39.2
  • 12.39.3
  • 12.39.4
  • 12.39.5
  • 12.39.6
  • 12.39.7
  • 12.39.8
  • phase_field: New Initial Conditions
  • 12.40.1A smooth circle initial condition with a hyperbolic tangent profile shall be provided
  • 12.40.2A capability to initialize polycrystal phase field variables from a file mesh shall be provided
  • 12.40.3A capability to initialize polycrystal phase field variables from a file mesh shall be provided through the PolycrystalVariables action
  • 12.40.4A capability to initialize polycrystal phase field variables from a file mesh shall be provided through the GrainGrowth action
  • phase_field: Phase Field Crystal
  • 12.41.1
  • 12.41.2The system shall support a tolerance approach to handing the natural log when using the Cahn-Hilliard RFF kernel
  • 12.41.3The system shall support a cancelation approach to handing the natural log when using the Cahn-Hilliard RFF kernel
  • 12.41.4The system shall support an expansion approach to handing the natural log when using the Cahn-Hilliard RFF kernel
  • 12.41.5
  • 12.41.6
  • 12.41.7
  • 12.41.8
  • phase_field: Phase Field Kernels
  • 12.42.1The system shall provide a non-split Cahn-Hilliard formalism
  • 12.42.2The system shall provide a split Cahn-Hilliard formalism
  • 12.42.3The system shall provide an AD version of the split Cahn-Hilliard formalism
  • 12.42.4The system shall provide a perfect Jacobian for the AD split Cahn-Hilliard problem.
  • 12.42.5The system shall provide a kernel option to implement transport terms for the off-diagonal Onsager matrix components
  • 12.42.6The system shall provide a Allen-Cahn phase field formulation.
  • 12.42.7The system shall provide perfect Jacobian contributions for the Allen-Cahn phase field formulation.
  • 12.42.8The system shall provide a Allen-Cahn phase field formulation with a variable dependent mobility.
  • 12.42.9The system shall provide an AD version of the Allen-Cahn phase field formulation.
  • 12.42.10The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem.
  • 12.42.11The system shall provide an AD version of the Allen-Cahn phase field formulation with a variable dependent mobility.
  • 12.42.12The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem with a variable dependent mobility.
  • 12.42.13The system shall provide a coupled Allen-Cahn formulation.
  • 12.42.14The system shall provide a coupled Allen-Cahn formulation with a user defined prefactor.
  • 12.42.15The system shall provide a coupled gradient square kernel.
  • 12.42.16The system shall provide a suite of simple to understand phase field kernels for novice users.
  • 12.42.17The system shall provide a suite of simple to understand phase field kernels for novice users.
  • 12.42.18The system shall provide a free energy contribution from elastic stresses in interfaces.
  • 12.42.19The system shall provide a perfect Jacobian for the free energy contribution from elastic stresses in interfaces.
  • 12.42.20The system shall verify that the barrier height and gradient energy parameter must be permitted to depend on non-linear variables.
  • 12.42.21MOOSE shall have AD examples where the barrier height and gradient energy parameter depend on non-linear variables
  • 12.42.22The Jacobian for the AD Allen-Cahn problem with a variable dependent coeffecients shall be perfect
  • phase_field: Polycrystal Diffusion
  • 12.43.1The system shall provide a material to assign location specific diffusivities in a polycrysatal structure, compatible with multiphase switching functions
  • 12.43.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
  • 12.44.1The system shall output an RGB field that can be interpreted as either a component or a combined Euler angle given a grain structure.
  • 12.44.2The system shall support reading EBSD data and initializing a Polycrystal grain structure with that data.
  • 12.44.3The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment.
  • 12.44.4The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment on a distributed mesh.
  • 12.44.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.
  • 12.44.6The system shall support grain evolution when beginning from EBSD ICs.
  • 12.44.7The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs.
  • 12.44.8The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs while supporting reduced order parameter IC assignment.
  • 12.44.9The system shall support reading EBSD data to initialize PolycrystalICs with discontinuous numbering.
  • 12.44.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.
  • 12.44.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.
  • 12.44.12The system shall support grain evolution when beginning from EBSD ICs and compute average orientation of non-uniformly oriented grains.
  • phase_field: Rigidbodymotion
  • 12.45.1
  • 12.45.2
  • 12.45.3
  • 12.45.4
  • 12.45.5
  • 12.45.6
  • 12.45.7
  • 12.45.8
  • 12.45.9
  • 12.45.10
  • phase_field: Slkks
  • 12.46.1The system shall be able to solve for sublattice concentrations in the SLKKS model.
  • 12.46.2The system shall be able to solve for mass transport, phases, and sublattice concentrations simultaneously in the SLKKS model.
  • 12.46.3The system shall be able to compute the average value of a variable field weighted by a material property.
  • phase_field: Solution Rasterizer
  • 12.47.1
  • 12.47.2

Usability Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

Performance Requirements

No requirements of this type exist for this application, beyond those of its dependencies.

System Interfaces

No requirements of this type exist for this application, beyond those of its dependencies.

System Operations

Human System Integration Requirements

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

Maintainability

  • 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 their 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 software in its entirety will be made available under the terms of a designated software license. These license terms are outlined in the LICENSE file alongside the Phase Field module source code. As a MOOSE physics module, the license for the Phase Field module is identical to that of the framework - that is, the LGPL version 2.1 license.

Reliability

The regression test suite will cover at least 89% of all lines of code within the Phase Field module at all times. Known regressions will be recorded and tracked (see Maintainability) 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 FlagDescription 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(implies -i flag) Execute the simulation but use pre-split mesh files instead of the mesh from the input file
--yamlOutput all object descriptions and available parameters in YAML format
--jsonOutput all object descriptions and available parameters in JSON format
--syntaxOutput all registered syntax
--registryOutput all known objects and actions
--registry-hitOutput 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
commentnote

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.

Physical Characteristics

The Phase Field module is software only with no associated physical media. See System Requirements for a description of the minimum required hardware necessary for running the Phase Field module.

Environmental Conditions

Not Applicable

System Security

MOOSE-based applications such as the Phase Field module have no requirements or special needs related to system security. The software is designed to run completely in user-space with no elevated privileges required nor recommended.

Information Management

The core framework and all modules in their entirety will be made publicly available on an appropriate repository hosting site. Day-to-day backups and security services will be provided by the hosting service. More information about MOOSE backups of the public repository on INL-hosted services can be found on the following page: GitHub Backups

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. The Phase Field module development team follows the NQA-1 standards.

Packaging, Handling, Shipping and Transportation

No special requirements are needed for packaging or shipping any media containing MOOSE and Phase Field module source code. However, some MOOSE-based applications that use the Phase Field module may 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.