Creation of lower-dimensional blocks and mortar variables

Use of mortar contact requires the generation of lower dimensional blocks that are used to generate mortar segments, where the problem's equations and constraints are computed. These lower-dimensional blocks are created from existing mesh sidesets, which are typically added to the mesh to capture general contact.

The creation of these subdomains when using mortar is automatically performed by the actions. Their names are composed of the name of action and _primary_subdomain and _secondary_subdomain. If only mortar mechanical contact is used, these subdomains are created by the mechanical contact action and then used by the thermal action. Otherwise, if mortar thermal contact is present, the thermal action creates the subdomains. Similarly, the Lagrange's multipliers required to compute the thermal equilibrium and normal and frictional mechanical contact are created by the action with the recommended settings of element type, interpolation order, and standard or dual interpolation.

For mechanical contact, the variable names are created by appending _normal_lm and _tangential_lm to the mechanical contact action. The heat flux Lagrange's multiplier is also created by appending the string _thermal_lm to the name of the thermal contact action.

Executioner

When using the conventional node on face approach, an input block is added in the Executioner block to control the order of integration. For example, for a first order case, the following selection is recommended

[Executioner<<<{"href": "../../syntax/Executioner/index.html"}>>>]
  [Quadrature<<<{"href": "../../syntax/Executioner/Quadrature/index.html"}>>>]
    order<<<{"description": "Order of the quadrature"}>>> = THIRD
    side_order<<<{"description": "Order of the quadrature for sides"}>>> = FIFTH
  []
[]

However, when running with thermomechanical mortar, this subblock is not needed.

Mortar formulations converge significantly better when small diagonal pivots are enforced, which alleviates numerical issues due to equation's saddle point structure. In general, the settings below are recommended.

  solve_type = 'NEWTON'
  petsc_options_iname = '-pc_type -pc_factor_mat_solver_package -mat_mffd_err -pc_factor_shift_type -pc_factor_shift_amount'
  petsc_options_value = 'lu    superlu_dist   1e-5          NONZERO               1e-15'
  snesmf_reuse_base = false

This last setting, snesmf_reuse_base = false, does not look to be strictly necessary to date, as mortar residuals give the same results for the same variable vector. Therefore, snesmf_reuse_base can be omitted, which will default to true. In addition, when running with mortar, the variable array gets augmented with Lagrange multipliers. These variables do not exist when employing Bison's traditional approach. However, new Lagrange multiplier (i.e. flux or contact pressure) can be various order of magnitude different from primal variables (temperature or displacements). For this reason, it is recommended to enforce additional variable scaling and/or relax the executioner absolute tolerance.

Output

In addition to Lagrange multipliers, the users can output analysis metrics when using a mortar formulation. An auxiliary kernel acting on a Lagrange variable on the lower-dimensional domain can set up as follows:

  [gap_conductance]
    type = GapConductanceMortar
    primary_boundary = 5 # cladding
    secondary_boundary = 10 # fuel
    primary_subdomain = 'mechanical_primary_subdomain'
    secondary_subdomain = 'mechanical_secondary_subdomain'
    heat_flux = thermal_contact_thermal_lm # heat flux Lagrange multiplier
    temperature = temperature
    variable = gap_conductance
  []

The variable gap_conductace can be acting upon in postprocessors (see below). Note that ElementAverageValue acts on the secondary lower-dimensional domain (mechanical_secondary_subdomain).

  [avg_gap_conductance]
    type = ElementAverageValue
    block = 'mechanical_secondary_subdomain'
    variable = gap_conductance
    execute_on = 'initial timestep_end'
  []

Thermal action

The user can now select an LWR thermal action that leverages an automatic differentiation mortar base class. The GasGapConductanceConstraint object is analogous to GasGapConductance and shares, for the most part, its functionality.

[ThermalContactMortar<<<{"href": "../../syntax/ThermalContactMortar/index.html"}>>>]
  [thermal_contact]
    secondary_variable<<<{"description": "The secondary variable"}>>> = temperature
    primary_boundary<<<{"description": "The primary surface"}>>> = '5'
    secondary_boundary<<<{"description": "The secondary surface"}>>> = '10'
    initial_moles<<<{"description": "The Postprocessor that will give the initial moles of gas."}>>> = initial_moles # coupling to a postprocessor which supplies the initial plenum/gap gas mass
    gas_released<<<{"description": "The postprocessor(s) that will give the gas released."}>>> = fis_gas_released # coupling to a postprocessor which supplies the fission gas addition
  []
[]

Normal contact constraint

The Lagrange's multiplier associated with normal contact is the normal contact pressure, so it can be used instead of the traditional contact_pressure and be plotted in postprocessing software. The normal contact constraints are enforced via complementarity conditions and a weighted (or integrated) normal gap distance. The mechanical contact action for frictionless contact can look as follows

[Contact<<<{"href": "../../syntax/Contact/index.html"}>>>]
  [mechanical]
    model<<<{"description": "The contact model to use"}>>> = frictionless
    formulation<<<{"description": "The contact formulation"}>>> = mortar
    primary<<<{"description": "The list of boundary IDs referring to primary sidesets"}>>> = 5
    secondary<<<{"description": "The list of boundary IDs referring to secondary sidesets"}>>> = 10
    c_normal<<<{"description": "Parameter for balancing the size of the gap and contact pressure for a mortar formulation. This purely numerical parameter affects convergence behavior and, in general, should be larger for stiffer materials. It is recommended that the user tries out various orders of magnitude for this parameter if the default value generates poor contact convergence."}>>> = 1e+11
  []
[]

c_normal is a purely numerical parameter that can affect convergence behavior (but not converged results). It is typically recommended to select a value for c_normal that would balance contact pressure and gap distance values. Best convergence results are typically obtained when c_normal is selected to be one or two orders of magnitude less than the maximum contact pressure reached over the course of the simulation.

Frictional contact

Variationally consistent frictional forces were recently implemented and their general use in BISON is particularly experimental. Unlike the conventional node on face mechanical contact, use of friction with mortar does not add a layer of algorithmic complexity (i.e. slip damper or augmented Lagrangian formulation). Instead, frictional constraints are solved within the entire system of equations and the corresponding variables are iteratively updated.

In addition to the c_normal parameter, a similar c_tangential numerical parameter is used to balance the time step's nodal relative tangential velocity. A significant increment of the number of nonlinear iterations is to be expected when enabling mortar friction. In addition, relaxation of absolute tolerances to enable convergence of Lagrange multipliers may be required.

[Contact<<<{"href": "../../syntax/Contact/index.html"}>>>]
  [mechanical]
    model<<<{"description": "The contact model to use"}>>> = coulomb
    formulation<<<{"description": "The contact formulation"}>>> = mortar
    primary<<<{"description": "The list of boundary IDs referring to primary sidesets"}>>> = 5
    secondary<<<{"description": "The list of boundary IDs referring to secondary sidesets"}>>> = 10
    friction_coefficient<<<{"description": "The friction coefficient"}>>> = 0.4
    c_normal<<<{"description": "Parameter for balancing the size of the gap and contact pressure for a mortar formulation. This purely numerical parameter affects convergence behavior and, in general, should be larger for stiffer materials. It is recommended that the user tries out various orders of magnitude for this parameter if the default value generates poor contact convergence."}>>> = 1e+09
    c_tangential<<<{"description": "Numerical parameter for nonlinear mortar frictional constraints"}>>> = 1e+17
  []
[]

And you'll probably have to contact the developers, so here's the page: Contact the developers. We might be able to help