Algebraic multigrid with filtering contact (AMGFContact) preconditioner for contact linear systems

[thartland]

This PR adds the capability of using AMGF (algebraic multigrid with filtering arXiv preprint)-preconditioned Krylov-subspace linear solvers for the Newton linear solves that arise in outer loop solves of contact problems.

• Obtain list of contact dofs via ContactData::addContactInteraction calls.
• Create a boundary_dof --> subspace transfer operator (mfem::HypreParMatrix) call. Much of this infastructure is in the utilities of continuationsolvers but a version most suitable for usage in smith would be best for less complex code.
• Obtain subspace transfer (displacement dofs --> contact dofs) operator via the list of contact dofs in appropriate place for passing the subspace transfer operator to the preconditioner provided that said linear solver preconditioner is AMGF.
• Resolve usage errors conflating print_level and preconditioner_print_level from linear solver options in the buildPreconditioner method.
• Test.

For future investigation/potential PR(s)
(1) Make AMGFContact robust to indefiniteness issues stemming from using exact Hessians in Newton solves.
(2) More careful consideration for setting outer/inner tolerances (as well as norms used) for Newton-Krylov.

Note -- AMGFContact preconditioned Krylov-subspace methods will fails unless the problem is a contact problem. The failure is indicated by mfem generated error messages indicating that the subspace transfer operator has not been set.

[ebchin]

Thanks @thartland, looking forward to using it!

[tupek2]

Ideally, yes. this would limit us to 2 billions dofs, max. There are likely other places we'd need to fix this though.

[tupek2]

Are these subspace transfers being computed once up front, or would they occur every time a new Jacobian is assembled (say in a Newton iteration loop). Maybe the performance if not so bad, but something to consider down the line perhaps.

[tupek2]

presumably we error out. maybe that is already happening elsewhere?

[thartland]

Are these subspace transfers being computed once up front, or would they occur every time a new Jacobian is assembled (say in a Newton iteration loop). Maybe the performance if not so bad, but something to consider down the line perhaps.

Good point. The subspace transfer operator is computed once every time SolidMechanicsContact::warmStartDisplacementContact is called which seems to be once per time-step. This does seem like too much and don't see a case for which the set of potential contact dofs would evolve in time.

[thartland]

Are these subspace transfers being computed once up front, or would they occur every time a new Jacobian is assembled (say in a Newton iteration loop). Maybe the performance if not so bad, but something to consider down the line perhaps.

This has now been updated and the subspace transfer operator is computed once per contact simulation.

[thartland]

@white238 -- regarding the guarding against usage of the contact_beam_amgf.cpp test in non-Tribol/non-Strumpack builds. Currently it is guarded against usage in Tribol and similar Tribol contact test cases have similar error messages when using non-Strumpack builds. See here. Do any of the mfem TPLs that we test against have non STRUMPACK builds?

Nonetheless I put STRUMPACK specific guards for including this test in non strumpack builds.

[white238]

@white238 -- regarding the guarding against usage of the contact_beam_amgf.cpp test in non-Tribol/non-Strumpack builds. Currently it is guarded against usage in Tribol and similar Tribol contact test cases have similar error messages when using non-Strumpack builds. See here. Do any of the mfem TPLs that we test against have non STRUMPACK builds?

Nonetheless I put STRUMPACK specific guards for including this test in non strumpack builds.

Thanks for putting the check in.. we should verify turning off our optional TPLs to see if they are properly guarded but that is outside the scope of this PR.