Xfem 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 Software Design Description (SDD) specific to the Xfem application.

Introduction

Frameworks are a software development construct aiming to simplify the creation of specific classes of applications through abstraction of low-level details. The main object of creating a framework is to provide an interface to application developers that saves time and provides advanced capabilities not attainable otherwise. The MOOSE, mission is just that: provide a framework for engineers and scientists to build state-of-the-art, computationally scalable finite element based simulation tools.

MOOSE was conceived with one major objective: to be as easy and straightforward to use by scientists and engineers as possible. MOOSE is meant to be approachable by non-computational scientists who have systems of partial differential equations (PDEs) they need to solve. Every single aspect of MOOSE was driven by this singular principle from the build system to the API to the software development cycle. At every turn, decisions were made to enable this class of users to be successful with the framework. The pursuit of this goal has led to many of the unique features of MOOSE:

  • A streamlined build system

  • An API aimed at extensible

  • Straightforward APIs providing sensible default information

  • Integrated, automatic, and rigorous testing

  • Rapid, continuous integration development cycle

  • Codified, rigorous path for contributing

  • Applications are modular and composable

Each of these characteristics is meant to build trust in the framework by those attempting to use it. For instance, the build system is the first thing potential framework users come into contact with when they download a new software framework. Onerous dependency issues, complicated, hard to follow instructions or build failure can all result in a user passing on the platform. Ultimately, the decision to utilize a framework comes down to whether or not you trust the code in the framework and those developing it to be able to support your desired use-case. No matter the technical capabilities of a framework, without trust users will look elsewhere. This is especially true of those not trained in software development or computational science.

Developing trust in a framework goes beyond utilizing "best practices" for the code developed, it is equally important that the framework itself is built upon tools that are trusted. For this reason, MOOSE relies on a well-established code base of libMesh and PETSc. The libMesh library provides foundational capability for the finite element method and provides interfaces to leading-edge numerical solution packages such as PETSc.

With these principles in mind, an open source, massively parallel, finite element, multiphysics framework has been conceived. MOOSE is an on-going project started in 2008 aimed toward a common platform for creation of new multiphysics tools. This document provides design details pertinent to application developers as well as framework developers.

Use Cases

The MOOSE Framework is targeted at two main groups of actors: Developers and Users. Developers are the main use case. These are typically students and professionals trained in science and engineering fields with some level of experience with coding but typically very little formal software development training. The other user group is Users. Those who intend to use an application built upon the framework without writing any computer code themselves. Instead they may modify or create input files for driving a simulation, run the application, and analyze the results. All interactions through MOOSE are primarily through the command-line interface and through a customizable block-based input file.

System Purpose

The Software Design Description provided here is description of each object in the system. The pluggable architecture of the framework 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 framework, modules and derivative applications. More information about the design documentation can be found in Documenting MOOSE.

System Scope

The purpose of this software is to provide several libraries that can be used to build an application based upon the framework. Additionally, several utilities are provided for assisting developers and users in end-to-end FEM analysis. A brief overview of the major components are listed here:

ComponentDescription
framework libraryThe base system from which all MOOSE-based applications are created
module librariesOptional "physics" libraries that may be used in an application to provide capability
build systemThe system responsible for creating applications for a series of libraries and applications
test harnessThe extendable testing system for finding, scheduling, running, and reporting regression tests
"peacock"The graphical user interface (GUI) for building input files, executing applications, and displaying results
MooseDocsThe extendable markdown system for MOOSE providing common documentation and requirements enforcement
"stork"The script and templates for generating a new MOOSE-based application ready for building and testing
examplesA set of complete applications demonstrating the use of MOOSE's pluggable systems
tutorialsStep by step guides to building up an application using MOOSE's pluggable systems
unitAn application for unit testing individual classes or methods of C++ code

Dependencies and Limitations

The MOOSE platform has several dependencies on other software packages and has scope that is constantly evolving based upon funding, resources, priorities, and lab direction. However, the software is open-source and many features and even bugs can be offloaded to developers with appropriate levels of knowledge and direction from the main design team. The primary list of software dependencies is listed below. This list is not meant to be exhaustive. Individual operating systems may require specific packages to be installed prior to using MOOSE, which can be found on the Install MOOSE pages.

Software DependencyDescription
libMeshFinite Element Library and I/O routines
PETScSolver Package
hypreMultigrid Preconditioner
MPIA distributed parallel processing library (MPICH)

Figure 1: A diagram of the MOOSE code platform.

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

- 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
FEMFinite Element Method
GUIgraphical user interface
HITHierarchical Input Text
HPCHigh Performance Computing
I/OInput/Output
INLIdaho National Laboratory
MOOSEMultiphysics Object Oriented Simulation Environment
MPIMessage Passing Interface
PDEspartial differential equations
SDDSoftware Design Description

Design Stakeholders and Concerns

Design Stakeholders

Stakeholders for MOOSE include several of the funding sources including Department of Energy, Nuclear Energy (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, MOOSE 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, MOOSE 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 framework itself is composed of a wide range of pluggable systems. Each system is generally composed of a single or small set of C++ objects intended to be specialized by a Developer to solve a specific problem. To accomplish this design goal, MOOSE uses several modern object-oriented design patterns. The primary overarching pattern is the "Factory Pattern". Users needing to extend MOOSE may inherit from one of MOOSE's systems to providing an implementation meeting his or her needs. The design of each of these systems is documented on the mooseframework.org wiki in the Tutorial section. Additionally, up-to-date documentation extracted from the source is maintained on the the mooseframework.org documentation site after every successful merge to MOOSE's stable branch. After these objects are created, the can be registered with the framework and used immediately in a MOOSE input file.

System Structure

The MOOSE framework architecture consists of a core and several pluggable systems. The core of MOOSE consists of a number of key objects responsible for setting up and managing the user-defined objects of a finite element simulation. This core set of objects has limited extendability and exist for every simulation configuration that the framework is capable of running.

Adaptivity

Adaptivity/Indicators

Adaptivity/Markers

AuxKernels

AuxKernels/MatVecRealGradAuxKernel

AuxKernels/MaterialVectorAuxKernel

AuxKernels/MaterialVectorGradAuxKernel

AuxScalarKernels

AuxVariables

AuxVariables/MultiAuxVariables

BCs

BCs/CavityPressure

BCs/CoupledPressure

BCs/InclinedNoDisplacementBC

BCs/Periodic

BCs/Pressure

Bounds

Closures

Components

Constraints

Contact

ControlLogic

Controls

CoupledHeatTransfers

Covariance

DGKernels

Dampers

Debug

Debug/MaterialDerivativeTest

DeprecatedBlock

DiracKernels

Distributions

DomainIntegral

Executioner

Executioner/Adaptivity

Executioner/Predictor

Executioner/Quadrature

Executioner/TimeIntegrator

Executioner/TimeStepper

Executors

FVBCs

FVInterfaceKernels

FVKernels

FluidPropertiesInterrogator

Functions

GeochemicalModelInterrogator

GlobalParams

GrayDiffuseRadiation

HeatStructureMaterials

ICs

ICs/PolycrystalICs

ICs/PolycrystalICs/BicrystalBoundingBoxIC

ICs/PolycrystalICs/BicrystalCircleGrainIC

ICs/PolycrystalICs/PolycrystalColoringIC

ICs/PolycrystalICs/PolycrystalRandomIC

ICs/PolycrystalICs/PolycrystalVoronoiVoidIC

ICs/PolycrystalICs/Tricrystal2CircleGrainsIC

InterfaceKernels

Kernels

Kernels/CHPFCRFFSplitKernel

Kernels/DynamicTensorMechanics

Kernels/HHPFCRFFSplitKernel

Kernels/PFCRFFKernel

Kernels/PolycrystalElasticDrivingForce

Kernels/PolycrystalKernel

Kernels/PolycrystalStoredEnergy

Kernels/PoroMechanics

Kernels/RigidBodyMultiKernel

Kernels/TensorMechanics

Materials

Mesh

Mesh/Partitioner

Modules

Modules/CompressibleNavierStokes

Modules/FluidProperties

Modules/HeatConduction

Modules/HeatConduction/ThermalContact

Modules/HeatConduction/ThermalContact/BC

Modules/IncompressibleNavierStokes

Modules/NavierStokesFV

Modules/Peridynamics

Modules/Peridynamics/Mechanics

Modules/Peridynamics/Mechanics/GeneralizedPlaneStrain
Modules/Peridynamics/Mechanics/Master

Modules/PhaseField

Modules/PhaseField/Conserved

Modules/PhaseField/DisplacementGradients

Modules/PhaseField/EulerAngles2RGB

Modules/PhaseField/GrainGrowth

Modules/PhaseField/GrandPotential

Modules/PhaseField/Nonconserved

Modules/PorousFlow

Modules/PorousFlow/BCs

Modules/TensorMechanics

Modules/TensorMechanics/CohesiveZoneMaster

Modules/TensorMechanics/DynamicMaster

Modules/TensorMechanics/GeneralizedPlaneStrain

Modules/TensorMechanics/GlobalStrain

Modules/TensorMechanics/LineElementMaster

Modules/TensorMechanics/Master

Modules/TensorMechanics/MaterialVectorBodyForce

MortarGapHeatTransfer

MultiApps

NodalKernels

NodalNormals

Outputs

PorousFlowBasicTHM

PorousFlowFullySaturated

PorousFlowUnsaturated

Postprocessors

Preconditioning

Problem

RayBCs

RayKernels

ReactionNetwork

ReactionNetwork/AqueousEquilibriumReactions

ReactionNetwork/SolidKineticReactions

Reporters

Samplers

ScalarKernels

SpatialReactionSolver

StochasticTools

Surrogates

ThermalContact

TimeDependentReactionSolver

TimeIndependentReactionSolver

Trainers

Transfers

UserObjects

Variables

Variables/CHPFCRFFSplitVariables

Variables/HHPFCRFFSplitVariables

Variables/PFCRFFVariables

Variables/PolycrystalVariables

VectorPostprocessors

XFEM

The MooseApp is the top-level object used to hold all of the other objects in a simulation. In a normal simulation a single MooseApp object is created and "run()". This object uses it's Factory objects to build user defined objects which are stored in a series of Warehouse objects and executed. The Finite Element data is stored in the Systems and Assembly object while the domain information (the Mesh) is stored in the Mesh object. A series of threaded loops are used to run parallel calculations on the objects created and stored within the warehouses.

MOOSE's pluggable systems are documented on the mooseframework.org wiki. Each of these systems has set of defined polymorphic interfaces and are designed to accomplish a specific task within the simulation. The design of these systems is fluid and is managed through agile methods and ticket request system on the Github.org website.

Data Design and Control

At a high level, the system is designed to process Hierarchical Input Text (HIT) input files to construct several objects that will constitute an finite element (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

MOOSE is a command-line driven program. All interaction with MOOSE and MOOSE-based codes 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 Input/Output (I/O) or through local Application Programming Interface (API) calls. Neither the framework, nor the 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 framework 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

  • xfem: LevelSetCutUserObject
  • 9.1.1The XFEM module shall have the capability to calculate mechanical response in two glued, layered materials with the interface location and material properties applied to on each side of the boundary determined by a level set function.

    Specification(s): glued_bimaterial

    Design: LevelSetCutUserObjectXFEMSingleVariableConstraint

    Issue(s): #10421

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.1.2The XFEM module shall have the capability to calculate mechanical response in a composite material matrix with an inclusion with the location of the inclusion boundary and material properties applied to the matrix and inclusion determined by a prescribed level set function.

    Specification(s): inclusion_bimaterial

    Design: LevelSetCutUserObjectXFEMSingleVariableConstraint

    Issue(s): #10421

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.5.3The XFEM Module shall have the capability to run 2D diffusion problems with a fixed position discontinuous interface defined by the location of the zero values of a level set function with the level set variable being a Moose Variable.

    Specification(s): levelsetcut2d

    Design: LevelSetCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.5.4The XFEM Module shall have the capability to run 2D diffusion problems with a fixed position discontinuous interface defined by the location of the zero values of a prescribed level set function with the level set variable being a Moose AuxVariable.

    Specification(s): levelsetcut2d_aux

    Design: LevelSetCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.5.5The XFEM Module shall have the capability to run 3D diffusion problems with a fixed position discontinuous interface defined by the location of the zero values of a prescribed level set function with the level set variable being a Moose AuxVariable.

    Specification(s): levelsetcut3d

    Design: LevelSetCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.1The XFEM module shall provide an ability to specify whether an XFEM cut surface should be healed independently for individual interfaces

    Specification(s): moving_interface

    Design: LineSegmentCutSetUserObjectLevelSetCutUserObject

    Issue(s): #11259

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.10The XFEM module shall provide an ability to solve bi-material diffusion problems where a moving material interface is defined by an XFEM surface, which is defined by a prescribed level set field.

    Specification(s): moving_diffusion

    Design: LevelSetBiMaterialRealXFEMEqualValueAtInterfaceLevelSetCutUserObject

    Issue(s): #11749

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.17The XFEM module shall accurately solve 1D, xy problems with homogeneous material properties with a moving interface determined by a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 1D_xy_homog1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.18The XFEM module shall accurately solve 1D, xy problems with material properties and a moving interface dependent on a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 1D_xy_lsdep1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.19The XFEM module shall accurately solve 1D, xy problems with a moving interface separating two discrete materials prescribed by a user defined level set function with problem results verified using the Method of Manufactured Solutions.

    Specification(s): 1D_xy_discrete2mat

    Design: LevelSetCutUserObjectXFEMSingleVariableConstraint

    Issue(s): #13756

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.20The XFEM module shall accurately solve 1D, rz problems with homogeneous material properties with a moving interface determined by a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 1D_rz_homog1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.21The XFEM module shall accurately solve 1D, rz problems with material properties and a moving interface dependent on a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 1D_rz_lsdep1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.22The XFEM module shall accurately solve 2D, xy problems with homogeneous material properties with a moving interface determined by a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 2D_xy_homog1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.23The XFEM module shall accurately solve 2D, xy problems with material properties and a moving interface dependent on a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 2D_xy_lsdep1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.24The XFEM module shall accurately solve 2D, rz problems with homogeneous material properties with a moving interface determined by a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 2D_rz_homog1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.25The XFEM module shall accurately solve 2D, rz problems with material properties and a moving interface dependent on a user prescribed level set function, and problem results are verified using the Method of Manufactured Solutions.

    Specification(s): 2D_rz_lsdep1mat

    Design: LevelSetCutUserObject

    Issue(s): #12833

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: Checkpoint
  • 9.2.1The XFEM module shall support outputting of checkpoint files.

    Specification(s): checkpoint

    Design: Checkpoint

    Issue(s): #17063

    Collection(s): FUNCTIONAL

    Type(s): CheckFiles

  • xfem: LineSegmentCutUserObject
  • 9.3.1The XFEM module shall have the capability of cutting directly through multiple nodes of a single QUAD4 element in 2D.

    Specification(s): corner_node_cut_twice

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.3.2The XFEM module shall be able to perform mesh cuts on any combination of the edges of elements and through elements including allowing cuts that go through the nodes on the same mesh.

    Specification(s): corner_edge_cut

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.3.3The XFEM module shall have the capability of perfoming mesh cuts on the edges of elements such that only two new nodes are generated to separate the previously connected elements.

    Specification(s): corner_node_cut

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.3.4The XFEM module shall be capable of propagating an existing crack front along a prescribed cut in 2D.

    Specification(s): notch

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.4.1The XFEM module shall have the capability to include near-tip enrichment functions in 2D mechanics simulations.

    Specification(s): crack_tip_enrichment_edge_2d

    Design: LineSegmentCutUserObjectCrackTipEnrichmentStressDivergenceTensors

    Issue(s): #10042

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.5.1The XFEM Module shall have the capability to run 2D diffusion problems with prescribed values on the domain boundary (Dirichlet conditions) with a fixed position discontinuous interface through mesh elements.

    Specification(s): diffusion_xfem

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.5.2The XFEM Module shall have the capability to run 2D diffusion problems with prescribed solution values on the domain boundary (Dirichlet conditions) and prescribed boundary flux values (Neumann conditions) with a fixed position discontinuous interface defined by a geometric cut user object.

    Specification(s): diffusion_xfem_flux_bc

    Design: LineSegmentCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: XFEM
  • 9.6.1The XFEM module shall retain the values of auxiliary variables on child nodes and elements after running the cutting algorithm, and initialize solution variables on newly created nodes with values from parent nodes in parallel

    Specification(s): init_solution_propagation

    Design: XFEM

    Issue(s): #8763

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.7.1The XFEM module shall permit applying a glued constraint across the XFEM interface for 2D solid mechanics problems.

    Specification(s): glued_penalty

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.8.1The XFEM module shall permit the use of the moment fitting algorithm to compute integration point weights for partial elements on 2D solid mechanics problems

    Specification(s): solid_mechanics_moment_fitting

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.8.2The XFEM module shall permit the use of the moment fitting algorithm to compute integration point weights for partial elements on 2D problems with a 4-point integration rule

    Specification(s): diffusion_moment_fitting_four_points

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.8.3The XFEM module shall permit the use of the moment fitting algorithm to compute integration point weights for partial elements on 2D problems with a 6-point integration rule

    Specification(s): diffusion_moment_fitting_six_points

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.9.2The XFEM module shall not output summary information on mesh changes when debug_output_level=0

    Specification(s): moving_interface_debug_output_0

    Design: XFEM

    Issue(s): #13666

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 9.9.3The XFEM module shall output summary information on mesh changes when debug_output_level=1

    Specification(s): moving_interface_debug_output_1

    Design: XFEM

    Issue(s): #13666

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 9.9.4The XFEM module shall output detailed information on mesh changes when debug_output_level=2

    Specification(s): moving_interface_debug_output_2

    Design: XFEM

    Issue(s): #13666

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 9.9.5The XFEM module shall output detailed information on mesh changes when debug_output_level=3

    Specification(s): moving_interface_debug_output_3

    Design: XFEM

    Issue(s): #13666

    Collection(s): FUNCTIONAL

    Type(s): RunApp

  • 9.11.1The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 2D using TRI6 elements.

    Specification(s): diffusion_2d_tri6

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.2The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 2D using QUAD8 elements.

    Specification(s): diffusion_2d_quad8

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.3The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 2D using QUAD9 elements.

    Specification(s): diffusion_2d_quad9

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.4The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 2D using QUAD9 elements when the XFEM cutting plane is prescribed using a level set field.

    Specification(s): diffusion_quad9_levelsetcut

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.5The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 3D using TET10 elements when the XFEM cutting plane is prescribed using a level set field.

    Specification(s): diffusion_3d_tet10

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.6The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 3D using HEX20 elements when the XFEM cutting plane is prescribed using a level set field.

    Specification(s): diffusion_3d_hex20

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.7The XFEM module shall permit modeling of discontinuities represented with XFEM with second-order elements in 3D using HEX27 elements when the XFEM cutting plane is prescribed using a level set field.

    Specification(s): diffusion_3d_hex27

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.8The XFEM module shall permit modeling of branching of discontinuities represented with XFEM by sequentially cutting second-order elements in 2D using QUAD8 elements.

    Specification(s): square_branch_quad8_2d

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.9The XFEM module shall permit modeling of branching of discontinuities represented with XFEM by sequentially cutting second-order elements in 2D using QUAD9 elements.

    Specification(s): square_branch_quad9_2d

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.11.10The XFEM module shall permit modeling of branching of discontinuities represented with XFEM by sequentially cutting second-order elements in 2D using TRI6 elements.

    Specification(s): square_branch_tri6_2d

    Design: XFEM

    Issue(s): #8709

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.12.1The XFEM module shall properly integrate quantities on sides of cut elements that are intersected by the cutting plane in 2D

    Specification(s): side_integral_xfem

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.12.2The XFEM module shall properly integrate quantities on sides of cut elements that are intersected by the cutting plane in 3D

    Specification(s): side_integral_3d_xfem

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.11The XFEM system shall permit branched cracks to be represented in 2D by sequentially cutting a 4-noded quadrilateral element by two prescribed evolving cutting planes

    Specification(s): square_branch_quad_2d

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.12The XFEM system shall permit branched cracks to be represented in 2D by sequentially cutting a 3-noded triangle element by two prescribed evolving cutting planes

    Specification(s): square_branch_tri_2d

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.13The XFEM system shall provide an accessor function to the crack_tip_origin_direction_map

    Specification(s): test_crack_counter

    Design: XFEM

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

  • xfem: XFEMPressure
  • 9.10.1The XFEM module shall permit application of pressure boundary conditions to XFEM cut surfaces in 2D

    Specification(s): edge_2d_pressure

    Design: XFEMPressure

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.10.2The XFEM module shall permit application of pressure boundary conditions to XFEM cut surfaces in 3D

    Specification(s): edge_3d_pressure

    Design: XFEMPressure

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.10.3The XFEM module shall permit application of pressure boundary conditions to inclined XFEM cut surfaces in 2D

    Specification(s): inclined_edge_2d_pressure

    Design: XFEMPressure

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.10.4The XFEM module shall permit application of pressure boundary conditions to XFEM cut surfaces in 2D finite deformation simulations

    Specification(s): 2d_pressure_displaced_mesh

    Design: XFEMPressure

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: XFEMRankTwoTensorMarkerUserObject
  • 9.15.1The XFEM module shall represent a propagating crack in a 2D mechanics problem in which crack growth occurs when the average stress in the element at the crack tip exceeds a critical value.

    Specification(s): crack_propagation_ave

    Design: XFEMRankTwoTensorMarkerUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.2The XFEM module shall represent a propagating crack in a 2D mechanics problem in which crack growth occurs when the average stress in the element at the crack tip exceeds a critical value defined by the value of a field variable.

    Specification(s): crack_propagation_var

    Design: XFEMRankTwoTensorMarkerUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.3The XFEM module shall represent a propagating crack in a 2D mechanics problem in which crack growth occurs when the stress at any of the quadrature points in the element at the crack tip exceeds a critical value defined by the value of a field variable.

    Specification(s): crack_propagation_single_point

    Design: XFEMRankTwoTensorMarkerUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: RectangleCutUserObject
  • 9.15.4The XFEM module shall permit definition of a stationary crack in a 3D mechanics model with XFEM, where the crack is defined using a rectangular cutting plane by RectangleCutUserObject

    Specification(s): edge_crack_3d

    Design: RectangleCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: CrackMeshCut3DUserObject
  • 9.15.5The XFEM module shall represent a propagating crack in a 3D mechanics model with XFEM, where the crack is defined using a topologically surface cutting mesh by CrackMeshCut3DUserObject and allowed to propagate with growth speeds determined by the fatigue cracking Paris law

    Specification(s): edge_crack_3d_fatigue

    Design: CrackMeshCut3DUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.6The XFEM module shall represent a propagating crack in a 3D mechanics model with XFEM, where the crack is defined using a topologically surface cutting mesh by CrackMeshCut3DUserObject and allowed to propagate with growth directions determined by the maximum hoop stress law

    Specification(s): edge_crack_3d_mhs

    Design: CrackMeshCut3DUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.7The XFEM module shall represent a propagating crack in a 3D mechanics model with XFEM, where the crack is defined using a topologically surface cutting mesh by CrackMeshCut3DUserObject

    Specification(s): edge_crack_3d_propagation

    Design: CrackMeshCut3DUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: EllipseCutUserObject
  • 9.15.8The XFEM module shall permit definition of a stationary crack in a 3D mechanics model with XFEM, where the crack is defined using an elliptical cutting plane by EllipseCutUserObject

    Specification(s): elliptical_crack

    Design: EllipseCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • xfem: DomainIntegral System
  • 9.15.9The XFEM system shall permit computation of fracture domain integrals in 3D mechanics problems where a stationary embedded circular crack is defined by a cutting plane geometry and points along the crack front for the domain integral are explicitly specified.

    Specification(s): penny_crack

    Design: DomainIntegral SystemCircleCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

  • 9.15.10The XFEM system shall permit computation of fracture domain integrals in 3D mechanics problems where a stationary embedded circular crack is defined by a cutting plane geometry and points along the crack front for the domain integral provided by a class that derives from CrackFrontPointsProvider.

    Specification(s): penny_crack_cfp

    Design: DomainIntegral SystemCircleCutUserObject

    Issue(s): #6320

    Collection(s): FUNCTIONAL

    Type(s): Exodiff