fft error due to (endian?) discrepancy between data origin and user?

obspy-ers,

I have a problem with data format (I think):

from obspy import read
st = read(“http://examples.obspy.org/TOK.2011.328.21.10.54.OKR01.HHN.inv”)
st.resample(10)

print st

Traceback (most recent call last):
File “”, line 1, in
File “/home/kasper/fortobias.py”, line 3, in
st.resample(10)
File “/usr/lib/python2.7/site-packages/obspy-0.9.2-py2.7-linux-x86_64.egg/obspy/core/stream.py”, line 2040, in resample
strict_length=strict_length)
File “/usr/lib/python2.7/site-packages/obspy-0.9.2-py2.7-linux-x86_64.egg/obspy/core/util/decorator.py”, line 249, in new_func
return func(*args, **kwargs)
File “/usr/lib/python2.7/site-packages/obspy-0.9.2-py2.7-linux-x86_64.egg/obspy/core/trace.py”, line 1467, in resample
self.data = resample(self.data, num, window=window)
File “/usr/lib64/python2.7/site-packages/scipy/signal/signaltools.py”, line 1292, in resample
X = fft(x, axis=axis)
File “/usr/lib64/python2.7/site-packages/scipy/fftpack/basic.py”, line 222, in fft
raise ValueError(“type %s is not supported” % tmp.dtype)
ValueError: type >f4 is not supported

But if I filter before resampling, all is fine:

from obspy import read
st = read(“http://examples.obspy.org/TOK.2011.328.21.10.54.OKR01.HHN.inv”)
st.filter(“highpass”, freq=1.0)
st.resample(10)
print st

/usr/lib64/python2.7/site-packages/scipy/signal/signaltools.py:1303: DeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
W.shape = newshape
1 Trace(s) in Stream:
.OKR01…HHN | 2011-11-24T21:10:54.000000Z - 2011-11-24T21:16:03.900000Z | 10.0 Hz, 3100 samples

I run this on 64-bit linux:

[kasper@localhost ~]$ uname -a
Linux localhost.localdomain 3.17.3-200.fc20.x86_64 #1 SMP Fri Nov 14 19:45:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Hi Kasper,

interesting. I did not see that one before. SciPy’s FFT cannot deal with big endian floats. Converting the data before resampling solves the issue.

st[0].data = np.require(st[0].data, dtype=np.float32)

The same happens during filtering which will convert to native double precision floats.

This is an edge case bug with ObsPy and I opened a ticket here: https://github.com/obspy/obspy/issues/923

Cheers!

Lion