[MSNoise] (no subject)

Tue Sep 23 15:17:13 UTC 2014

Thomas,

Thanks for the quick answer !

I pre-process between 0.01 and 0.49 Hz and the filter for the daily
correlations is low=0.01, low_mwcs=0.01, high_mwcs=0.49, high=0.49.

I am using the output for tomography for the moment that's why I used this
filter.

Aurelien

2014-09-23 11:06 GMT-04:00 Thomas Lecocq <thomas.lecocq at oma.be>:

> 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
>>>
>>>
>>
>>
> _______________________________________________
> MSNoise mailing list
> MSNoise at mailman-as.oma.be
> http://mailman-as.oma.be/mailman/listinfo/msnoise
>

-- 
==========================

Aurelien Mordret

Postdoctoral fellow
Department of Earth, Atmospheric and Planetary Sciences
Massachusetts Institute of Technology
54-526
Cambridge, MA  02139-4307
e-mail: mordret at mit.edu
web: http://web.mit.edu/mordret/www