[MSNoise] (no subject)

[Thomas Lecocq]

Aurélien:

this line https://github.com/ROBelgium/MSNoise/blob/master/whiten.py#L66 
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 at oma.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 at mailman-as.oma.be
>> http://mailman-as.oma.be/mailman/listinfo/msnoise
>>
>
>