Phase Field System Design Description

This template follows INL template TEM-140, "IT System Design Description."

commentnote

This document serves as an addendum to Framework System Design Description and captures information for SDD specific to the Phase Field module.

Introduction

Computing microstructure evolution of materials is important for a variety of applications. These can employ a variety of assumptions of material behavior, and can be either run as standalone single-physics problems or as coupled multiphysics problems to study the evolution with that of other physics. The MOOSE Phase Field module provides a foundational set of models for modeling microstructure evolution. This module relies on MOOSE for solving its system of equations, and is designed to be readily extended or coupled with other physics models. This document describes the system design of the Phase Field module.

System Purpose

The Software Design Description provided here is description of each object in the system. The pluggable architecture of the underlying framework of the Phase Field module makes MOOSE and MOOSE-based applications straightforward to develop as each piece of end-user (developer) code that goes into the system follows a well-defined interface for the underlying systems that those object plug into. These descriptions are provided through developer-supplied "markdown" files that are required for all new objects that are developed as part of the Phase Field module. More information about the design documentation for MOOSE-based applications and like the Phase Field module can be found in Documenting MOOSE.

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.

Dependencies and Limitations

The MOOSE Phase Field module inherits the software dependencies of the MOOSE framework, with no additional dependencies.

Definitions and Acronyms

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

Definitions

  • Pull (Merge) Request: A proposed change to the software (e.g. usually a code change, but may also include documentation, requirements, design, and/or testing).

  • Baseline: A specification or product (e.g., project plan, maintenance and operations (M&O) plan, requirements, or design) that has been formally reviewed and agreed upon, that thereafter serves as the basis for use and further development, and that can be changed only by using an approved change control process (NQA-1, 2009).

  • Validation: Confirmation, through the provision of objective evidence (e.g., acceptance test), that the requirements for a specific intended use or application have been fulfilled (24765:2010(E), 2010).

  • 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
APIApplication Programming Interface
DOE-NEDepartment of Energy, Nuclear Energy
FEfinite element
HITHierarchical Input Text
HPCHigh Performance Computing
I/OInput/Output
INLIdaho National Laboratory
MOOSEMultiphysics Object Oriented Simulation Environment
MPIMessage Passing Interface
SDDSoftware Design Description

Design Stakeholders and Concerns

Design Stakeholders

Stakeholders for MOOSE include several of the funding sources including DOE-NE and the INL. However, Since MOOSE is an open-source project, several universities, companies, and foreign governments have an interest in the development and maintenance of the MOOSE project.

Stakeholder Design Concerns

Concerns from many of the stakeholders are similar. These concerns include correctness, stability, and performance. The mitigation plan for each of these can be addressed. For correctness, Phase Field module development requires either regression or unit testing for all new code added to the repository. The project contains several comparisons against analytical solutions where possible and also other verification methods such as MMS. For stability, the Phase Field module (located within the MOOSE repository) maintains multiple branches to incorporate several layers of testing both internally and for dependent applications. Finally, performance tests are also performed as part of the the normal testing suite to monitor code change impacts to performance.

System Design

The MOOSE Phase Field module relies on MOOSE to solve the governing equations for the phase field method, which can include contributions from the thermodynamic potentials provided by this module, elastic energy contributions from mechanical deformation, and temperature fields solved using the heat transfer module. The design of MOOSE is based on the concept of modular code objects that define all of the aspects of the physics model. This module follows this design, providing code objects that define specific aspects of the solutions for its physics that derive from the base classes defined by the MOOSE framework and the modules that it depends on.

The Phase Field module provides specialized Kernel classes that compute the contributions from the terms in the partial differential equations governing the evolution of phase fields. In addition, it provides IC, BC, Action, Marker, MeshGenerator, Function, AuxKernel, Postprocessor and VectorPostprocessor classes to facilitate various aspects of these simulations.

System Structure

The MOOSE Phase Field module relies on the MOOSE framework to provide the core functionality of solving multiphysics problems using the finite element method. The structure of the Phase Field module is based on defining C++ classes that derive from base classes in the MOOSE framework to provide functionality for the solution of phase field problems. By using the interfaces defined in MOOSE for these classes, this module is able to rely on MOOSE to execute these models at the appropriate times during the simulation and use their results in the desired ways.

Data Design and Control

At a high level, the system is designed to process HIT input files to construct several objects that will constitute an FE simulation. Some of the objects in the simulation may in turn load other file-based resources to complete the simulation. Examples include meshes or data files. The system will then assemble systems of equations and solve them using the libraries of the Code Platform. The system can then output the solution in one or more supported output formats commonly used for visualization.

Human-Machine Interface Design

The Phase Field module is a command-line driven program. All interaction with the Phase Field module is ultimately done through the command line. This is typical for HPC applications that use the MPI interface for running on super computing clusters. Optional GUIs may be used to assist in creating input files and launching executables on the command line.

System Design Interface

All external system interaction is performed either through file I/O or through local API calls. Neither the Phase Field module, nor the MOOSE framework, nor the other MOOSE modules are designed to interact with any external system directly through remote procedure calls. Any code to code coupling performed using the framework are done directly through API calls either in a static binary or after loading shared libraries.

Security Structure

The Phase Field module does not require any elevated privileges to operate and does not run any stateful services, daemons or other network programs. Distributed runs rely on the MPI library.

Requirements Cross-Reference

  • phase_field: GBAnisotropy
  • 12.6.1A material shall be provided to compute anisotropic grain boundary energies and mobilities.

    Specification(s): test1

    Design: GBAnisotropy

    Issue(s): #4580

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.6.2A material shall be provided to compute anisotropic grain boundary energies and mobilities.

    Specification(s): test2

    Design: GBAnisotropy

    Issue(s): #4580

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.6.3A material shall be provided to compute anisotropic grain boundary energies and mobilities with an inclination dependence.

    Specification(s): test3

    Design: GBAnisotropy

    Issue(s): #4580

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: GBWidthAnisotropy
  • 12.6.4The anisotropic grain boundary system shall allow the user to specify grain boundary widths independently for each interface between grains.

    Specification(s): testwidth1

    Design: GBWidthAnisotropy

    Issue(s): #8079

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: KKSCHBulk
  • 12.10.2A non-split version of the Kim-Kim-Suzuki shall be provided

    Specification(s): kks_example

    Design: KKSCHBulk

    Issue(s): #4835

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: ACMultiInterface
  • 12.12.10The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions

    Specification(s): acmultiinterface

    Design: ACMultiInterface

    Issue(s): #4545

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.12.11The system shall provide an Allen-Cahn gradient energy kernel with cross term contributions, and some order parameters may be aux variables

    Specification(s): acmultiinterface_aux

    Design: ACMultiInterface

    Issue(s): #4545

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: MultiSmoothCircleIC
  • 12.13.1We shall be able to generate multiple smooth circle initial conditions with uniform radius variation type

    Specification(s): multi_test

    Design: MultiSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.13.2We shall be able to generate multiple smooth circle initial conditions with normal radius variation type

    Specification(s): multi_normal_test

    Design: MultiSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: LatticeSmoothCircleIC
  • 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

    Specification(s): lattice_bounds

    Design: LatticeSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.13.4We shall be able to produce a lattice of smooth circle initial conditions, using a uniform radius variation type

    Specification(s): lattice_test

    Design: LatticeSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.13.5We shall be able to produce a lattice of smooth circle initial conditions using a normal radius variation type

    Specification(s): lattice_normal_test

    Design: LatticeSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.13.6We shall be able to create multiple SpecifiedSmoothCircleICs with a small invalue

    Specification(s): lattice_small_invalue_test

    Design: LatticeSmoothCircleIC

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: DiscreteNucleationData
  • 12.14.10The nucleation data porocessor shall return the number of currently active nuclei or whether a change to the nucleus list has occurred

    Specification(s): data

    Design: DiscreteNucleationData

    Issue(s): #12114

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • phase_field: DiscreteNucleationFromFile
  • 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

    Specification(s): file

    Design: DiscreteNucleationFromFile

    Issue(s): #12262

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): file2

    Design: DiscreteNucleationFromFile

    Issue(s): #14544

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: SoretDiffusion
  • 12.17.1A temperature gradient driving force for diffusion shall be added to the split form of the Cahn-Hilliard equation.

    Specification(s): split

    Design: SoretDiffusion

    Issue(s): #5324

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): split_temp

    Design: SoretDiffusion

    Issue(s): #5324

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.17.3A temperature gradient driving force for diffusion shall be added to the non-split form of the Cahn-Hilliard equation.

    Specification(s): direct

    Design: SoretDiffusion

    Issue(s): #5324

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): direct_temp

    Design: SoretDiffusion

    Issue(s): #5324

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: TotalFreeEnergy
  • 12.19.1We shall be able to calculate the free energy (with one variable) using an AuxKernel

    Specification(s): TotalFreeEnergy

    Design: TotalFreeEnergy

    Issue(s): #4413

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.19.2We shall be able to calculate the free energy (with two variables) using an AuxKernel

    Specification(s): 2var

    Design: TotalFreeEnergy

    Issue(s): #4413

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: GrainGrowthAction
  • 12.20.13The phase field module shall provide an action to set up grain growth problems

    Specification(s): grain_growth

    Design: GrainGrowthAction

    Issue(s): #9485

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): ad_grain_growth

    Design: GrainGrowthAction

    Issue(s): #13539

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 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

    Specification(s): ad_grain_growth-jac

    Design: GrainGrowthAction

    Issue(s): #13539

    Collection(s): FUNCTIONAL

    Type(s): PetscJacobianTester

  • 12.20.16The grain growth action shall have the ability to set up problems with a pinning particle

    Specification(s): grain_growth_with_c

    Design: GrainGrowthAction

    Issue(s): #9485

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.20.17The grain growth action shall have the ability to set up problems with a temperature gradient

    Specification(s): grain_growth_with_T_grad

    Design: GrainGrowthAction

    Issue(s): #9485

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.40.4A capability to initialize polycrystal phase field variables from a file mesh shall be provided through the GrainGrowth action

    Specification(s): GrainGrowth_initial_from_file

    Design: GrainGrowthAction

    Issue(s): #13624

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: Coupleable
  • 12.21.1The phase field module shall be able to compute the gradient of the rate of the variable using automatic differentiation.

    Specification(s): diffusionrate

    Design: Coupleable

    Issue(s): #16167

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • phase_field: Langevin Noise
  • 12.25.1A system to supply a noise field with a domain integral of zero shall be provided

    Specification(s): integral

    Design: Langevin Noise

    Issue(s): #4763

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.25.2A system to supply a normal distributed noise field with a domain integral of zero shall be provided

    Specification(s): normal

    Design: Langevin Noise

    Issue(s): #4763

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.25.3A system to supply a uniformly distributed noise field with a domain integral of zero shall be provided

    Specification(s): uniform

    Design: Langevin Noise

    Issue(s): #4763

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.25.4A system to supply a normal distributed noise field with an amplitude mask and a domain integral of zero shall be provided

    Specification(s): integral_normal_masked

    Design: Langevin Noise

    Issue(s): #4763

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.25.5The conserved noise kernel shall error out with a helpful message if a 'seed' parameter is supplied

    Specification(s): seed_error

    Design: Langevin Noise

    Issue(s): #4763

    Collection(s): FAILURE_ANALYSISFUNCTIONAL

    Type(s): RunException

  • phase_field: FeatureFloodCount
  • 12.29.1The feature flood counter system shall be able to track contiguous regions in a simulation domain, based on a vaiable value

    Specification(s): test

    Design: FeatureFloodCount

    Issue(s): #5077

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.29.2The feature flood counter system shall be able to track multiple variables at once, with features being sets of elements.

    Specification(s): test_elemental

    Design: FeatureFloodCount

    Issue(s): #5077

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.29.3The feature flood counter system shall be able to track multiple variables at once, with features being sets of nodes.

    Specification(s): simple

    Design: FeatureFloodCount

    Issue(s): #5077

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.29.5The feature flood counter system shall be able to track multiple variables at once with periodic boundary conditions.

    Specification(s): two_var

    Design: FeatureFloodCount

    Issue(s): #5077

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.29.6The feature flood counter system shall be restrictable to a boundary.

    Specification(s): bound_restrict_single

    Design: FeatureFloodCount

    Issue(s): #11813

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.29.7The feature flood counter system shall be restrictable to multiple boundaries.

    Specification(s): bound_restrict_all

    Design: FeatureFloodCount

    Issue(s): #11813

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

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

    Specification(s): boundary_intersection

    Design: FeatureFloodCountFeatureFloodCountAux

    Issue(s): #23246

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.29.9The system shall report an error if a nodal variable is specified as the target for the intersection status.

    Specification(s): boundary_intersection_error

    Design: FeatureFloodCountFeatureFloodCountAux

    Issue(s): #23246

    Collection(s): FAILURE_ANALYSISFUNCTIONAL

    Type(s): RunException

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

    Specification(s): fourier_noise

    Design: FourierNoise

    Issue(s): #13316

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: PolycrystalHex
  • 12.34.4A hexagonal grain structure IC shall be provided

    Specification(s): hex

    Design: PolycrystalHex

    Issue(s): #8810

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.34.5A hexagonal grain structure IC shall be provided using KDTree

    Specification(s): hex_kdtree

    Design: PolycrystalHex

    Issue(s): #8810

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: FauxPolycrystalVoronoi
  • 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

    Specification(s): faux_voronoi

    Design: FauxPolycrystalVoronoi

    Issue(s): #14697

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: GrainTracker
  • 12.36.1The system shall properly create and track grains when using the Nodal mode of the GrainTracker algorithm.

    Specification(s): test_nodal

    Design: GrainTracker

    Issue(s): #4765

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.2The system shall properly create and track grains when using the Elemental mode of the GrainTracker algorithm.

    Specification(s): test_elemental

    Design: GrainTracker

    Issue(s): #4881

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.3The PolycrystalVoronoi object shall create a valid coloring for a given number of grains and order parameters.

    Specification(s): test_advanced_op_assignment

    Design: GrainTracker

    Issue(s): #7005#9018

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.6The GrainTracker/PolycrystalUserObject base class shall support having only a grain halo bleeding over a periodic edge.

    Specification(s): test_halo_periodic_bc

    Design: GrainTracker

    Issue(s): #6713#8926

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.7The GrainTracker object shall support remapping order parameter values.

    Specification(s): test_remapping_serial

    Design: GrainTracker

    Issue(s): #1298

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.8The FeatureFloodCount object shall distribute the merging of features when the processor count exceeds number of order parameters for efficiency.

    Specification(s): test_remapping_parallel

    Design: GrainTracker

    Issue(s): #11805

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.9The GrainTracker object shall support remapping order parameter values with nonlinear preconditioning.

    Specification(s): test_remapping_linearized_interface

    Design: GrainTracker

    Issue(s): #21938#21940#25419

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.10The GrainTracker object shall properly checkpoint unique grain information in serial.

    Specification(s): test_recovery_serial_part1

    Design: GrainTracker

    Issue(s): #6713#12427

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 12.36.11The GrainTracker object shall properly recover unique grain information in serial.

    Specification(s): test_recovery_serial_part2

    Design: GrainTracker

    Issue(s): #6713#12427

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.12The GrainTracker object shall properly checkpoint unique grain information in parallel.

    Specification(s): test_recovery_parallel_part1

    Design: GrainTracker

    Issue(s): #6713#12427

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 12.36.13The GrainTracker object shall properly recover unique grain information in parallel.

    Specification(s): test_recovery_parallel_part2

    Design: GrainTracker

    Issue(s): #6713#12427

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.15The GrainTracker shall support maintaining reserve order parameters for simulations where new grains can form.

    Specification(s): remapping_with_reserve

    Design: GrainTracker

    Issue(s): #7605

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.16The GrainTracker shall support beginning a simulation with no active grain structure.

    Specification(s): start_with_zero_grains

    Design: GrainTracker

    Issue(s): #12200

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.19The GrainTracker shall support handling the splitting of a grain during a simulation.

    Specification(s): split_grain

    Design: GrainTracker

    Issue(s): #7875

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.20The AverageFeatureVolume Postprocessor shall calculate the average volume of each active grain in a simulation.

    Specification(s): changing_avg_volume

    Design: GrainTracker

    Issue(s): #11822

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.21The GrainTracker shall support a mode where it can continue even when it fails to remap for post-modern analysis and debugging.

    Specification(s): tolerate_remap_failure

    Design: GrainTracker

    Issue(s): #11843

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 12.36.23The system shall properly handle a single feature or grain taking up the entire domain.

    Specification(s): one_grain

    Design: GrainTracker

    Issue(s): #12216

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.24The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Nodal.

    Specification(s): test_faux_nodal

    Design: GrainTracker

    Issue(s): #5453

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.25The system shall grain tracking behavior even when the number of grains equals the number of order parameters when using mode Elemental.

    Specification(s): test_faux_element

    Design: GrainTracker

    Issue(s): #5453

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.36.26The system shall output individual grain tracker volumes.

    Specification(s): grain_tracker_volume

    Design: GrainTracker

    Issue(s): #7769

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.27The system shall output individual grain tracker volumes assigning each element to only one grain (conservative).

    Specification(s): grain_tracker_volume_single

    Design: GrainTracker

    Issue(s): #7769

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • 12.36.28The system shall output individual grain tracker volumes when the number of order parameters equals the number of grains.

    Specification(s): feature_flood_volume

    Design: GrainTracker

    Issue(s): #5453

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • phase_field: CHPFCRFF
  • 12.41.2The system shall support a tolerance approach to handing the natural log when using the Cahn-Hilliard RFF kernel

    Specification(s): tolerance_test

    Design: CHPFCRFF

    Issue(s): #5338

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.41.3The system shall support a cancelation approach to handing the natural log when using the Cahn-Hilliard RFF kernel

    Specification(s): cancelation_test

    Design: CHPFCRFF

    Issue(s): #5338

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.41.4The system shall support an expansion approach to handing the natural log when using the Cahn-Hilliard RFF kernel

    Specification(s): expansion_test

    Design: CHPFCRFF

    Issue(s): #5338

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: SplitCHWRes
  • 12.42.5The system shall provide a kernel option to implement transport terms for the off-diagonal Onsager matrix components

    Specification(s): SplitCHWRes

    Design: SplitCHWRes

    Issue(s): #14140

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: AllenCahn
  • 12.42.6The system shall provide a Allen-Cahn phase field formulation.

    Specification(s): AllenCahn

    Design: AllenCahn

    Issue(s): #3816

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.42.7The system shall provide perfect Jacobian contributions for the Allen-Cahn phase field formulation.

    Specification(s): analyzejacobian_AllenCahn

    Design: AllenCahn

    Issue(s): #3816

    Collection(s): FUNCTIONAL

    Type(s): AnalyzeJacobian

  • 12.42.8The system shall provide a Allen-Cahn phase field formulation with a variable dependent mobility.

    Specification(s): AllenCahnVariableL

    Design: AllenCahn

    Issue(s): #3816

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • phase_field: ADAllenCahn
  • 12.42.9The system shall provide an AD version of the Allen-Cahn phase field formulation.

    Specification(s): ADAllenCahn

    Design: ADAllenCahn

    Issue(s): #13197

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.42.10The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem.

    Specification(s): ADAllenCahn-jac

    Design: ADAllenCahn

    Issue(s): #13197

    Collection(s): FUNCTIONAL

    Type(s): PetscJacobianTester

  • 12.42.11The system shall provide an AD version of the Allen-Cahn phase field formulation with a variable dependent mobility.

    Specification(s): ADAllenCahnVariableL

    Design: ADAllenCahn

    Issue(s): #13197

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.42.12The system shall calculate a perfect Jacobian for the AD Allen-Cahn problem with a variable dependent mobility.

    Specification(s): ADAllenCahnVariableL-jac

    Design: ADAllenCahn

    Issue(s): #13197

    Collection(s): FUNCTIONAL

    Type(s): PetscJacobianTester

  • phase_field: Reading EBSD Data
  • 12.44.2The system shall support reading EBSD data and initializing a Polycrystal grain structure with that data.

    Specification(s): 1phase_reconstruction

    Design: Reading EBSD Data

    Issue(s): #9110

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.44.3The system shall support reading EBSD data to initalized Polycrystal grain structures while supporting reduced order parameter IC assignment.

    Specification(s): 1phase_reconstruction_40x40

    Design: Reading EBSD Data

    Issue(s): #9110

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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

    Specification(s): 1phase_reconstruction_40x40_distributed

    Design: Reading EBSD Data

    Issue(s): #19150

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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

    Specification(s): 1phase_reconstruction_40x40_distributed_pre_refine

    Design: Reading EBSD Data

    Issue(s): #19150

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.44.6The system shall support grain evolution when beginning from EBSD ICs.

    Specification(s): 1phase_evolution

    Design: Reading EBSD Data

    Issue(s): #9110

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.44.7The system shall support reading a single phase of EBSD data at a time to initialize PolycrystalICs.

    Specification(s): 2phase_reconstruction

    Design: Reading EBSD Data

    Issue(s): #9110#5920

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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

    Specification(s): 2phase_reconstruction2

    Design: Reading EBSD Data

    Issue(s): #9110#5920

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 12.44.9The system shall support reading EBSD data to initialize PolycrystalICs with discontinuous numbering.

    Specification(s): 2phase_reconstruction3

    Design: Reading EBSD Data

    Issue(s): #9110#5920

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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

    Specification(s): 2phase_reconstruction4

    Design: Reading EBSD Data

    Issue(s): #9110#5920

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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

    Specification(s): regions_without_grains

    Design: Reading EBSD Data

    Issue(s): #9110#5920

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • phase_field: EBSDReader
  • 12.44.12The system shall support grain evolution when beginning from EBSD ICs and compute average orientation of non-uniformly oriented grains.

    Specification(s): average_orientation

    Design: EBSDReader

    Issue(s): #13869

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

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]