Add auxvar and quadrature options to ContactAction

[TheBEllis]

Added two more input parameters to the ContactAction

• quadrature, which allows the user to change the quadrature order used with Mortar formulations
• add_aux_var, which allows the user to prevent the generation of contact_pressure, penetration, nodal_area and mortar_tangent aux variables when using mortar

Reason

• Being able to change the quadrature order from the ContactAction is a nice quality of life improvement.
• For large mortar problems, being able to turn off the auxiliary variables required for penalty and kinematic formulations can save a substantial amount of memory.

Design

• I have wrapped the generation of the aux variables in an if statement that will only be skipped if the formulation is set to mortar and add_aux_vars is set to false.
• By default add_aux_vars is set to true, and if the user tries to use it with a formulation that isn't mortar they will receive an error.
• The quadrature parameter is passed on to the Mortar constraints that can consume it.
• If the user tries to set quadrature with a formulation that isn't mortar they will receive an error.

Impact

• Could help enable larger mortar formulation solves through reduced memory footprint.

Edit: Closes #30208.

[milljm]

You'll need to adjust the base branch you are attempting to merge into (change to next instead of devel)

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request

[milljm]

Looks like Precheck failed, for the following:

##########################################################################
INFO: Your patch contains no trailing whitespace.
INFO: Your patch contains no proprietary or classified keywords.
INFO: Your patch contains no files without newlines before EOF.
INFO: Your patch contains no bad executable files.
INFO: Your patch contains no banned functions.
INFO: Your patch contains no banned keywords.
INFO: Style check disabled
INFO: Your patch contains no unicode characters.
INFO: Your patch contains no old style C++ include guards.
INFO: Your patch contains windows line endings.
##########################################################################


##########################################################################
ERROR: Your patch does not contain a valid ticket reference! (i.e. #1234)
Merge branch 'ContactActionQuadrature' of https://github.com/TheBEllis/moose into test
Added add_aux_vars to initialiser list
Add auxvar and quadrature options to ContactAction

ERROR: MOOSE prefers two spaces instead of tabs. The following files contain tab characters:
	modules/contact/src/actions/ContactAction.C
##########################################################################

Seems you'll need to create an Issue (like a feature request), and then amend your commit with that reference ticket.

[TheBEllis]

I've created and linked a relevant issue now, hopefully the checks will run fine!

[milljm]

You just need to include that in your commit message :) Civet is a real stickler about that:

git commit --ammend

"""
This adds the following features, etc etc

Closes #30208
"""

[TheBEllis]

You just need to include that in your commit message :) Civet is a real stickler about that:

I re-read your first comment and realised I had been foolish:)

[milljm]

With Precheck passing, I'll hand this off to one of our developers for approval to run on our clusters.

Cheers!

[moosebuild]

Job OpenMPI on 4d81a5a : invalidated by @GiudGiud

unrelated failure

[moosebuild]

Job Documentation, step Docs: sync website on 4d81a5a wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage, step Generate coverage on 4d81a5a wanted to post the following:

Framework coverage

Coverage did not change

Modules coverage

Contact

	48c61a	#30198 4d81a5
	Total	Total	+/-	New
Rate	90.31%	90.30%	-0.01%	97.17%
Hits	4874	4885	+11	103
Misses	523	525	+2	3

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
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• subchannel
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[maxnezdyur]

@TheBEllis Can you add a few more options for mortar contact? The action can't set some options that can be useful.

1. minimum_projection_angle
2. debug_mesh

[GiudGiud]

Just a note that adding new options is not mandatory.

But now that the additional need has been expressed, let's at least make sure the PR does not preclude meeting it

[jbadger95]

Hi Alex, triangle quadratures exactly integrate polynomials with total order; e.g. x^2 + xy + y^2 + LOT. Quad quadrature rules exactly integrate polynomials with tenor order; e.g. x^2y^2 + LOT. The quadrature is evaluating inner products so the 2n+1 is essentially split between the two functions being integrated. Maybe it’s possible to devise nonstandard quadrature schemes for triangles and in any case you can often get away with less since the mortar segment mesh is finer but I think the comment is correct as written; exact integration with standard quadratures do require that. Anyway, that’s the motivation on the comment, you probably have more insight into practice, etc.

On Mon, Mar 31, 2025 at 3:16 PM Alex Lindsay @.***> wrote:

@.**** requested changes on this pull request.

In modules/contact/src/actions/ContactAction.C https://github.com/idaholab/moose/pull/30198#discussion_r2021684773:

•  "While DEFAULT quadrature order is typically sufficiently accurate, "
  

•  "exact integration of QUAD mortar faces requires SECOND order quadrature for FIRST variables "
  

•  "and FOURTH order quadrature for SECOND order variables.");
  

What quadrature order are you seeing? The default quadrature order should be 2*n + 1, where n is the order of the FE basis

In modules/contact/src/actions/ContactAction.C https://github.com/idaholab/moose/pull/30198#discussion_r2021685444:

@@ -273,6 +273,22 @@ ContactAction::validParams() "Whether to use the Petrov-Galerkin approach for the mortar-based constraints. If set to " "true, we use the standard basis as the test function and dual basis as " "the shape function for the interpolation of the Lagrange multiplier variable.");

• params.addParam<MooseEnum>(

•  "quadrature",
  

•  MooseEnum("DEFAULT FIRST SECOND THIRD FOURTH", "DEFAULT"),
  

•  "Quadrature rule to use on mortar segments. For 2D mortar DEFAULT is recommended."
  

•  "For 3D mortar, QUAD meshes are integrated using triangle mortar segments. "
  

•  "While DEFAULT quadrature order is typically sufficiently accurate, "
  

•  "exact integration of QUAD mortar faces requires SECOND order quadrature for FIRST variables "
  

•  "and FOURTH order quadrature for SECOND order variables.");
  

• params.addParam("add_aux_vars",

•                    true,
  

•                    "For Mortar contact formulation problems, does the user still wish to "
  

⬇️ Suggested change

•                    "For Mortar contact formulation problems, does the user still wish to "
  

•                    "For mortar contact formulation problems, does the user still wish to "
  

---

In modules/contact/src/actions/ContactAction.C https://github.com/idaholab/moose/pull/30198#discussion_r2021707427:

•  "While DEFAULT quadrature order is typically sufficiently accurate, "
  

•  "exact integration of QUAD mortar faces requires SECOND order quadrature for FIRST variables "
  

•  "and FOURTH order quadrature for SECOND order variables.");
  

Ah I see this comment is a copy and paste from the doc string in MortarConstraintBase. I don't like the comment as currently written. Because the quadrature order we end up applying is actually 2*n + 1 where n is the order supplied to this parameter. So to describe what is currently happening in MOOSE, if someone supplies SECOND to this parameter, you will actually get FIFTH for the order value supplied to the quadrature constructor. And if someone supplies FOURTH, then the quadrature order will end up being NINTH.

I think that instead of duplicating parameters and doc strings which we directly forward from the action to the constraint, we should create some common params static function that returns these duplicates. Or I think maybe @GiudGiud https://github.com/GiudGiud created APIs for doing these parameter transfers for physics?

Finally, @jbadger95 https://github.com/jbadger95 or @roystgnr https://github.com/roystgnr do we really need NINTH quadrature for exactly integrating second order polynomial bases on a quad face that has been decomposed into two tris?

— Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/pull/30198#pullrequestreview-2730372749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJACZHVVKC4PUDDYABRIJZL2XGPBXAVCNFSM6AAAAABZ4Z2PACVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOMZQGM3TENZUHE . You are receiving this because you were mentioned.Message ID: @.***>

[lindsayad]

That's clear. Thanks @jbadger95 for your quick reply! Hope you're doing well 😄

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[GiudGiud]

Any update here?

[lindsayad]

we could probably finish this if @TheBEllis would prefer us to

[GiudGiud]

Yeah we should. @lindsayad want to take it on and I review or the opposite

[lindsayad]

Half this PR (the aux var piece) will no longer be relevant after https://github.com/idaholab/moose/pull/31268 which among several other things updates the ContactAction to only add auxiliary quantities that the mortar system uses. Instead of outputting penetration it will output the gap which is computed by a mortar aux kernel. Contact pressure will still be output but it will actually be nonzero now because it will use the mortar aux kernel. Nodal area will no longer be output. I think I'll wait until that PR is merged and then update this PR to only be about the quadrature option

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[lindsayad]

I should update this now that #31268 is merged

[lindsayad]

closing in favor of https://github.com/idaholab/moose/pull/32103 for automatically triggered testing