Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions petsctools/pc.py
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
import abc
from .exceptions import PetscToolsException
from .options import _validate_prefix


class PCBase(abc.ABC):
Expand Down Expand Up @@ -153,3 +154,33 @@ def view(self, pc, viewer=None):
pcname = f"{type(self).__module__}.{type(self).__name__}"
viewer.printfASCII(
f"Python type preconditioner {pcname}\n")


class AuxiliaryPC(PCBase):

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 JHopeCollins Jun 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

prefix = "aux"

def initialize(self, pc):
from petsc4py import PETSc
A, P = self.get_mats(pc)
ksp = PETSc.KSP().create(comm=pc.comm)
ksp.setOperators(A, P or A)
ksp.setOptionsPrefix(
_validate_prefix((pc.getOptionsPrefix() or "") + self.prefix)
)
ksp.setFromOptions()
self.ksp = ksp

def update(self, pc):
A, P = self.ksp.getOperators()
A.assemble()
if P is not A:
P.assemble()

def apply(self, pc, x, y):
self.ksp.solve(x, y)

def applyTranspose(self, pc, x, y):
self.ksp.solveTranspose(x, y)

def mats(self, pc):
return pc.getOperators()
Loading