Separate stick, slip, open parts of contact residual and try to normalize them properly

[paveltomin]

Separately compute contact residuals for elements in stick, slip, and open states and normalize:

• Stick: normalize locally rhs by element area and compute L2-norm of that
• Slip and Open: compute L2-norm of rhs and normalize by Linf norm or rhs (similar to for as continuous mechanics)   Bonus: lineSearchResidualFactor - factor used to check residual increase for triggering line search (currently any residual increase will trigger line search which is too conservative)

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 7.69231% with 84 lines in your changes are missing coverage. Please review.

Project coverage is 53.19%. Comparing base (d84a7e1) to head (fc2ef0e).

Files	Patch %	Lines
...sSolvers/contact/SolidMechanicsLagrangeContact.cpp	0.00%	43 Missing :warning:
...olvers/contact/SolidMechanicsEmbeddedFractures.cpp	0.00%	34 Missing :warning:
...nents/physicsSolvers/NonlinearSolverParameters.cpp	75.00%	2 Missing :warning:
src/coreComponents/physicsSolvers/SolverBase.cpp	0.00%	2 Missing :warning:
...nents/physicsSolvers/NonlinearSolverParameters.hpp	50.00%	1 Missing :warning:
...ers/solidMechanics/SolidMechanicsLagrangianFEM.cpp	0.00%	1 Missing :warning:
...ers/solidMechanics/SolidMechanicsLagrangianFEM.hpp	0.00%	1 Missing :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3059      +/-   ##
===========================================
- Coverage    53.21%   53.19%   -0.02%     
===========================================
  Files          989      989              
  Lines        83602    83646      +44     
===========================================
+ Hits         44490    44498       +8     
- Misses       39112    39148      +36     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[CusiniM]

also, why not merging this into develop directly?

[paveltomin]

also, why not merging this into develop directly?

i was not sure this PR will fly, i can merge it into https://github.com/GEOS-DEV/GEOS/pull/3049 but would prefer you to have a look at #3049 first separately

[paveltomin]

Do you see improvements in the convergence? I am not fully conviced by the stick case normalization. I think we should try to keep dimensionless.

Yes, some case from @jhuang2601 started to behave more reasonably (see some discussion here https://fcmaelstrom.slack.com/archives/C06LS3LH51P/p1711552600352519)

[CusiniM]

also, why not merging this into develop directly?

i was not sure this PR will fly, i can merge it into #3049 but would prefer you to have a look at #3049 first separately

I think I would merge these changes directly into develop separately.

[paveltomin]

also, why not merging this into develop directly?

i was not sure this PR will fly, i can merge it into #3049 but would prefer you to have a look at #3049 first separately

I think I would merge these changes directly into develop separately.

this branch happen to be based on #3049