Contact 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 Contact module.

Introduction

In simulations of deformable bodies, it is often important to impose constraints on the solutions to ensure that the bodies do not interpenetrate, and to appropriately represent the physical behavior of the interacting surfaces. The MOOSE Contact module provides the capabilities to enforce these mechanical constraints in simulations of deformable bodies. This module relies on MOOSE for solving its system of equations, and works in conjunction with models for the deformation of those bodies provided by the Solid Mechanics module. This document describes the system design of the Contact 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 Contact 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 Contact module. More information about the design documentation for MOOSE-based applications and like the Contact module can be found in Documenting MOOSE.

System Scope

The MOOSE Contact module provides capabilities for enforcing a variety of types of mechanical contact constraints between surfaces on deforming bodies. These constraints typically enforce the condition that the two surfaces do not penetrate each other. They can also optionally enforce that the two surfaces do not separate or slide relative to each other, or allow for slip only when the frictional capacity has been reached. Multiple methods are provided for enforcing these constraints, including node-on-face and mortar-based formulations. In addition to providing the capabilities for enforcing contact constraints, the Contact module also provides various supporting tools to facilitate setting up these models and outputting the results related to contact.

Dependencies and Limitations

The MOOSE Contact module inherits the software dependencies of the MOOSE framework and Solid Mechanics module 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, Contact 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 Contact 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 Contact module relies on MOOSE to solve the equilibrium equations for mechanical deformation, taking into account the additional conditions imposed for mechanical contact enforcement. 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 Contact module provides specialized Constraint classes that perform the majority of the effort involved in contact enforcement. This module is designed to work in conjunction with models provided outside this module, typically by the Solid Mechanics module, that solve the equilibrium equations for mechanical deformation of the bodies, and augments those solutions with the terms due to contact. It also provides other Action, AuxKernel, Damper, LineSearch, Postprocessor, Problem, Split, and UserObject classes to facilitate various aspects of these simulations.

System Structure

The MOOSE Contact module relies on the MOOSE framework to provide the core functionality of solving multiphysics problems using the finite element method, and on the Solid Mechanics module to provide the models for mechanical deformation of the interacting bodies. The structure of the Contact module is based on defining C++ classes that derive from classes in the MOOSE framework to provide functionality for mechanical contact enforcement. By using the interfaces defined in MOOSE base classes 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 Contact module is a command-line driven program. All interaction with the Contact 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 Contact 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 Contact 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

  • contact: VCP
  • 3.8.1The system shall converge and match the solution produced by standard mortar contact.

    Specification(s): dm_contact

    Design: Contact ActionVCP

    Issue(s): #15215

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    22
  • 3.8.2The system shall converge and match the solution produced by dual mortar contact.

    Specification(s): std_contact

    Design: Contact ActionVCP

    Issue(s): #15215

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    22
  • 3.8.3The system shall converge and match the solution with the standard methods using variable condenstation with AMG.

    Specification(s): dm_contact_precon

    Design: Contact ActionVCP

    Issue(s): #15215

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    22
  • 3.8.4The system shall converge and match the solution with the standard methods using variable condenstation with AMG, by always condensing out the LMs.

    Specification(s): dm_contact_precon_no_adaptivity

    Design: Contact ActionVCP

    Issue(s): #15215

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    22
  • 3.8.5The system shall converge and match the solution with the standard methods using variable condenstation with AMG, by using LU to solve for the LM variable (not assuming diagonal coupling with the primal variable).

    Specification(s): dm_contact_precon_full_dinv

    Design: Contact ActionVCP

    Issue(s): #15215

    Collection(s): FUNCTIONAL

    Type(s): CSVDiff

    22
  • contact: PenetrationAux
  • 3.14.1The system shall be able to output the incremental slip components to an auxiliary variable.

    Specification(s): slip

    Design: PenetrationAux

    Issue(s): #14409

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • contact: NodalArea
  • 3.25.1The system shall compute the nodal area for use with contact calculations in 3D.

    Specification(s): 3D

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.2The system shall compute the nodal area in parallel for use with contact calculations in 3D.

    Specification(s): 3D2Proc

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.3The system shall compute the nodal area for use with contact calculations in 2D.

    Specification(s): 2D

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.4The system shall compute the nodal area in parallel for use with contact calculations in 2D.

    Specification(s): 2D2Proc

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.5The system shall compute the nodal area for Hex20 elements for use with contact calculations.

    Specification(s): Hex20

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.6The system shall compute the nodal area for Hex20 elements for use with frictionless contact calculations.

    Specification(s): Hex20_2

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.7The system shall compute the nodal area for Hex20 elements for use with penalty contact calculations.

    Specification(s): Hex20_3

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.8The system shall compute the nodal area in parallel for Hex20 elements for use with contact calculations.

    Specification(s): Hex202Proc

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.9The system shall compute the nodal area for Hex27 elements for use with contact calculations.

    Specification(s): Hex27

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23
  • 3.25.10The system shall compute the nodal area in parallel for Hex27 elements for use with contact calculations.

    Specification(s): Hex272Proc

    Design: ContactNodalArea

    Issue(s): #716

    Collection(s): FUNCTIONAL

    Type(s): Exodiff

    23

References

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