Obspy: Behavior of SAC timing parameters when slicing and saving to disk

[LevCarlo]

When cutting the data with slice method, the attribute Trace.stats.sac would not change(specifically, the start time) after cutting. Therefore, it lose the information of absolute time while saving the slice data with SAC format. It will cause some trouble while reading the slice data again.

How can I fix it, Or is there some additionnal options?

[jkmacc-LANL]

Hi. I think tr.stats.sac will be overwritten by values in tr.stats on write. Have you written a SAC file after slicing it to be sure the header is incorrect?

If you are willing to provide a failing example, I'm happy to put it into a test for a PR. Thank you.

[LevCarlo]

tr.stats.sac will be overwritten by values in tr.stats on write

I run a test to explain my confusion and hope it can help.

SliceTest.pdf

[jkmacc-LANL]

@LevCarlo I think I see what's happening. Sample times in SAC are relative to a reference time, encoded in nzyear, nzjday, nzhour, etc. This reference time is independent of the data vector. You are expecting the SAC reference time (nzhour in this case) to change because you've trimmed the seismogram, but it won't change unless you require that the first sample time is the reference time. After you've trimmed and re-read the file, you can see that tr.stats.sac.b (the time of the first sample relative to the reference time) has moved according to your trimming. If you need the reference time to be the first sample time, you may need to use the lower-level obspy.io.sac.SACTrace class to do SAC-specific header manipulations instead of the higher-level Trace class.

[LevCarlo]

@LevCarlo I think I see what's happening. Sample times in SAC are relative to a reference time, encoded in nzyear, nzjday, nzhour, etc. This reference time is independent of the data vector. You are expecting the SAC reference time (nzhour in this case) to change because you've trimmed the seismogram, but it won't change unless you require that the first sample time _is_ the reference time. After you've trimmed and re-read the file, you can see that tr.stats.sac.b (the time of the first sample relative to the reference time) _has_ moved according to your trimming. If you need the reference time to be the first sample time, you may need to use the lower-level obspy.io.sac.SACTrace class to do SAC-specific header manipulations instead of the higher-level Trace class.

Thanks for taking the time to answer my questions. I think I see.

[jkmacc-LANL]

@LevCarlo Do you think I can close this Issue?

[LevCarlo]

@LevCarlo Do you think I can close this Issue?

Of course.Thanks.