Allow integrating hypre AMS/ADS in FSPs

[nmnobre]

See also https://gitlab.com/petsc/petsc/-/merge_requests/9077.

[moosebuild]

Job Coverage, step Generate coverage on 71c9d19 wanted to post the following:

Coverage

	783e82	#4412 71c9d1
	Total	Total	+/-	New
Rate	65.47%	65.47%	-0.00%	100.00%
Hits	78226	78232	+6	31
Misses	41255	41263	+8	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

[lindsayad]

Is this going to rely on the libMesh DM?

[nmnobre]

I was using petsc_auto_fieldsplit() with --solver-variable-names to test this (is that what you meant?).
The current implementation in set_petsc_aux_data() only requires a variable/split index (so there must be a one-to-one correspondence there between no. of vars and splits), but I don't think there were any particular assumptions on who/what does the splitting, as long as PETSc is informed about it somehow.

In the discussion I linked above we agreed that the proper way to do this was probably to provide a callback that PETSc would call just-in-time whenever it needs info to build the preconditioner with sufficient information passed to the client application (i.e. libMesh) so it can disambiguate what variable/split needs preconditioning. That would then lift the requirement for only a single-level of field-split with one-to-one variables and splits (like I have here at present).

[lindsayad]

I probably don't fully understand the situation here but in MOOSE we have examples of

• nested field splits
• one split with multiple variables
• multiple splits of one variable (contact-interface dofs and non-contact-interface dofs for example)

I'll note that it's been a long-standing goal of mine to unify the libMesh and MOOSE DMs. I think each has features that the other does not. The MOOSE DM, for instance, doesn't have geometric multigrid support

[nmnobre]

I know we do, and I know as it stands this implementation is limiting (thus the condition to return early if the assumption doesn't hold).

I probably don't fully understand the situation here

I think the problem is I don't fully understand the situation. That's (partially) why this is on hold. I don't really know how PETSc DM works.

I'll note that it's been a long-standing goal of mine to unify the libMesh and MOOSE DMs

Yes(!), I never understood why some of the functionality was reimplemented, and to be frank I always had doubts as to whether they're actually playing perfectly nice with each other. I remember lamenting the situation with @roystgnr, but I just can't find that conversation anywhere, might've dreamt it.