release: 0.3.5

[GeophyAI]

Version bump for sweep-solver 0.3.5 (the RWI velocity gradient for AcousticLSRTM, #108; notebooks #107 / #109): pyproject version, the CHANGELOG [0.3.5] section and compare links, the API page eyebrow.

Already on PyPI:

• Wheel 69673f0f, 42.5 MB, and sdist 942a8f46.
• Cores cu12 0800bee2 and cu13 903902ae, rebuilt in manylinux_2_28 (GLIBC 2.17 / GLIBCXX 3.4.22). Against 0.3.4's cores only LSRTM kernels changed machine code: every other kernel's SASS is byte-identical on every arch.

Checked before upload:

• This tree with the shipped cu12 core: full suite, 1914 passed, 44 skipped.
• Clean venv on an RTX 6000 Ada: the wheel loads its own core and compiles nothing. Installed tests (0.3.4's list + test_lsrtm_rwi_vp_gate.py): 547 passed, 2 skipped.
• The same wheel on an A100, in a cu13 env (torch 2.14) and a cu12 env (torch 2.5):
  • Each env loads its own core and compiles nothing. Installed tests: cu13 547 passed, cu12 548 passed.
  • LSRTM, cu13 vs cu12, with and without the vp gradient: 36 of 40 tensors bit-equal; the other 4 (lsrtm3d checkpoint mp gradients) are within the run-to-run floor. vp.grad is non-zero in full / bs and zero in the checkpoint modes.
  • Every impl='c' equation, 0.3.4 wheel vs 0.3.5 wheel (separate venvs: the 0.3.5 package refuses a 0.3.4 core):
    • LSRTM: the vp gradient is new in full / bs (20 arrays); every other LSRTM array is within rel 9.75e-7 (FMA contraction).
    • Everything else: the same refusals; deterministic arrays bitwise equal (cu12 3138 / 3138, cu13 3138 / 3139, the odd one at rel 8e-40). The checkpoint families that are already nondeterministic in 0.3.4 (acoustic2d, VRZ3D) flag 3-4 arrays outside 8 runs' spread. Their kernels' machine code is byte-identical to 0.3.4's, so these are atomics, not changes.
  • Eager-vs-c gradient matrix (cu13): identical to 0.3.4 outside the LSRTM rows; acoustic_lsrtm2d / full goes from FAIL (vp zero) to PASS*.

🤖 Generated with Claude Code