# HowTo RESP ?

**URL:** <https://discourse.obspy.org/t/howto-resp/211>\
**Category:** Users Mailing List Archive\
**Tags:** archive\
**Created:** [September 11, 2013, 5:25pm UTC](https://discourse.obspy.org/t/howto-resp/211 "2013-09-11T17:25:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peter\_Danecek1](https://discourse.obspy.org/user_avatar/discourse.obspy.org/peter_danecek1/32/1123_2.png) [@Peter\_Danecek1](https://discourse.obspy.org/u/Peter_Danecek1)\
**Post date:** [September 11, 2013, 5:25pm UTC](https://discourse.obspy.org/t/howto-resp/211/1 "2013-09-11T17:25:33Z")

</div>

Hi all,

I am currently exploring several options to do instrument correction with ObsPy. Doing this, I encountered some problem in using evalresp for deconvolution. The idea is to use full SEED file to obtain a waveform as well as the RESP file, which is used later for instrument correction.

However, the script I came up with would not work, so I wonder what I understood wrong. It is attached for reference. Strangely enough, when I download a corresponding dateless and reference these RESP file instead. The procedure seem to terminate correctly. Again, when I use rdseed to extract RESP files from the full SEED, the procedure would fail.

To me it looks a bit like the selection for the time range, which is relatively short for the data RESP file 5 mins or so, would fails. I don't claim this would be a bug, but the only explanation I could come up with and as I said I am not sure to understand things right.

I send a minimal test program and the traceback, also it is not too helpful to me. I am working with 0.8.4.

Thanks for any comments!  
~petr

[test\_resp.py](https://discourse.obspy.org/uploads/short-url/hxohydzOVcAuUeYhKLUKpBZhIVt.py) (975 Bytes)

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [September 11, 2013, 9:58pm UTC](https://discourse.obspy.org/t/howto-resp/211/2 "2013-09-11T21:58:08Z")

</div>

Hi Petr,

without the fullseed you're using I can't say much (can you put it for  
download somewhere or send it?). Your program looks OK to me..

Actually I was working on some convenience wrapping to be able to just  
give a Parser to seedresp yesterday. It's pretty much ready and probably  
be in master soon but that won't help you in 0.8.4 of course.

Btw, there is a command line tool obspy-dataless2resp that converts  
dataless files to RESP files (but of course it might be nicer to avoid  
having metadata duplicated in multiple files locally).

best,  
Tobias

> Hi all,
> 
> I am currently exploring several options to do instrument correction  
> with ObsPy. Doing this, I encountered some problem in using evalresp  
> for deconvolution. The idea is to use full SEED file to obtain a  
> waveform as well as the RESP file, which is used later for instrument  
> correction.
> 
> However, the script I came up with would not work, so I wonder what I  
> understood wrong. It is attached for reference. Strangely enough,  
> when I download a corresponding dateless and reference these RESP  
> file instead. The procedure seem to terminate correctly. Again, when  
> I use rdseed to extract RESP files from the full SEED, the procedure  
> would fail.
> 
> To me it looks a bit like the selection for the time range, which is  
> relatively short for the data RESP file 5 mins or so, would fails. I  
> don't claim this would be a bug, but the only explanation I could  
> come up with and as I said I am not sure to understand things right.
> 
> I send a minimal test program and the traceback, also it is not too  
> helpful to me. I am working with 0.8.4.
> 
> Thanks for any comments! ~petr
> 
> --- snip --- In [130]: execfile('transform.py') processing ID:  
> IV.MURB..HNE test/RESP.IV.MURB..HNE WARNING: no response found for  
> NET=\*,STA=\*,LOCID=\*,CHAN=\*,DATE=2012, 75  
> ---------------------------------------------------------------------------

ValueError Traceback (most recent call last)

---

<div class="post-metadata">

**Author:** ![Peter\_Danecek1](https://discourse.obspy.org/user_avatar/discourse.obspy.org/peter_danecek1/32/1123_2.png) [@Peter\_Danecek1](https://discourse.obspy.org/u/Peter_Danecek1)\
**Post date:** [September 12, 2013, 8:28am UTC](https://discourse.obspy.org/t/howto-resp/211/3 "2013-09-12T08:28:39Z")

</div>

Hi Tobias,

Thanks a lot for looking into this!

> Hi Petr,
> 
> without the fullseed you're using I can't say much (can you put it for  
> download somewhere or send it?). Your program looks OK to me..

I was considering sending the data file as well, but decided against doing so on the mailing list. I'll send it off-list to you.

> Actually I was working on some convenience wrapping to be able to just  
> give a Parser to seedresp yesterday. It's pretty much ready and probably  
> be in master soon but that won't help you in 0.8.4 of course.

Well, I observe that the instrument (de-)convolution might deserve some review, but I'd like to understand all better before commenting on this. And yes, checking out master is on my list, but I need to adhere to the release as well.

> Btw, there is a command line tool obspy-dataless2resp that converts  
> dataless files to RESP files (but of course it might be nicer to avoid  
> having metadata duplicated in multiple files locally).

I have not looked at this, but from what I saw the RESP files produced by ObsPy are identical to the ones produced by `rdseed`. The point would be not to fetch dateless at all. To this goal this will not be helpful, I guess.

Thanks again for all the effort!  
~petr

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [September 12, 2013, 10:02am UTC](https://discourse.obspy.org/t/howto-resp/211/4 "2013-09-12T10:02:30Z")

</div>

Hi Petr,

after looking at the files you sent me, it was clear that this is an  
issue we need to address.  
The problem basically is that the output RESP file (I would need to  
check but I assume the FullSEED delivered by the data center is like  
that already) has an epoch starting and ending sharply with the  
requested data start/endtime. It seems we were only passing the date to  
evalresp, though, which interpreted it as 12am (midnight) then and thus  
wasnt finding a matching epoch.  
See [evalresp RESP lookup failing with fine grained epochs (on sub-day level) · Issue #631 · obspy/obspy · GitHub](https://github.com/obspy/obspy/issues/631).

This is fixed in master.

best,  
Tobias

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [September 12, 2013, 10:21am UTC](https://discourse.obspy.org/t/howto-resp/211/5 "2013-09-12T10:21:10Z")

</div>

P.S.: As an (ugly and hackish) workaround when stuck with 0.8.4 you  
could reset all channel metadata to start at 12am of the respective date  
in your program (I think blockettes 52 are the only ones you would need  
to change):

p = obspy.xseed.Parser(fname)  
for block in p.blockettes[52]:  
&nbsp;&nbsp;&nbsp;&nbsp;block.start\_date = UTCDateTime(block.start\_date.date)

best,  
Tobias

---

<div class="post-metadata">

**Author:** ![Peter\_Danecek1](https://discourse.obspy.org/user_avatar/discourse.obspy.org/peter_danecek1/32/1123_2.png) [@Peter\_Danecek1](https://discourse.obspy.org/u/Peter_Danecek1)\
**Post date:** [September 12, 2013, 10:44am UTC](https://discourse.obspy.org/t/howto-resp/211/6 "2013-09-12T10:44:44Z")

</div>

Tobias,

> Hi Petr,
> 
> after looking at the files you sent me, it was clear that this is an  
> issue we need to address.  
> The problem basically is that the output RESP file (I would need to  
> check but I assume the FullSEED delivered by the data center is like  
> that already) has an epoch starting and ending sharply with the  
> requested data start/endtime.

Well, that is what I observed, but have not made exhaustive testing neither.

> It seems we were only passing the date to  
> evalresp, though, which interpreted it as 12am (midnight) then and thus  
> wasnt finding a matching epoch.

That was what I suspected.

> See [evalresp RESP lookup failing with fine grained epochs (on sub-day level) · Issue #631 · obspy/obspy · GitHub](https://github.com/obspy/obspy/issues/631).
> 
> This is fixed in master.

Thanks a lot for fixing this that fast!  
~petr