Add LM mortar friction regularization

[Andreas-Lepak]

closes #33356

Reason

Coulomb friction in Lagrange-multiplier mortar contact can be difficult to converge near the onset of sliding because the tangential constraint reaches the full Coulomb bound abruptly. This PR adds optional regularization controls that can smooth that transition while preserving the current behavior by default.

Design

Add LM-mortar-only Coulomb friction regularization options:

• friction_elastic_slip adds a small tangential compliance in the friction LM predictor before the full Coulomb bound is reached.
• friction_coefficient_regularization = ARCTAN_SLIP scales the effective friction coefficient using the current step slip increment.
• friction_reference_slip provides the physical slip distance used by the arctangent regularization.

Tests cover action and direct-constraint input validation, unsupported formulation rejection, a short quasistatic LM mortar run, and a dynamic LM mortar CSV regression.

Impact

Existing inputs and results are unchanged unless users explicitly enable the new options. The new arctangent coefficient regularization uses the current step slip increment, so users should check timestep or load-step sensitivity when enabling it.

Notes

Performance tests for a simple ironing contact problem. Note that the PR is limited to mortar LM contact only, there was little benefit in using these new approaches for penalty methods (both mortar and node-face).

mortar_LM_ironning_friction_reg_github_loop.mp4

[moosebuild]

Job Documentation, step Docs: sync website on 34476db wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Test, step Results summary on 34476db wanted to post the following:

Framework test summary

Compared against 4fcf7b8 in job civet.inl.gov/job/3980633.

No change

Modules test summary

Compared against 4fcf7b8 in job civet.inl.gov/job/3980633.

Added tests

Test	Time (s)	Memory (MB)
contact/test:mortar_dynamics.block-dynamics-friction-regularization-action-run	3.68	177.11
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/run	1.75	292.55
contact/test:mortar_dynamics.block-dynamics-friction-regularization-action-parallel	1.31	255.33
contact/test:mortar_dynamics.block-dynamics-friction-regularization-action	0.69	94.70
contact/test:mortar_dynamics.block-dynamics-friction-regularization-direct	0.69	115.42
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/accept	0.62	131.71
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/nonpositive_reference_slip_error	0.59	166.16
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/bad_epsilon_error	0.56	56.41
contact/test:bouncing-block-contact.coulomb_friction_regularization_action_errors/ranfs_regularization_error	0.55	268.68
contact/test:bouncing-block-contact.coulomb_friction_regularization_action_errors/mortar_penalty_regularization_error	0.55	266.62
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/negative_reference_slip_error	0.55	55.35
contact/test:bouncing-block-contact.coulomb_friction_regularization_action_errors/non_coulomb_regularization_error	0.54	158.58
contact/test:bouncing-block-contact.coulomb_friction_regularization_action_errors/node_face_penalty_regularization_error	0.54	268.81
contact/test:bouncing-block-contact.coulomb_friction_regularization_lm_mortar/missing_reference_slip_error	0.54	108.18

[moosebuild]

Job Coverage, step Generate coverage on 34476db wanted to post the following:

Framework coverage

Coverage did not change

Modules coverage

Contact

	4fcf7b	#33358 34476d
	Total	Total	+/-	New
Rate	91.27%	91.38%	+0.12%	100.00%
Hits	5005	5081	+76	129
Misses	479	479	-	0

Diff coverage report

Full coverage report

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• subchannel
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[lindsayad]

Summary

This PR adds two optional regularizations for Coulomb LM mortar friction. Changes are requested before merge: the arctangent option is reasonably motivated, but the elastic-slip implementation appears increment-based rather than history-dependent, and the current verification does not establish physical accuracy or timestep convergence.

The performance figure does not demonstrate a convincing benefit from elastic slip. For 2D Mortar LM it is substantially more expensive than the default while reaching the same final time; for 3D it progresses only modestly farther and still does not finish. The visible improvement comes from arctangent regularization, while combining it with elastic slip shows no apparent additional benefit.

Cross-cutting design concern

Before adding friction_elastic_slip as a durable public interface, either demonstrate a representative LM case in which it improves robustness while preserving acceptable accuracy, or remove it from this PR. Because the incomplete 3D runs stop at different simulated times, their raw iteration totals are not directly comparable; normalize the measurements or run every variant to a common endpoint.

Tests & SQA

The full CI matrix is green and new-line coverage is reported as 100%. The remaining gaps are behavioral: the numerical regression enables both mechanisms together, quasistatic coverage is execution-only, and there is no load-hold or timestep-refinement test capable of detecting incremental creep.

Documentation

The existing object pages were updated and no new MooseObject documentation stubs are needed. The documentation should include the actual regularized equations and explain the loss or relaxation of exact sticking. I also suggest adding a July 2026 newsletter entry once the interface and semantics are settled.

Checklist

• CodeGraph used for reuse and blast-radius analysis
• No equivalent existing MOOSE regularization helper found
• Code Standard and user-facing parameters reviewed
• Independent numerical verification for each regularization
• Accurate per-test SQA traceability
• Equations and physical/timestep implications documented
• No security-sensitive behavior identified

Review generated by GPT-5 via Codex, at the request of @lindsayad.

[lindsayad]

Required: This “elastic slip” construction has no stored elastic-slip state. In the stick branch, defining $(B=\mu_{\mathrm{eff}}\max(0,p+cg))$, the residual reduces to

$$ \Delta u_t = \frac{\delta_e}{B+\epsilon}\lambda_t. $$

Because $(\Delta u_t=v_t\Delta t)$, a sustained sub-Coulomb traction can permit another nonzero slip increment on every timestep. That is incremental, timestep-dependent creep rather than recoverable elastic slip. Please either carry the required history, or rename and document this explicitly as increment-based regularization and verify its timestep behavior. The dynamic class repeats the same construction.

(generated by GPT-5 via Codex)

[lindsayad]

Required: This newly rejects epsilon = 0 even when regularization is disabled, despite the PR’s promise that existing inputs remain valid by default. If strict positivity is needed only to protect the elastic-compliance denominator, preserve compatibility and validate epsilon > 0 conditionally when friction_elastic_slip is enabled. The dynamic class has the same unconditional change.

(generated by GPT-5 via Codex)

[lindsayad]

Required: This reroutes function_friction through the populated physical-velocity map and therefore changes existing results even when the new regularization remains NONE; the updated legacy gold files confirm that behavior change. This may be a valid bug fix, but it contradicts the stated Impact. Please either split it into a separately traced fix or explicitly expand the issue and PR Reason/Design/Impact and update the affected test traceability.

(generated by GPT-5 via Codex)

[lindsayad]

Required: The only numerical diff enables elastic slip and arctangent regularization simultaneously, so it does not independently verify either public behavior. The quasistatic coverage is also only RunApp/check-input. Please add result-based tests for each mechanism separately, including a sub-Coulomb load-and-hold case that detects continued creep, timestep/load-step refinement, and convergence toward unregularized Coulomb as the regularization distances decrease.

(generated by GPT-5 via Codex)

[lindsayad]

Required: Adding #33356 here makes every pre-existing test in this file—including frictionless tests—inherit that issue. The added ContactAction design page at line 2 is inherited just as broadly. Keep the original file-level metadata and attach the new issue and appropriate design page(s) only to the new regularization tests.

(generated by GPT-5 via Codex)

[lindsayad]

Required: Please document the actual equations and physical tradeoffs. In particular, ARCTAN_SLIP gives $(\mu_{\mathrm{eff}}(0)\approx0)$, so exact static sticking is replaced by creeping, while the elastic term uses the current-step increment and depends on epsilon. Both mechanisms are timestep/load-step sensitive; the present wording attributes that warning only to coefficient regularization and can be read as implying a history-dependent elastic response.

(generated by GPT-5 via Codex)

[lindsayad]

Suggestion: I suggest declaring this non-template function here and defining it in a .C file. It does not need header-only visibility or inlining for performance; keeping the implementation out of the header follows the MOOSE Code Standard and reduces recompilation exposure.

(generated by GPT-5 via Codex)

[lindsayad]

Suggestion: I suggest using the direct _formulation != ContactFormulation::MORTAR comparison at the sole call site. This wrapper has only one use and does not add meaning beyond the comparison.

(generated by GPT-5 via Codex)