Pretty significant bug, when the user plots a RecordSection with option zero_pad_s to pad zeros to the start or end of the waveform, the plotted record section signal is artificially time-shifted by the pre-starttime time shift.
See normal record section
and one with zero pad [5, 0]s
Absolute time and data are not affected, as evidenced when you plot things directly with ObsPy
But the record sections definition of the time axis becomes incorrect. It shifts the time axis double so that the starting time is 2*zero_pad_s[0].
This is happening because I forgot to account for the zero pad when calculating the time_offset (which is used to store USER_T0 for synthetics).
bch0w
commented
1 week ago
Thanks @ammcpherson for pointing this out.
Pretty significant bug, when the user plots a RecordSection with option
zero_pad_sto pad zeros to the start or end of the waveform, the plotted record section signal is artificially time-shifted by the pre-starttime time shift.See normal record section
and one with zero pad [5, 0]s
Absolute time and data are not affected, as evidenced when you plot things directly with ObsPy
But the record sections definition of the time axis becomes incorrect. It shifts the time axis double so that the starting time is
2*zero_pad_s[0].This is happening because I forgot to account for the zero pad when calculating the
time_offset(which is used to store USER_T0 for synthetics).https://github.com/adjtomo/pysep/blob/0b22608a1cda52a9229987c49fff06de826fe662/pysep/recsec.py#L1056-L1076
This was then applied to the time axis during plotting leading to cumulative time shifts.
https://github.com/adjtomo/pysep/blob/0b22608a1cda52a9229987c49fff06de826fe662/pysep/recsec.py#L1795-L1802