v0.3.2 — pml_type validation and a torch.compile fallback

sweep-solver 0.3.2

A bug-fix release on top of 0.3.1. Upgrade with pip install -U sweep-solver. sweepx accepts 0.3.2, but pip install -U sweepx leaves an installed 0.3.1 solver in place.

Fixed

• pml_type is validated. A pml_type the equation was not written for raises ValueError at construction, naming the equation, the value and the supported ones. Before, it reached the kernels, which read the PML profiles positionally; Elastic with pml_type='cpmlr' on impl='c' aborted the Python process on a C assert. Leave pml_type unset: every equation ships one PML (Acoustic1st also takes 'spml'), now listed in its supported_pml property and in Equation.defaults(). The README, docs, notebooks and examples no longer pass it. (#99)
• impl='eager' survives a compiler that cannot build the step. use_compile defaults to True, and on CPU with g++ older than 10 the first forward raised InductorError: CppCompileError. The step now runs uncompiled, with one RuntimeWarning; results are identical to use_compile=False. Errors raised by the step itself still propagate. (#101)

Documentation

• The installation page has a PyTorch-style selector: GPU, driver and CUDA version give the matching torch command. It also has a Verification snippet. Build details moved to Developer › Building the CUDA core. (#98)
• Notebook 11 (3-D Overthrust FWI) runs on impl='c' with explicit BoundarySaving and a top free surface. (#100)

The CUDA cores are the 0.3.0 binaries, unchanged: cu12 c72bdc3a, cu13 10832c06.

Full changelog: v0.3.1...v0.3.2