Dear,
inside a Python script that prepares input files for HypoDD, I’m reading a series of Mseed files and getting this Warning message for each one:
“…InternalMSEEDWarning: readMSEEDBuffer(): Record with offset=1573376 has a fractional second (.0001 seconds) of 10000. This is not strictly valid but will be interpreted as one or more additional seconds.”.
The script however continues and finishes correctly. I don’t know exactly what the problem is but since I’m working with P and S time picks I want to be sure that this issue can’t corrupt waveform timing or something else. Does anyone have ideas about this warning and how to fix it?
Without looking at details it sounds like a minor bug in whatever software wrote the MiniSEED, writing 10,000 into a filed that is expected to run from 0 to 9,999 (multiples of tenths of millisecond, to represent time values less than a second).
You know, kind of like how some programs write 60 into a field reserved for minutes, which can still be resolved (as an additional full hour) during reading but is kind of weird/unexpected usage of the “minute” field.
I would assume that everything is fine, but if you want to investigate more you would have to probably go into a debugger when this happens to investigate the file in question.
The miniseed files are taken from Seiscomp archive (SDS structure) and are generated using the command scart (https://www.seiscomp.de/doc/apps/scart.html). I didn’t generate the ms files myself so I don’t know the option used.
Anyway, could be a bug in Obspy and its compatibility with Seiscomp? I’m using obspy 1.4.0 version in a conda environment.
Like I said, from the above warning message, it looks like whatever software (the digitizer internally maybe?) wrote the original MSEED data (before it was transmitted via seedlink, presumably) seems to have written “sloppy” data.
ObsPy is just considerate enough to let the user know that something slightly off of the expected is going on. If you can find out what file is causing it, you could have a look at the respective chunk of data and probably the data is without a gap which would further corroborate that everything is in order. Like I said, it’s likely safe to ignore this warning.