is the culprit,
edit it to be
high = Nfft // 2
and that will work...
NB: What are the frequency bounds you are using ? up to 0.5 Hz ?
Thomas
Le 23/09/2014 15:07, Aurélien Mordret a écrit :
Hi Thomas,
2014-09-23 5:37 GMT-04:00 Thomas Lecocq <thomas.lecocq(a)oma.be>be>:
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 ?
I think so, I download it last week... Version 1.2.4.
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)...
I'm not familiar yet with obspy (yes, same on me...), what are exactly
the
trace ids and dtypes? I may have found one possible explanation. In my SDS
archive I have sometimes for the same station two location codes and some
data are redundant: I have twice the same data in two different files. I
did not pay attention to that when I downloaded the data from IRIS.
Actually, the location codes are more or less complementary but sometimes
they overlap. How does MSNoise deal with that? However, I could'nt say
exactly what file did mess the thing as I re-run directly when it crashes
and I lost the log file in the process.
I'll do some tests and I tell you.
Cheers,
Thomas
Thanks,
Aurelien
_______________________________________________
MSNoise mailing list
MSNoise(a)mailman-as.oma.be
http://mailman-as.oma.be/mailman/listinfo/msnoise
_______________________________________________
MSNoise mailing list
MSNoise(a)mailman-as.oma.be