Cory Reed
I am attempting to remove the instrument response for various stations
using the following command lines, similar to the SAC tutorials:
SETBB RES "RESP.IU.CCMxxx.BHE"
READ [input .sac file]
RTR
TAPER
TRANSFER FROM EVALRESP FNAME %res TO NONE FREQLIM 0.004 0.007 0.2 0.4
When I call the transfer function, I receive the following:
WARNING: no response found for NET=IU, STA=CCM, LOCID=*, CHAN=Q, ...
and a final error message (#2118) which states that no transfer function
has been applied.
My first thought was that the channel was wrong (I am working with BHE,
BHN, and BHZ channels, not 'Q', though that may be solely due to my
misconception of the variable). I am using SAC version 101.2, and the RESP
files were obtained using the following command:
rdseed -f dataless*CCM* -R -d
on a dataless metadata volume I obtained using a BREQ_FAST request.
Despite all of my efforts to find a solution, I am unable to bypass this
issue. Please offer whatever advice you are able to.
--
Best Regards,
Cory Reed
PhD Candidate
Geology & Geophysics Program
Department of Geological Sciences & Engineering
Missouri University of Science & Technology
129 McNutt Hall, Rolla, Missouri 65409
E-mail: caryrd<at>mst.edu
using the following command lines, similar to the SAC tutorials:
SETBB RES "RESP.IU.CCMxxx.BHE"
READ [input .sac file]
RTR
TAPER
TRANSFER FROM EVALRESP FNAME %res TO NONE FREQLIM 0.004 0.007 0.2 0.4
When I call the transfer function, I receive the following:
WARNING: no response found for NET=IU, STA=CCM, LOCID=*, CHAN=Q, ...
and a final error message (#2118) which states that no transfer function
has been applied.
My first thought was that the channel was wrong (I am working with BHE,
BHN, and BHZ channels, not 'Q', though that may be solely due to my
misconception of the variable). I am using SAC version 101.2, and the RESP
files were obtained using the following command:
rdseed -f dataless*CCM* -R -d
on a dataless metadata volume I obtained using a BREQ_FAST request.
Despite all of my efforts to find a solution, I am unable to bypass this
issue. Please offer whatever advice you are able to.
--
Best Regards,
Cory Reed
PhD Candidate
Geology & Geophysics Program
Department of Geological Sciences & Engineering
Missouri University of Science & Technology
129 McNutt Hall, Rolla, Missouri 65409
E-mail: caryrd<at>mst.edu
-
Cory,
My experience is that the evalresp option is very fussy about matches
between network/station/channel names between the RESP textfile and
the SAC file that you want to work on. Do a 'listhdr' on your SAC file
(checking in particular for kstnm and kcmpnm), and open your RESP file
in a text editor to compare.
If your SAC file has channel name Q and the RESP file has channel name
BHE, the transfer function is going to record that as an error and
crash. There are 2 possible quick workarounds *if appropriate for the
data*:
Either (i) edit the RESP file to replace all instances of 'BHE' by 'Q'
while you do the response transfer, then change them back again
Or (ii) change the SAC header to BHE, do the response transfer, then
change it back to Q again, e.g.
read sacfile
ch kcmpnm BHE
transfer from evalresp....
ch kcmpnm Q
w ...
However, if the response files are different between components for
this station (i.e. the parameters, not just the channel names), it
would be important to check why your component name is 'Q' rather than
'BHE' before implementing this quick-fix. Have the horizontals been
rotated?
Fiona Darbyshire.
On Mon, Nov 18, 2013 at 11:44 AM, Cory Reed <caryrd<at>mst.edu> wrote:
I am attempting to remove the instrument response for various stations using
the following command lines, similar to the SAC tutorials:
SETBB RES "RESP.IU.CCMxxx.BHE"
READ [input .sac file]
RTR
TAPER
TRANSFER FROM EVALRESP FNAME %res TO NONE FREQLIM 0.004 0.007 0.2 0.4
When I call the transfer function, I receive the following:
WARNING: no response found for NET=IU, STA=CCM, LOCID=*, CHAN=Q, ...
and a final error message (#2118) which states that no transfer function has
been applied.
My first thought was that the channel was wrong (I am working with BHE, BHN,
and BHZ channels, not 'Q', though that may be solely due to my misconception
of the variable). I am using SAC version 101.2, and the RESP files were
obtained using the following command:
rdseed -f dataless*CCM* -R -d
on a dataless metadata volume I obtained using a BREQ_FAST request.
Despite all of my efforts to find a solution, I am unable to bypass this
issue. Please offer whatever advice you are able to.
--
Best Regards,
Cory Reed
PhD Candidate
Geology & Geophysics Program
Department of Geological Sciences & Engineering
Missouri University of Science & Technology
129 McNutt Hall, Rolla, Missouri 65409
E-mail: caryrd<at>mst.edu
_______________________________________________
sac-help mailing list
sac-help<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-help
-
Cory,
Both the TRANSFER function and EVALRESP support have changed since v101.2.
If you would like to see if your data file and RESP file have a problem
with the current version (v101.6 today, but v101.6a within a few days),
sent me (off-list) your RESP and SAC waveform files. Send me the files as
they come out of rdseed (which also has been updated since v101.2 came
out).
Arthur
On Mon, 18 Nov 2013, Cory Reed wrote:
I am attempting to remove the instrument response for various stations using
the following command lines, similar to the SAC tutorials:
SETBB RES "RESP.IU.CCMxxx.BHE"
READ [input .sac file]
RTR
TAPER
TRANSFER FROM EVALRESP FNAME %res TO NONE FREQLIM 0.004 0.007 0.2 0.4
When I call the transfer function, I receive the following:
WARNING: no response found for NET=IU, STA=CCM, LOCID=*, CHAN=Q, ...
and a final error message (#2118) which states that no transfer function has
been applied.
My first thought was that the channel was wrong (I am working with BHE, BHN,
and BHZ channels, not 'Q', though that may be solely due to my misconception
of the variable). I am using SAC version 101.2, and the RESP files were
obtained using the following command:
rdseed -f dataless*CCM* -R -d
on a dataless metadata volume I obtained using a BREQ_FAST request.
Despite all of my efforts to find a solution, I am unable to bypass this
issue. Please offer whatever advice you are able to.
--
Best Regards,
Cory Reed
PhD Candidate
Geology & Geophysics Program
Department of Geological Sciences & Engineering
Missouri University of Science & Technology
129 McNutt Hall, Rolla, Missouri 65409
E-mail: caryrd<at>mst.edu
Fiona Darbyshire
Arthur Snoke
