You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Every viscoelastic Stokes solve prints a PETSc error banner from _check_velocity_preconditioner #827
A viscoelastic Stokes solve prints a full PETSc error banner, about 38 lines, starting:
[0]PETSC ERROR: Object is in wrong state
[0]PETSC ERROR: Must call KSPSetUp() or PCSetUp() before calling PCFieldSplitGetSubKSP()
[0]PETSC ERROR: #1 PCFieldSplitGetSubKSP_FieldSplit_Schur() at .../fieldsplit.c:2267
The solve itself is healthy: reason 3, then 2. The banner makes it look broken.
Where.Stokes._check_velocity_preconditioner (systems/solvers.py) asks pc.getFieldSplitSubKSP() while the fieldsplit PC is not set up. The except Exception: return catches the exception, but PETSc prints the banner before the exception reaches Python. With the method replaced by a no-op, the banner is gone and the solves are unchanged (same reasons and iteration counts).
The method already skips the rotated free-slip path for this exact reason; its comment says catching does not work and pushErrorHandler broke 23 tests. The viscoelastic path also reaches the check with the PC not set up, presumably since the #727 split into _stress_history_prepare / _stress_history_advance rebuilds the solver around the build.
Fix direction. Gate the check on the PC having been set up, rather than catching, the same way the rotated path is skipped. Or run the check after the first solve, when the sub-KSPs exist. A test can capture stderr from the reproducer at the file-descriptor level and assert that no PETSC ERROR appears.
Found by the adversarial review of the #823 branch. It is identical with and without that branch's changes.
Underworld development team with AI support from Claude Code
More triggers, from the adversarial review of the #794 merge (PR #794 merged with development at 2c6bc2f). The banner "Must call KSPSetUp() or PCSetUp() before calling PCFieldSplitGetSubKSP()" prints after any rewire followed by a warm solve that converges at iteration 0: a consistent_jacobian toggle, a jit_route switch, and the tangent restored after homotopy=True or homotopy="rate_strengthening". The solves are healthy. The source is the same: _check_velocity_preconditioner (systems/solvers.py) reads sub-KSPs from a PC that was never set up. A likely fix is to skip the check when getLinearSolveIterations() == 0.
Activity
lmoresi commentedon Oct 11, 2026
More triggers, from the adversarial review of the #794 merge (PR #794 merged with development at 2c6bc2f). The banner "Must call KSPSetUp() or PCSetUp() before calling PCFieldSplitGetSubKSP()" prints after any rewire followed by a warm solve that converges at iteration 0: a
consistent_jacobiantoggle, ajit_routeswitch, and the tangent restored afterhomotopy=Trueorhomotopy="rate_strengthening". The solves are healthy. The source is the same:_check_velocity_preconditioner(systems/solvers.py) reads sub-KSPs from a PC that was never set up. A likely fix is to skip the check whengetLinearSolveIterations() == 0.Review record for #794, round 3: the merge with development (tier 2, #…