reading gcf (Guralp compressed file) data

Users Mailing List Archive
1

Dear obspy users

Does any of of you know if obspy can read gcc files or not?
In the obspy-documentation it says I can read gcc file by using read command:

from obspy import read

st=read(’/Users/me/Desktop/20130106_1200/bjnrn/20130106_1200n.gcf’)

but when I do this i get the following error:

TypeError: Unknown format for file /Users/me/Desktop/20130106_1200/bjnrn/20130106_1200n.gcf

Do you have any suggestion?
I want to convert my gcc file to mseed format, so any suggestions would be welcome.

With Kind Regards
Meysam

20130106_1200n.gcf (1.76 MB)

2

Hi Meysam

AFAIK obspy can not read/write gcf, but if all you want to do is to convert to mseed (miniSEED ?) why not use the command line tool GCF2MSD freely available from guralps homepage (http://www.guralp.com/sw/gcf2msd.shtml)?

That said, I just wrote a python extension module in C that can read and write gcf files according to the available documentation on the format. I've tested the code on the file you attached and it reads it fine. If you are interested in trying it out I'm glad to share (the more people testing it the more BUGS I will be able to track down and fix), however note that the code have only been tested on Linux and I have limited time aiding in compilation and and invocation of the module (actually not that hard and I have a python utility using the module to serve as an example). Further the data model returned is not the trace class of obspy, hence you need to build that yourself before you can use obspy to write the data to mseed.

In the long (long long) term run I would like to contribute the read/write capability to obspy, but that is not likely to happen in the near future. Further there are certain aspects that first needs to be figured out, perhaps some of the obspy authors will tune in on this thread and can give me some feedback directly, among the questions I have are

* can C-extension modules be added to obspy?
* Guralp does not carry information about network and station and only limited information on the instrument type (I may be wrong on this last point) how would this best be handled
* Guralp saves information about the sampling rate in an unsigned short (8 bit). Therefore only a limited number of sampling rates below 1 Hz and above 255 Hz are allowed and translated into numbers that can be handled by the format but deemed unlikely to be reel sampling rates. Any suggestion son how this would best be handled?

regP

3

I wrote a module that can read gcf files into obspy but haven’t uploaded to github. I’ve used it extensively but it should still be tested. There are some subtleties that you can gain control over by using this library and not a conversion tool. It is easier to diagnose problematic GCF files.

I will create a pull request as soon as I can.

4

Hi all,

the ObsPy master (and as a consequence the next ObsPy version) can
already read compressed G�ralp files:

In [2]: obspy.read("./20130106_1200n.gcf")
Out[2]:
13 Trace(s) in Stream:
.BJNR..HHN | 2013-01-06T12:00:00 ... | 200.0 Hz, 26600 samples
.BJNR..HHN | 2013-01-06T12:02:15 ... | 200.0 Hz, 42000 samples
.BJNR..HHN | 2013-01-06T12:05:47 ... | 200.0 Hz, 110800 samples
.BJNR..HHN | 2013-01-06T12:15:03 ... | 200.0 Hz, 42000 samples
.BJNR..HHN | 2013-01-06T12:18:35 ... | 200.0 Hz, 8400 samples
.BJNR..HHN | 2013-01-06T12:19:19 ... | 200.0 Hz, 25400 samples
.BJNR..HHN | 2013-01-06T12:21:47 ... | 200.0 Hz, 12400 samples
.BJNR..HHN | 2013-01-06T12:22:51 ... | 200.0 Hz, 8400 samples
.BJNR..HHN | 2013-01-06T12:23:35 ... | 200.0 Hz, 93200 samples
.BJNR..HHN | 2013-01-06T12:31:23 ... | 200.0 Hz, 204400 samples
.BJNR..HHN | 2013-01-06T12:48:27 ... | 200.0 Hz, 8400 samples
.BJNR..HHN | 2013-01-06T12:49:11 ... | 200.0 Hz, 102000 samples
.BJNR..HHN | 2013-01-06T12:57:42 ... | 200.0 Hz, 27600 samples

Doc: obspy.io.gcf - Guralp Compressed Format, GCF, read and write support for ObsPy — ObsPy 1.4.0.post0+326.gdfb021350c.obspy.master documentation
PR: https://github.com/obspy/obspy/pull/1449
Github: obspy/obspy/io/gcf at master · obspy/obspy · GitHub

I wrote a module that can read gcf files into obspy but haven't uploaded
to github. I've used it extensively but it should still be tested. There
are some subtleties that you can gain control over by using this library
and not a conversion tool. It is easier to diagnose problematic GCF files.

I will create a pull request as soon as I can.

We are of course always interested in things that improve or enhance
ObsPy so maybe check if your module has something that ObsPy does not
yet have?

    In the long (long long) term run I would like to contribute the
    read/write capability to obspy, but that is not likely to happen in
    the near future. Further there are certain aspects that first needs
    to be figured out, perhaps some of the obspy authors will tune in on
    this thread and can give me some feedback directly, among the
    questions I have are

Same comment as above.

    * can C-extension modules be added to obspy?

I assume you mean a C-extension that uses the CPython C API? In
principle yes as ObsPy does already require a C compiler. Practically we
currently don't link against libpython and just compile all C parts that
we have as shared libraries and call them with ctypes. That is also
quite a bit easier.

But if someone comes along with an actual C extension we can definitely
have a look and see if it entails any installation and distribution
problems or not.

    * Guralp does not carry information about network and station and
    only limited information on the instrument type (I may be wrong on
    this last point) how would this best be handled

Just leave them empty - there are already a couple file formats that do
this. But the gcf module in ObsPy does read a station code - did you
mean location code?

    * Guralp saves information about the sampling rate in an unsigned
    short (8 bit). Therefore only a limited number of sampling rates
    below 1 Hz and above 255 Hz are allowed and translated into numbers
    that can be handled by the format but deemed unlikely to be reel
    sampling rates. Any suggestion son how this would best be handled?

This only matters for writing to GCF (which ObsPy currently cannot do so
that would be nice to have). If the sampling rate as would be written to
the GCF file is very different from the one in the Trace, just raise a
descriptive error message explaining the problem. There is really
nothing else that can be done there.

Cheers!

Lion

5

Hi Lion

Just leave them empty - there are already a couple file formats that do
this. But the gcf module in ObsPy does read a station code - did you
mean location code?

No I meant station code, but from the output I note that the gcf reader in obspy sets the serial number as the station name (and this may very well be the station name, but by default is an instrument identifier), guess this is the reasonable choice and reading up on guralps homepage seems to what they do in their own mseed converter

regP

6

GCF packets have two codes that define a stream: stream ID and system ID. stream ID is (unless manually changed) the instrument serial number, location code and tap number: 6282E2.

station ID is usually the station name. it is rare but possible to have stream ID and system ID to have been mixed up and/or messed up as the names are not very self-explanatory. I’ve encountered this couple of times. I’ve made a list for such stations and swapped stream ID with system ID if the station is in the said list.

Because of these reasons, it would be helpful to read stream ID into the obspy trace object.

7

Dear Obspy users

Thank you so much for you replay and useful emails.
I’ve installed obspy master and problem solved.
Now I can read my gcf file by using _read_gcf(“gcf file”) command.

With kind regards
Meysam

8

Please note that whenever possible you should avoid to use internal,
lower level routines like '_read_gcf()'.

You should rather use the high-level core routine 'read()', optionally
specifying the file format explicitly if you want (to skip format
autodetection): 'read(..., format="GCF")'

T