Constraints System

The Constraints system provides functionality for describing interaction and coupling between various nodes, elements or surfaces in a model for which the topology may evolve during the course of the solution. Generically, within an interaction pair, the two sides are referred to as Element and Neighbor or Secondary and Primary. A few examples of constraints include contact, mesh tying, and periodic boundary conditions.

Since the topology of the interacting nodes and elements may evolve, the direct contributions to the residual and the Jacobian need to be provided by the developer by overriding the computeResidual() and computeJacobian() functions directly. Certain examples for node and element constraints are listed in the syntax list at the bottom of the page. The remainder of the description is focused on the application of mortar constraints for surface interaction.

MortarConstraints

The mortar system in MOOSE uses a segment-based approach for evaluation of mortar integrals; for information on the automatic generation of mortar segment meshes see AutomaticMortarGeneration.

One has the option to use Petrov-Galerkin interpolation for the Lagrange multiplier variable. This is typically useful for mechanical contact problems (see Petrov-Galerkin approach for Lagrange multipliers).

Overview

An excellent overview of the conservative mortar constraint implementation in MOOSE for 2D problems is given in Peterson (2018). We have verified that the MOOSE mortar implementation satisfies the following a priori error estimates for 2D problems and (see discussion and plots on this github issue) and for 3D problems on hexahedral meshes:

Primal FE Type	Lagrange Multiplier (LM) FE Type	Primal L2 Convergence Rate	LM L2 Convergence Rate
Second order Lagrange	First order Lagrange	3	2.5
Second order Lagrange	Constant monomial	3	1
First order Lagrange	First order Lagrange	2	1.5
First order Lagrange	Constant monomial	2	1.5

General meshes in 3D—especially meshes with triangular face elements on the mortar interface—require additional care to ensure convergence. Triangular elements on the mortar interface typically exhibit the infamous (and well documented) 'locking' phenomenon; resulting in singular systems that require stabilization or other special treatment.

The above primal convergence rates were realized on tetrahedral and mixed meshes using a stabilization with delta = 0.1 for the EqualValueConstraint, with the additional caveat that meshes (both generated and unstructured) are re-generated for each experiment. Uniform refinement of tetrahedral meshes were typically observed to result in divergence of the Lagrange multiplier and degradation of primal convergence rates. Adaptive refinement of meshes with triangular faces on the mortar interface has not been thoroughly studied in MOOSE and should be approached with caution.

Based on these observations the following recommendations are provided for using 3D mortar in MOOSE:

When possible, discretize the secondary side of the mortar interface with QUAD elements (i.e. use HEX elements or carefully oriented PRISM and PYRAMID elements for volume discretization).
When TRI elements are present on the mortar interface, verify that the problem is well conditioned of the problem and use stabilization if necessary.
Avoid uniformly refining meshes, instead regenerate meshes when a refined mesh is needed.

note

3D mortar often requires larger AD array sizes than specified by the default MOOSE configuration. To configure MOOSE with a larger array use configuration option --with-derivative-size=<n>. The AD size required for a problem depends on 1) problem physics, 2) the order of primal and Lagrange multiplier variables, and 3) the relative sizing of the secondary and primary meshes.

Parameters

There are four required parameters the user will always have to supply for a constraint derived from MortarConstraint:

primary_boundary: the boundary name or ID assigned to the primary side of the mortar interface
secondary_boundary: the boundary name or ID assigned to the secondary side of the mortar interface
primary_subdomain: the subdomain name or ID assigned to the lower-dimensional block on the primary side of the mortar interface
secondary_boundary: the subdomain name or ID assigned to the lower-dimensional block on the secondary side of the mortar interface

As suggested by the above required parameters, the user must do some mesh work before they can use a MortarConstraint object. The easiest way to prepare the mesh is to assign boundary IDs to the secondary and primary sides of the interface when creating the mesh in their 3rd-party meshing software (e.g. Cubit or Gmsh). If these boundary IDs exist, then the lower dimensional blocks can be generated automatically using the LowerDBlockFromSidesetGenerator mesh generator as shown in the below input file snippet:


[Mesh]
  [./primary]
    type = LowerDBlockFromSidesetGenerator
    sidesets = '2'
    new_block_id = '20'
  [../]
  [./secondary]
    type = LowerDBlockFromSidesetGenerator
    sidesets = '1'
    new_block_id = '10'
  [../]
[]

There are also some optional parameters that can be supplied to MortarConstraints. They are:

variable: Corresponds to a Lagrange Multiplier variable that lives on the lower dimensional block on the secondary face
secondary_variable: Primal variable on the secondary side of the mortar interface (lives on the interior elements)
primary_variable: Primal variable on the primary side of the mortar interface (lives on the interior elements). Most often secondary_variable and primary_variable will correspond to the same variable
compute_lm_residuals: Whether to compute Lagrange Multiplier residuals. This will automatically be set to false if a variable parameter is not supplied. Other cases where the user may want to set this to false is when a different geometric algorithm is used for computing residuals for the LM and primal variables. For example, in mechanical contact the Karush-Kuhn-Tucker conditions may be enforced at nodes (through perhaps a NodeFaceConstraint) whereas the contact forces may be applied to the displacement residuals through MortarConstraint
compute_primal_residuals: Whether to compute residuals for the primal variables. Again this may be a useful parameter to use when applying different geometric algorithms for computing residuals for LM variables and primal variables.
periodic: Whether this constraint is going to be used to enforce a periodic condition. This has the effect of changing the normals vector, for mortar projection, from outward to inward facing.
quadrature: Specifies the quadrature order for mortar segment elements. This is only useful for 3D mortar on QUAD face elements since integration of QUAD face elements with TRI mortar segments on the mortar interface is inexact. Default quadratures are typically sufficient, but exact integration of FIRST order QUAD face elements (e.g. HEX8 meshes) requires SECOND order integration. Exact integration of SECOND order QUAD face elements (e.g. HEX27 meshes) requires FOURTH order integration.

At present, either the secondary_variable or primary_variable parameter must be supplied.

Coupling with Scalar Variables

If the weak form has contributions from scalar variables, then this contribution can be treated similarly as coupling from other spatial variables. See the Coupleable interface for how to obtain the variable values. Residual contributions are simply added to the computeQpResidual() function.

Because mortar-versions of UserObjects are not yet implemented, the only way to add contributions to the Jacobian, as well as the contribution of the mortar spatial variables to the scalar variable, is through deriving from the scalar augmentation class MortarScalarBase. This class provides standard interfaces for quadrature point contributions to primary, secondary, lower, and scalar variables in the residual and Jacobian. Additional discussion can be found at ScalarKernels.

Available Objects

Moose App
ADPenaltyEqualValueConstraintPenaltyEqualValueConstraint enforces solution continuity between secondary and primary sides of a mortar interface using a penalty approach (no Lagrange multipliers needed)
ADPenaltyPeriodicSegmentalConstraintADPenaltyPeriodicSegmentalConstraint enforces macro-micro periodic conditions between secondary and primary sides of a mortar interface using a penalty approach (no Lagrange multipliers needed). Must be used alongside PenaltyEqualValueConstraint.
ADPeriodicSegmentalConstraintADPeriodicSegmentalConstraint enforces macro-micro periodic conditions between secondary and primary sides of a mortar interface using Lagrange multipliers.Must be used alongside EqualValueConstraint.
CoupledTiedValueConstraintRequires the value of two variables to be the consistent on both sides of an interface.
EqualGradientConstraintEqualGradientConstraint enforces continuity of a gradient component between secondary and primary sides of a mortar interface using lagrange multipliers
EqualValueBoundaryConstraintConstraint for enforcing that variables on each side of a boundary are equivalent.
EqualValueConstraintEqualValueConstraint enforces solution continuity between secondary and primary sides of a mortar interface using lagrange multipliers
EqualValueEmbeddedConstraintThis is a constraint enforcing overlapping portions of two blocks to have the same variable value
LinearNodalConstraintConstrains secondary node to move as a linear combination of primary nodes.
OldEqualValueConstraintOldEqualValueConstraint enforces solution continuity between secondary and primary sides of a mortar interface using lagrange multipliers
PenaltyEqualValueConstraintPenaltyEqualValueConstraint enforces solution continuity between secondary and primary sides of a mortar interface using a penalty approach (no Lagrange multipliers needed)
PenaltyPeriodicSegmentalConstraintPenaltyPeriodicSegmentalConstraint enforces macro-micro periodic conditions between secondary and primary sides of a mortar interface using a penalty approach (no Lagrange multipliers needed). Must be used alongside PenaltyEqualValueConstraint.
PeriodicSegmentalConstraintPeriodicSegmentalConstraint enforces macro-micro periodic conditions between secondary and primary sides of a mortar interface using Lagrange multipliers.Must be used alongside EqualValueConstraint.
TiedValueConstraintConstraint that forces the value of a variable to be the same on both sides of an interface.
Tensor Mechanics App
NodalFrictionalConstraintFrictional nodal constraint for contact
NodalStickConstraintSticky nodal constraint for contact

Available Actions

Moose App
AddConstraintActionAdd a Constraint object to the simulation.

References

John W. Peterson. Progress toward a new implementation of the mortar finite element method in moose. 2 2018. doi:10.2172/1468630.

@article{osti_1468630,
    author = "Peterson, John W.",
    title = "Progress toward a new implementation of the mortar finite element method in MOOSE",
    abstractNote = {The mortar finite element method has been used for many years in a variety of applications, including the enforcement of continuity conditions across decomposed domains, the implementation of Dirichlet boundary conditions, obtaining improved estimates of surface fluxes, and for solving large deformation contact mechanics problems. There is a currently great deal of interest in developing more robust mechanical and thermal contact solution strategies in the MOOSE framework and physics modules, and schemes based on the mortar finite element approach appear to be a promising avenue of development. There are a number of challenges associated with the development of a robust Lagrange multiplier based formulation of the mortar finite element method which can be tackled using the relatively simple framework of thermal contact problems, before tackling more complicated applications such as thermomechanical contact. In this report, we describe several aspects of our mortar finite element method implementation for solving thermal contact problems. The approach and notation used are based primarily based on the work of Bin Yang et al. ("Two dimensional mortar contact methods for large deformation frictional sliding," International Journal for Numerical Methods in Engineering 62(9), 2005).},
    doi = "10.2172/1468630",
    journal = "",
    place = "United States",
    year = "2018",
    month = "2"
}