[MSNoise] (no subject)

[Aurélien Mordret]

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
>



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

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