Hi all,
I have a large duration of miniseed data downloaded from IRIS, which I am slicing into day chunks to integrate with the rest of our archive structure. I read the data into obspy in chunks as detailed here (and suggested in the "ObsPyMSEEDFilesizeTooLargeError" message) unable to read large mseed file by krischer · Pull Request #1419 · obspy/obspy · GitHub . I then slice the miniseed into day chunks (using st.slice() ) and write them to individual miniseed files using st.write() . This all runs successfully.
However, some of the miniseed files produced, though readable by obspy, are not readable by mseedcut, mseedinfo etcetera (from the GIPPTOOLS collection of seismic processing tools) which are heavily integrated into our processing routines and work with all the rest of our data. The error messages are as follows:
mseedinfo 2015114_000000_BORG_Z2M.m
Hi Tom,
hard to see what is going on in your hexdump without the ASCII
representation. Can you upload the two files somewhere?
Also note that the byte order/word order flag is part of blockette 1000
so the header byteorder first has to be determined via some heuristics
before blockette 1000 can be read in the first place. One of the
oddities of the MiniSEED format.
A total wild guess what might be going wrong here: Your tools might
assume that the first blockette in a MiniSEED header is blockette 1000
and not properly traverse the blockette chain. ObsPy (under some
conditions) might write other blockettes first. The fixed MiniSEED
header only has limited precision for the sampling rate and the start
time. If ObsPy discovers that more precision might be required it also
adds blockettes 100 and/or 1001 to the record as these have fields to
allow for higher precision. This might explain why you see the error
only for some files. But this all is just a guess.
If that is indeed the root cause - what might "fix" it for you: Make
sure neither the sampling rate nor the start times have too much
apparent precision.
Cheers!
Lion
Hello,
I'm the author of the GIPPtools and I can confirm that the programs
indeed expect either a zero ('0') or a one ('1') in the word-order field
of blockette #1000. Finding a different value in this field ('39') will
trigger the mentioned error message and abort processing.
Why there is a '39' in the respective field I don't know, but as the
GIPPtools do actually traverse the blockette chain to locate blockette
#1000 you can probably remove the case "different blockette ordering"
from the list of suspects.
Tom, could you please provide me with a sample of the problematic
miniSEED? (I'm also awful at reading hex-dumps. 
) I'll send it
through the debugger and make sure it is definitively not a problem
traversing the blockette chain. Maybe I can spot something peculiarity
in the miniSEED header.
Also, just as a (temporary) workaround, you could also use the
'mseedcut' command of the GIPPtools to "chunk" your input data. The
'--file-length' option will just do that for you.
Lion, you mention blockette #1001 and #100. The GIPPtools do correctly
handle blockette #1001 but I have not yet come across a miniSEED file
using blockette #100. (Non of the instruments in use at the GIPP
generates them.) Do you by any chance have a small sample file at hand
that you could send to me? If ObsPy generates that blockette then it
looks to me like a worthwhile addition to GIPPtools miniSEED handling.
Cheers Christof