This pull request (PR) introduces a minor refactoring of the contact constitutive models. The changes are intended to facilitate:
The implementation of rate-and-state- dependent friction.
The incorporation of various normal stress-hydraulic aperture relationships beyond the current table-based approach.
The use of a different contact enforcement in the Hydrofracture solver.
Below, I detail each proposed change and the rationale behind them:
Separation of Friction Law and Hydraulic Aperture-Stress Relation:
Objective: Decouple the friction law and hydraulic aperture-stress relationship into two distinct objects.
Rationale: These elements serve different purposes, particularly evident in scenarios where hydraulic aperture does not influence dry fractures. This separation simplifies the user experience by eliminating unnecessary table definitions for non-flow scenarios and supports more focused class responsibilities.
Implementation:
Friction models: derived from a FrictionBase class. These would be, for example, CoulombFriction and RateAndStateFriction . In general I would say that a friction model should have pretty limited responsibilities. The main thing it should know how to do is compute the shearTraction given the normal one.
HydraulicAperture - stress models: derived from HydraulicApertureBase (I hate this name but could not think of a better one), these laws define the relationship between the hydraulicAperture and the contact stress. The current aperture table would, for example, be part of these and we could immediately add BartonBandis and that exponential model (in the past, @frankfeifan had to hardcode these in the kernels).
Move the penalty parameter from the friction model to the physicsSolvers t
Objective: Remove the penalty parameter from the friction model and integrate it into the physics solvers where necessary.
Rationale: The penalty parameter is a numerical paramer, not a physical property, and should be treated as such.
Introduction of SolidMechanicsPenaltyContact:
Objective: Create a distinct physics package for the penalty method, separating it from the SolidMechanicsSolver.
Rationale: This change is somewhat arbitrary but aligns with the idea that the penalty is just another method to enforce non-interpenetration, deserving its own dedicated solver. This adjustment reduces the complexity of the SolidMechanicsSolver and moves some functionalities to a new physics package that inherits from ContactSolverBase. I don't think we will ever use this method to model slip but I think it helps removing a few functions and a few options from the base SolidMechanics solver. In the future we can also abstract the SOLID_SOLVER type in the HydrofractureSolver and introduce an hydraulic fracturing solver that relies on the kinematic enforcement of the contact constraints instead of the penalty currently used.
Redefinition of defaultAperture:
Objective: Move the defaultAperture definition from the region to the HydraulicAperture relation model.
Rationale: Since the aperture and its default setting are closely linked, consolidating them into a single model enhances coherence and reduces redundancy.
@rrsettgast, @paveltomin , @jhuang2601, @matteofrigo5, @frankfeifan : this is still a WIP but I have already made enough changes for you to grasp what the final result will look like.
This pull request (PR) introduces a minor refactoring of the contact constitutive models. The changes are intended to facilitate:
The implementation of rate-and-state- dependent friction.
The incorporation of various normal stress-hydraulic aperture relationships beyond the current table-based approach.
The use of a different contact enforcement in the
Hydrofracture
solver.Below, I detail each proposed change and the rationale behind them:
Separation of Friction Law and Hydraulic Aperture-Stress Relation:
FrictionBase
class. These would be, for example,CoulombFriction
andRateAndStateFriction
. In general I would say that a friction model should have pretty limited responsibilities. The main thing it should know how to do is compute theshearTraction
given the normal one.HydraulicApertureBase
(I hate this name but could not think of a better one), these laws define the relationship between thehydraulicAperture
and the contact stress. The current aperture table would, for example, be part of these and we could immediately addBartonBandis
and that exponential model (in the past, @frankfeifan had to hardcode these in the kernels).Move the penalty parameter from the friction model to the physicsSolvers t
Introduction of
SolidMechanicsPenaltyContact
:SolidMechanicsSolver
.SolidMechanicsSolver
and moves some functionalities to a new physics package that inherits fromContactSolverBase
. I don't think we will ever use this method to model slip but I think it helps removing a few functions and a few options from the baseSolidMechanics
solver. In the future we can also abstract theSOLID_SOLVER
type in theHydrofractureSolver
and introduce an hydraulic fracturing solver that relies on the kinematic enforcement of the contact constraints instead of the penalty currently used.Redefinition of
defaultAperture
:defaultAperture
definition from the region to the HydraulicAperture relation model.@rrsettgast, @paveltomin , @jhuang2601, @matteofrigo5, @frankfeifan : this is still a WIP but I have already made enough changes for you to grasp what the final result will look like.