[claude]

Closes #138

What was wrong

The SLIPT1 block of an SRF holds slip rate (cm/s), not slip. The sum of a row times dt equals the patch's total slip. You can check this on tests/srfs/3468575.srf: the median of rowsum * dt / slip is 1.000001. But SrfFile documented slipt1_array[i, j] as "the slip for the ith patch", and to_xarray labelled the slip dataset with units: "cm". The docs also didn't say that column j is absolute time j * dt, so each row's non-zero entries start at floor(tinit / dt) (src/srf_parser.rs).

What changed

These are documentation and metadata changes only, all in source_modelling/srf.py:

• The SrfFile.slipt1_array docstring now says slip rate (cm/s), absolute time j * dt, and that row i starts at floor(tinit / dt).
• The slip property docstring now says slip-rate functions (cm/s).
• The to_xarray slip dataset attrs are now units: "cm/s" and description: "Slip rate for each patch at each timestep".

Tests

No test added. While checking this, I found that these attrs never reach the output. to_xarray calls xr.merge(datasets) with the default combine_attrs="override", which keeps only the first dataset's attrs (the header dataset has none). So SrfFile.to_xarray().attrs is just {'version': ...}, and neither to_xarray nor write_hdf5 exposes units/description anywhere. Changing the attr values therefore alters no observable behaviour, so no test can fail before this change. The full suite passes (800 passed).

For reviewers

• The issue says the cm units are written into every HDF5 file. As explained above, they are actually dropped. I left that alone because fixing it would change the HDF5 output, which is beyond this issue. A maintainer may want to decide separately whether these attrs should be kept, e.g. as variable-level attrs on data.
• No numerical behaviour changed.

🤖 Generated with Claude Code