obspy read SAC: trace.stats.sac a subset of actual SAC header?

Users Mailing List Archive
1

Hello everyone,

I've got a SAC file that contains certain header values that are not reflected in the trace.stats.sac AttribDict after being read in by ObsPy. Specifically, I'm trying to get 'knetwk' or 'kstnm'. Is the trace.stats.sac dictionary only a subset of the actual SAC header?

Thanks for your help.

Best,
Jon

----- code ----

* When I look at it in SAC:

r myfile.sac
lh
  
  FILE: myfile.sac - 1

2

Hi Jonathan,

some of the SAC header entries are used to fill the standard trace.stats entries and are not listed again in the trace.stats.sac dictionary. Here are the assignment rules:

convert_dict = {'npts': 'npts',
                 'delta': 'delta',
                 'kcmpnm': 'channel',
                 'kstnm': 'station',
                 'scale': 'calib',
                 'knetwk': 'network',
                 'khole': 'location'}

so, for example, kstnm becomes the network entry in trace.stats, kstnm becomes the station entry.

Cheers,
Yannik

3

Yannik,

Thanks for replying. I saw these conversions, but didn't realize the original header values were not kept. Is there also some cannibalizing of the nzyear, nzhour, etc... fields in order to make the Trace.stats.starttime entry? If so, I think there may be some information lost when these "nz..." fields are discarded (e.g. for event-based reference times). For me, the expected behavior for when I use "read" on a SAC file is that no header information is discarded. Would you be receptive if I submitted an "enhancement" ticket?

Thanks again for your help and your work.

Best,
Jonathan

4

Dear Jonathan,

as Yannik said we parse some of the header values to gain a uniform
way to deal with different formats like MiniSeed, GSE2, Seisan ...

Therefor, we must actually convert some of the header info. However,
to my knowledge no header info is actually discarted (as I said, it
is just converted).

E.g. The nzhour, nzyear, ... forms the starttime. The event-base
reference time is stored as an offset of this time in trace.sac.b. We
have further a test-suite which assures that we actually can write the
same information as which we can read.

If you find a header entry which is not converted forward and backward
please report a bug --- this is actually valuable information. In
this bug report, please attach an example, so that we can reproduce
this issue and use this example as a basis for a new test.

Best regards,
M

5

Yannik and M,

Thanks for replying. I apologize if this is review for many people; I have to relearn this every time...
Is this pseudocode somewhat correct (at least for the event-based reftime)?

Best,
Jon

1) As I understand it,

reftime = sac.nzyear + ... + sac.nzmsec*1000
tr.stats.starttime = reftime + sac.b

2) Therefore,

if sac.iztype == 11:
  # event-based reftime
  origin_time = tr.stats.starttime - sac.b
  assert sac.o == 0
elif sac.iztype == 9:
  # 1st sample-based reftime
  first_samptime = tr.stats.starttime
  assert sac.b == 0.0
elif sac.iztype == 10:
  # Midnight of reference day
  midnight = tr.stats.starttime - sac.b
  assert sac.nzhour == 0
  assert sac.nzmin == 0
  assert sac.nzsec == 0
  assert sac.nzmsec == 0
elif sac.iztype == 12:
  # sac.a-based reftime
  atime = tr.stats.starttime - sac.b
  assert a == 0
elif sac.iztype == 13 + 1*n:
  # pick n-based reftime
  tn_time = tr.stats.starttime - sac.b
  assert sac.tn == 0