Updates for latest release of PETSc

[connorjward]

Supersedes #3997

Closes #4155

Should follow #4135 (merged)

Note that we expect the docs build to fail because that is using an older PETSc version.

[francesco-ballarin]

What's the long term plan in terms of CI?

My guess is that you may want to have three CIs:

• on firedrake release branch, check periodically that tests/demos still run against the blessed PETSc/SLEPc version. This should never fail.
• on firedrake release branch, check periodically that tests/demos run against the current PETSc/SLEPc release branch. This would not be expected to fail often, since point releases of PETSc/SLEPc are expected to be backward compatible.
• on firedrake main branch, check periodically that tests/demos run against the current PETSc/SLEPc main branch. Seeing this fail should not be a big deal, but it should be a warning that something will break in March/September, when the blessed PETSc/SLEPc version will be moved.

Feel free to move this elsewhere if more appropriate. Note that the last two CIs will need petsc4py/slepc4py to be unpinned (i.e. no ==3.22.2 in pyproject.toml).

[connorjward]

What's the long term plan in terms of CI?

• on firedrake release branch, check periodically that tests/demos run against the current PETSc/SLEPc release branch. This would not be expected to fail often, since point releases of PETSc/SLEPc are expected to be backward compatible.

I don't know if this is a goal here. I think we have two Firedrake configurations which we want to test: release vs the 'blessed' PETSc version, and main vs something close to PETSc main.

• on firedrake main branch, check periodically that tests/demos run against the current PETSc/SLEPc main branch. Seeing this fail should not be a big deal, but it should be a warning that something will break in March/September, when the blessed PETSc/SLEPc version will be moved.

I think the idea is to track and advance (weekly-ish) a known "last good commit" on PETSc main. That way we can fix things when they arise but not have our CI beholden to whether or not main works for us. Maybe it would be better to just track main, not sure.

[francesco-ballarin]

I don't know if this is a goal here. I think we have two Firedrake configurations which we want to test: release vs the 'blessed' PETSc version, and main vs something close to PETSc main.

My rationale for saying this was: say that you are forced to release a firedrake 2025.4.1 in July. Maybe at that point, since you were forced to do a new release anyways, you would want to move to PETSc 3.23.2 (or whatever point version they have arrived at), rather than stick to the 3.23.0 as of March.

[connorjward]

I don't know if this is a goal here. I think we have two Firedrake configurations which we want to test: release vs the 'blessed' PETSc version, and main vs something close to PETSc main.

My rationale for saying this was: say that you are forced to release a firedrake 2025.4.1 in July. Maybe at that point, since you were forced to do a new release anyways, you would want to move to PETSc 3.23.2 (or whatever point version they have arrived at), rather than stick to the 3.23.0 as of March.

I'm not sure that we necessarily want to always track the different releases. It introduces a source of instability (though likely very minor) into our own releases. If things work as they are I'm not sure that we should take any unnecessary risks.

[rckirby]

Looks fine, let's land after #4121.