Thread: strange behavior with "transfer" command

Started: 2013-03-19 21:53:34
Last activity: 2013-03-20 17:36:54
Topics: SAC Help
Emily Wolin
2013-03-19 21:53:34
(no body)
  • Brian Savage
    2013-03-20 01:47:22
    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
    • Arthur Snoke
      2013-03-20 02:57:20
      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



    • Emily Wolin
      2013-03-20 17:36:54
      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

15:21:23 v.22510d55