Contact-Homotopy

[thartland]

The purpose of this PR is to add the ability to solve (tied) contact problems with the homotopy solver.

Tribol calls are wrapped in a constraint object which will define a NLMCProblem which is the object that the homotopy solver acts on.

Another addition of this PR is the complete avoidance of delete and replacing usage of raw pointers with std::unique_ptr in inertia relief and tied contact problem EqualityConstrainedHomotopyProblem's

Removing finite difference check task as such a check will only pass if we compile with enzyme and enable exact derivatives.

• create a contact NLMCProblem and pass it to the HomotopySolver.
• Have complementarity problems return Operator* instead of HypreParMatrix* to support a wider range of applications wherein the Operators are not assembled. Caveat: more work is needed for the HomotopySolver to fully support other operator types
• More verbose function defs for serac wrapper of problems so things are more easily understood by others.
• Utilize exceptions from Tribol compuations to signal bad contact computations to the solver and to reduce solver step length parameters. (Currently via a branch of Tribol). While exceptions are now in place they are not being explicitly used in this PR as with "milder" homotopy solver parameters the nonlinear iterates do not vary so wildly as to require the exceptions that are only available via a specific Tribol branch.
• Given updates to algorithmic parameters to the HomotopySolver is it still necessary to catch contact mechanics computation errors for the contact mechanics application problem? This will potentially impact the PR making it being able to merge into master dependent on if we update Tribol. Answer: it is not strictly necessary to catch Tribol contact mechanics errors for the two_block example that runs with the Homotopy solver.
• Hide the infastructure needed to utilize "fixed" and "displacement" ess_tdof_list's. That is the "user" need just pass the ess_tdof_list's and the ContinuationSolver problem class should just take care of things. As is the "user" shouldn't need to construct prolongation_ and restriction_ mfem::HypreParMatrix's as in the current implementation of examples/contact/homotopy/two_blocks.cpp.

For a future PR: (1) finish work begun here to cache contact mechanics function calls and (2) update the manner in which we do Dirichlet BC's. Currently we eliminate essential/displacement dofs and only expose the reduced linear system to the Homotopy solver. This has implications for the linear solvers used, such as AMG with SystemsOptions.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 1.35135% with 73 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.82%. Comparing base (db9409c) to head (604d8f7).
⚠️ Report is 15 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/serac/physics/contact_constraint.hpp	1.38%	71 Missing ⚠️
src/serac/physics/constraint.hpp	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1463      +/-   ##
===========================================
- Coverage    92.03%   91.82%   -0.21%     
===========================================
  Files          199      200       +1     
  Lines        25212    25277      +65     
===========================================
+ Hits         23203    23210       +7     
- Misses        2009     2067      +58     

Flag	Coverage Δ
unittests	91.82% <1.35%> (-0.21%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tupek2]

what does point mean in this context? Is this checking if we need to updating things in Tribol again because contact interactions may have changed?

[thartland]

Precisely. Like is the point that we are doing such and such computations at a "new_point" or was it "seen" in the previous call. This flag is intended to allow caching contact mechanics computations.

[btalamini]

Thanks for the explanation. Can you make the name more clear and specific? new_point is too vague. "point" makes me think of points in space. It might help to make the name an imperative statement, like "refresh_contact_search" or something like that.

[thartland]

@btalamini I used "fresh_evaluation" to not be so vague as "point"/"new_point". I didn't want to use "refresh_contact_search" as this language is specific for contact but caching constraint evaluations/constraint Jacobian evaluations can be done in applications other than contact.

[btalamini]

Thanks for the explanation. Can you make the name more clear and specific? new_point is too vague. "point" makes me think of points in space. It might help to make the name an imperative statement, like "refresh_contact_search" or something like that.

[white238]

Approved after minor nitpicks but there is a conflict.