(no body)
Attachments
-
Emily,
Thanks for reporting this bug to SAC. I was able to reproduce this behavior on my system.
The error is from the ACC instrument response. The ACC instrument response should be:
ZEROS 2
POLES 0
CONSTANT 1.0
but the implementation in src/icm/acc.c is:
complexf pole[2], zero[1];
There should be two zeros, not one in the zero array.
That line above should be
complexf pole[2], zero[2];
A patch (text-file) to fix this is attached. If it does not fix the issue, please let me know.
This bug fix will be incorporated into the next version coming soon.
Thanks again.
Brian
savage<at>uri.edu
On Mar 19, 2013, at 3:53 PM, Emily Wolin wrote:
Hello all,
I recently upgraded from SAC 101.4 to 101.5c and have noticed some odd behavior in one of my macros that calls the "transfer" command. The macro (listed below; also attached as acc.m) removes the instrument response from a SAC file and writes an acceleration seismogram.
My macro:
** Prep for response removal
r US.AMTX..LHZ.SAC
rmean
rtr
taper type cosine width 0.1
** Remove instrument response
transfer from evalresp fname RESP.US.AMTX..LHZ to acc freqlimits 0.0016 0.006 .2 .28
w append .acc
In SAC 101.4, this seems to work. In 101.5c, the transfer command returns a trace with zero amplitude. All of the header information (npts, delta, station and event location, event time, etc.) is preserved. I don't see any error messages when running the macro. I have not seen any similar issues when using "transfer" to output displacement or velocity seismograms.
I am running Mac OS X 10.6.8 and first noticed the problem when using the 64-bit binary (downloaded on 27 Aug 2012). I then tried building SAC from the source code and encountered the same behavior. Interestingly, this issue does not occur when I run SAC on a Linux machine using the 64-bit Linux binary. The output traces from Linux 101.5c and OS X 101.4 are identical.
The macro and a sample seismogram (with appropriate RESP file) are attached. Has anyone else noticed a problem with the transfer command? Can you reproduce this behavior on your own system? Is there something in the macro that might be causing this problem?
Thanks for your help,
Emily Wolin
PhD Candidate
Northwestern University
Dept. of Earth and Planetary Sciences
emilyw<at>earth.northwestern.edu
<US.AMTX..LHZ.SAC><RESP.US.AMTX..LHZ><acc.m>_______________________________________________
sac-help mailing list
sac-help<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-help
Attachments
-
In parallel, I verified that Emily's did not work on SAC vv101.6c, but I
found that it did work on thesame computer (also Mac OS 10.6.8) on our
current 101.6 beta version.
It is good Brian has found the cause and a fix. What is puzzling is why
it sometimes works (e.g., Emily on v101.4 and me on 101.6 beta on the Mac,
Emily on Linux). If one does not have the source and needs acc, one could
probably use the unary diff function.
On Tue, 19 Mar 2013, Brian Savage wrote:
Emily,
Thanks for reporting this bug to SAC. I was able to reproduce this
behavior on my system.
The error is from the ACC instrument response. The ACC instrument
response should be:
ZEROS 2
POLES 0
CONSTANT 1.0
but the implementation in src/icm/acc.c is:
complexf pole[2], zero[1];
There should be two zeros, not one in the zero array.
That line above should be
complexf pole[2], zero[2];
A patch (text-file) to fix this is attached. If it does not fix the
issue, please let me know.
This bug fix will be incorporated into the next version coming soon.
Thanks again.
Brian
savage<at>uri.edu
-
Thank you for the patch, Brian! It seems to be working, and I'll keep
testing it to make sure.
I'm not sure why this would happen only for certain versions/operating
systems, but if anyone figures out why this is going on, I'd be interested
to hear about it.
Thanks!
Emily
-