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.
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
---------------------------------------------------------------------------
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.
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.
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]:
block.start_date = UTCDateTime(block.start_date.date)
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.