[obspy-users] How to modify stationXML file

miha lanjscek miha.bond at gmail.com
Thu Oct 20 16:30:06 CEST 2016


Yes, you are quite right.
In this example, the corrected waveform was so ahead the original, that it
would produce big errors at seismic phases determination.
I looked at some other station with different seismometers and found out
that the corrected waveforms are also ahead of the original but the
difference is much smaller.

Thank you for explanation,

Miha

On Thu, Oct 20, 2016 at 3:55 AM, Youngman <youngman at earth.sinica.edu.tw>
wrote:

> Hi Miha,
>
>
>
> From my view your code works fine, as the microseismic signal before the
> event of the corrected waveform showing little time lead of original one.
> The time lead you observed from the event is due to the instrument response
> itself, as you can see from the ‘read_inventory’ that the phase is lag
> after frequency above 0.2 Hz, so corrected event waveform is ahead of
> original one after removing response.
>
>
>
> The reason you cannot write corrected data into MSEED format is because
> standard MSEED is integer format.
>
>
>
> Hope that helps!
>
>
>
> Best,
>
> Youngman
>
>
>
> *From:* obspy-users-bounces at lists.swapbytes.de [mailto:
> obspy-users-bounces at lists.swapbytes.de] *On Behalf Of *miha lanjscek
> *Sent:* Wednesday, October 19, 2016 9:08 PM
> *To:* users at obspy.org
> *Cc:* obspy-users at lists.swapbytes.de
> *Subject:* Re: [obspy-users] How to modify stationXML file
>
>
>
> I apologize for the bug in my code, if you want to see the response for my
> channel of interest(HHZ), then the correct version of the last 2 lines of
> the code is:
>
> #######
>
> inv = read_inventory('C:\path\to\CRES.xml')[0][0][23].response
> inv.plot(0.01, output='VEL')
>
> #######
>
> sorry for the inconvenience
>
> Miha
>
>
>
> On Tue, Oct 18, 2016 at 4:24 PM, miha lanjscek <miha.bond at gmail.com>
> wrote:
>
> Hi Lion,
>
> Thank you for your fast response.
> My question was awkwardly composed, the main problem is that after I
> remove response, the result is ahead of the original, and yes, then I tried
> manually to change stationXML file, to see what happens with the delay.
>
> Quanterra digitizers, that we are using, already correct delay, that
> occurs at digital analog conversion stage, therefore, the <delay> in
> the <decimation> stages in stationXML file is always 0.
> Here is the link to this stationXML file(generated by Antelope 5.5) for
> specific station named CRES, and also the link the waveform
>
> https://www.dropbox.com/s/xsg3owz9ogy2024/CRES_HHZ?dl=0
>
> https://www.dropbox.com/s/745hkz88lsqxfus/CRES.xml?dl=0
>
> Here is the code, where I implement everything
>
> ########
> from obspy import read, read_inventory
>
> wf = read('C:\path\to\CRES_HHZ')
> t = wf[0].stats.starttime
> wf.write('C:\path\to\CRES_original.mseed', format='MSEED',
> encoding='STEIM2')
> print("data type: ", wf[0].data.dtype)
> wf.plot(dpi=55, starttime=t + 29.75, endtime=t + 30.5)
>
> inv = read_inventory('C:\path\to\CRES.xml')
> pre_filt = (0.001, 0.005, 70.0, 80.0)
> wf.remove_response(inventory=inv, output='VEL', water_level= 60,
> pre_filt=pre_filt, plot=False)
>
> print("data type: ", wf[0].data.dtype)
> wf.plot(color="black", dpi=55, starttime=t + 29.75, endtime=t + 30.5)
>
> wf.write('C:\path\to\CRES_removeResp.mseed', format='MSEED',
> encoding='FLOAT64')
>
> inv = read_inventory('C:\path\to\CRES.xml')[0][0][0].response
> inv.plot(0.01, output='VEL')
>
> ########
>
> As you can see from the results, the waveform is ahead of the original.
> The only reason for this, that I could think of, is the change in data
> type from int32 to float64. After I remove response,I cannot write it to
> file if
> I don't change encoding from 'STEIM2' to 'FLOAT64', because it returns
> 'Wrong dtype for Stream[0].data for encoding FLOAT64.'
>
> cheers,
>
> Miha
>
>
>
> On Mon, Oct 17, 2016 at 4:18 PM, Lion Krischer <krischer at geophysik.uni-
> muenchen.de> wrote:
>
> Hi Miha,
>
> kind of hard to judge without an example. Can you send a long a short
> code snippet + data if appropriate to help diagnose the issue? A couple
> thoughts:
>
> (1) Keep in mind that (especially if you use the pre_filt option)
> instrument correction is not a causal procedure. ObsPy implements it as
> a spectral division which might well introduce acausality.
>
> (2) Did you have a look at the phase response? (inv.plot_response(0.001))?
>
> (3) There might be a good reason for why the corrected trace is earlier
> in time. I guess you already noticed that, but for example the
> decimation stages can have a time delay and also indicate whether the it
> has already been corrected for by the data center. If not, the
> instrument correction should correctly shift them in time.
>
> (4) If you don't have a very good reason, better don't modify the
> StationXML files. There is probably a reason for these values.
>
> Cheers!
>
> Lion
>
>
>
> On 17/10/16 10:14, miha lanjscek wrote:
> > Dear all,
> >
> > I am trying to remove instrument response using remove_response function
> > and stationXML file.
> >
> > The result itself is OK, except that the waveform precedes the original
> > for about 0.1 second.
> >
> > Now I am trying to change the stationXML file parameter for station and
> > channel that I am using, to see how this effects the outcome. I changed
> > the number in all <delay> tags and also the <value> in
> > <InstrumentSensitivity> tag, but there seems to be no effect.
> >
> > Can anyone tell me, how to change stationXML file in such way, that it
> > will effect the result?
> >
> > Thanks for the answer in advance,
> >
> > Miha
> >
> >
>
> > _______________________________________________
> > obspy-users mailing list
> > obspy-users at lists.swapbytes.de
> > http://lists.swapbytes.de/mailman/listinfo/obspy-users
> >
> _______________________________________________
> obspy-users mailing list
> obspy-users at lists.swapbytes.de
> http://lists.swapbytes.de/mailman/listinfo/obspy-users
>
>
>
>
>
> _______________________________________________
> obspy-users mailing list
> obspy-users at lists.swapbytes.de
> http://lists.swapbytes.de/mailman/listinfo/obspy-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.swapbytes.de/pipermail/obspy-users/attachments/20161020/fb581dd4/attachment-0003.html>


More information about the obspy-users mailing list