Repository navigation
solver.gradient() takes the adjoint of an unconverged forward solve and returns a wrong-signed number #804
Description
Activity
Not reproducible on
development(7c9cbbfd) — the adjoint API is not there:uw.adjoint present: False Stokes adjoint API: [] files with 'adjoint' in the path: 0Only scattered references remain (one line in
petsc_generic_snes_solvers.pyx, five inmcp/__init__.py, eight intranscript_query.py), not the implementation. So this defect lives in unmerged work —feature/discrete-adjoint(#744, currently conflicting and red),feature/adjoint-rotated-bc(#751, based on #744), orscratch/adjoint-merge.That is why it has sat untouched: there is nothing on the main line to fix. It is not
fixed-in-PR— the opposite. It has to be fixed on the branch before that branch lands, or it lands with the defect.Checked in the untouched-issue triage. Blocked behind #744, which needs its conflicts resolved and a CI re-run (its red check is
test_1063_constrained_traction, whose timeout #814 addressed when it merged on 2026-10-06).
_adjoint_supportdocuments that an unconverged solve is refused ("a linearisation about a state the solve never reached is not the adjoint of anything"), caught after the fact by_record_solve_outcome. That catch is on the recorded/transcript path. A directsolver.solve()followed bysolver.gradient(...)is not refused.Reproduced on
scratch/adjoint-merge(82e697b): softmin viscoplastic box,snes_max_it = 2.Wrong sign, no warning. Script:
~/+Simulations/adjoint_note_checks/unconverged_refusal.py.UWTN 2026-020 (draft) currently states that "the library refuses to take the adjoint of a solve that did not converge", so either the guard moves into
adjoint_solve/gradient(checksnes.getConvergedReason() > 0on the solver that did the solving) or the note's sentence goes. The first seems right: the note's argument — a multiplier is undefined off the constraint manifold — is exactly why this should be an error rather than a number.