srf.py: write_sw4_hdf5 drops the column indices of slipt1_array, so slip-rate functions are misplaced unless every row i #137

Location: source_modelling/srf.py:407 and :418 (SrfFile.write_sw4_hdf5).

points_data["NT1"] = np.diff(self.slipt1_array.indptr).astype(np.int32)
...
h5file.create_dataset("SR1", data=self.slipt1_array.data.astype(np.float32))

SW4 reads each point's NT1 samples of SR1 as a contiguous series starting at TINIT. The writer uses the number of stored entries as NT1 and the raw .data as SR1, and never looks at .indices. That is only right when every row is stored with no gaps from its first sample. The parser builds rows that way, but any csr_array a user builds (from a dense array, after eliminate_zeros(), or after arithmetic that drops zeros) is not. Interior zeros then disappear and the slip-rate function is squashed in time, without any warning.

Reproducer:

import h5py, numpy as np, scipy as sp
from source_modelling import srf
f = srf.read_srf("tests/srfs/3468575.srf")
dense = np.zeros((len(f.points), f.nt), dtype=np.float32)
dense[:, 10] = 1.0; dense[:, 20] = 1.0   # two pulses 10 steps apart
f.slipt1_array = sp.sparse.csr_array(dense)
f.write_sw4_hdf5(".ai/sw4.h5")
with h5py.File(".ai/sw4.h5") as h:
    print("NT1", h["POINTS"]["NT1"][:3], "SR1", h["SR1"][:4], "TINIT", h["POINTS"]["TINIT"][:3])

Output:

NT1 [2 2 2] SR1 [1. 1. 1. 1.] TINIT [5.7029 5.449  5.1804]

The two pulses, 0.25 s apart, are written as two back-to-back samples. The slip-rate duration is cut from 11 samples to 2.

This is the same assumption as #120 (Rust srf_writer.rs), but in the Python SW4 writer, so fixing #120 will not fix it.

Suggested fix: for each row, write the samples from the row's first stored column to its last, filling the gaps with zeros. NT1 is then that span length. Alternatively, check that each row's indices are consecutive and raise if not. Add a test that round-trips a CSR without explicit zeros.

Filed by the weekly issue sweep. Kind: bug, severity: medium.