Hi Aurélien,
Le 22/09/2014 21:20, Aurélien Mordret a écrit :
Greetings Thomas, greetings dear MSNoise users,
First of all, I would like to thank the authors for their invaluable
contribution: MSNoise is a really nice piece of work!! Congrats!
Thanks a lot !!
Now let me start with my questions:
I'm computing correlations from LHZ components (1 Hz sampling frequency),
I'm asking for 1Hz output correlations so I put the re-sampling parameter
at 1 Hz. I correlate chunks of data 14400 s long (4 hours).
1) I obtain this annoying warning in the whiten.py function (I show just
one example, but it happens at every lines involving the parameter 'high',
lines 86,100,102)
./MSNoise-1.2.4/whiten.py:102: DeprecationWarning: using a non-integer
number instead of an integer will result in an error in the future
FFTRawSign[high:-high] *= 0
I understand that is because 'high' is an indice and should be an integer,
but I don't really understand why it is NOT an integer in my case because
it seems to me that this problem has been assessed in the s03compute_cc.py
function(line 380-382).
Is it because, line 398-399, in the function whiten, Nfft should be
replaced by int(Nfft)? Beside the bunch of messages on the screen, it does
not affect the correlation computation.
Indeed, this should be already addressed. I'll double check the code on
GitHub... Are you using the latest version ?
2) Some times to times, when I'm computing the correlations, the function
exits with an error when trying to gather daily files which have not the
same type (I don't know what that means...)
Traceback (most recent call last):
File "s03compute_cc.py", line 214, in <module>
stream.merge(fill_value=0)
File "/usr/local/lib/python2.7/dist-packages/obspy/core/stream.py", line
1715, in merge
self._mergeChecks()
File "/usr/local/lib/python2.7/dist-packages/obspy/core/stream.py", line
1660, in _mergeChecks
raise Exception(msg)
Exception: Can't merge traces with same ids but differing data types!
I checked the file where it seems there is a problem, but it looks OK.
My solution so far is just to jump to the next job by re-running the
correlation function but it's annoying to have to check regularly if the
run wasn't aborted.
I know it's more an obspy problem than a MSNoise one, but, does anyone
faced this problem before?
Well... this is strange... You shouldn't have two
traces with same ids
and different dtype... Could you send me the files corresponding to this
day/job ? Your solution is clearly not desired in the long term... I
could think of some extra pre-calculation sanity checks on the
scanned-archive (data_availability table in the DB)...
Cheers,
Thomas
Thanks,
Aurelien