Calculation of c_normal and c_tangential values based on simulation parameters

[SweetRT]

Motivation

In order to use the mortar-based frictional contact capability in MOOSE, the numerical parameters c_normal and c_tangential, which greatly affect problem convergence behavior, must be set a priori. The use of trial-and-error to set these parameters is one of the largest impediments to generating multiphysics fuel performance simulations without individually calibrating each simulation. This also provides a more interpretable and intuitive syntax. Additionally, the ability to calculate these parameters dynamically during a simulation has the potential to enhance convergence behavior.

Design

The suggested design of this enhancement would include an option to use a problem-specific input parameters (i.e. initial gap distances and expected peak contact forces) and a dynamic tangential velocity calculation (in the case of c_tangential) to allow simulations using similar materials and geometries to have similar input parameters, preventing the need for the iterative process of setting these parameters.

Impact

This feature will enhance the general usability of frictional mortar-based contact by adding additional optional calculations for setting contact parameters. Given that this is intended to be an optional calculation, it should not affect current problems.

[lindsayad]

Ok I've pushed a design document referencing this issue. Here's the part that I could use user feedback on. Here are the new ContactAction parameters:

Parameter	Type	Default	Purpose
c_normal_strategy	MooseEnum	"user"	user (current behavior) or physical (fully automatic)
c_tangential_strategy	MooseEnum	"user"	user (current behavior) or physical (velocity-scaled, linked to c_normal_eff)
secondary_elasticity_tensor_base_name	std::string	""	Base name prefix of the elasticity tensor property on the secondary body; only used when c_normal_strategy = physical
primary_elasticity_tensor_base_name	std::string	""	Base name prefix of the elasticity tensor property on the primary body; only used when c_normal_strategy = physical
elasticity_tensor_is_ad	bool	false	Set to true if the elasticity tensor material property was declared as AD; only used when c_normal_strategy = physical

The idea is that we use the elasticity tensor to automatically compute local normalization coefficients. In order for this idea to work the user would need to specify base_name parameters in case they have base_name settings for their materials computing the elasticity tensor. I don't know how common this is. Additionally we need to be able to correctly call getMaterialProperty vs. getADMaterialProperty so there is an elasticity_tensor_is_ad parameter in the action

[lindsayad]

I'll note that there was a previous attempt at this in #23491 but it used old time solution state. That is a option. It wouldn't be useful on the very first timestep, but that's generally a small percentage of the overall simulation

[tophmatthews]

Not sure it matters, but there are other times where contact doesn't occur into much later in the simulation, so the previous timestep wouldn't help mid simulation either.

[lindsayad]

Yea we can plan to go with the pure physics based approach that doesn't rely on previous timestep data. If people are ok with the uncommon case of supplying a base_name when it's non-empty and specifying AD or not for the elasticity tensor for this physics based calc, then I'll get started implementing