AuxiliaryPC with user provided Mats

[JHopeCollins]

A PC to apply the inverse of a user provided Mat.

TODO:

• docstrings
• tests
• decide whether to default to -ksp_type preonly

[pbrubeck]

The name is misleading, as this class does more than just a PC

[pbrubeck]

I think it'd be good to support two separate classes, one that wraps KSP, and another wrapping PC. You can also add a third one wrapping SNES.

[JHopeCollins]

The name is misleading, as this class does more than just a PC

Why is it more that just a PC? It sets up a subsolver on an alternative Mat. The standard thing for PETSc subsolvers is to set up a KSP. bjacobi, fieldsplit, asm, all do this.

The AuxiliaryOperatorPC in Firedrake is the anomoly, and I'd argue it does the wrong thing because it leads to the options mess that is PCKSP when it should just set up a LinearVariationalSolver or KSP and default to preonly.

I think it'd be good to support two separate classes, one that wraps KSP, and another wrapping PC. You can also add a third one wrapping SNES.

I agree that one wrapping SNES would be good. I'd like to do that after this one so I can see how it goes on the PC first.
I don't think we need one with the KSP. Either you're at the outermost solver level in which case it doesn't make sense to immediately change the mat (you'd just use preonly), or you're somewhere inside the solver stack in which case you can just use this PC.
It's an oddity of KSP/PC being distinct but SNES/NPC not being.

[pbrubeck]

A PC by default is understood as linear operator. A KSP is nonlinear in general. When you nest a KSP within a PC you might introduce undesirable mathematical behavior

[JHopeCollins]

When you nest a KSP within a PC you might introduce undesirable mathematical behavior

This is what you get with any of the other PETSc PCs I mentioned. You just default the inner KSP to be preonly, and if the user requests a nonlinear Krylov method then they need to make sure that the outer method is flexible.