Thread: bug on transfer evalresp

Started: 2010-09-28 18:12:49
Last activity: 2010-09-29 21:55:36
Topics: SAC Help
Marcelo Bianchi
bug on transfer evalresp
2010-09-28 18:12:49
Dear All,

Today I was using the transfer command to remove the instrument from resp
files and found something strange. The transfer evalresp couldn´t find the
RESP file because of a time calculation error.

My file started at 01:45:05.280 and the resp file, here is the output from
SAC and the header from the RESP file:

SAC> lh kzdate kztime


FILE: 2008.330.01.45.05.2800.PD.EW01..HHZ.D.SAC - 1
-----------------------------------------------

kzdate = NOV 25 (330), 2008
kztime = 01:45:05.280
SAC>


B052F22 Start date: 2008,330,01:45:05.2800
B052F23 End date: 2008,330,02:00:11.9200

when I try to run the transfer I got the folowing message:

SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
Extracting evresp response for EW01, HHZ...
[PD.EW01.*.HHZ] WARNING: no response found for
NET=PD,STA=EW01,LOCID=*,CHAN=HHZ,DATE=2008,330,1:45:5
No transfer function applied!
ERROR 2118: No transfer function applied.
SAC>

Pay special attention to the error output I noticed it was not considering
the miliseconds, it was trying to find the date equal to
'DATE=2008,330,1:45:5'. As a test case, If I change the RESP file, removing
the miliseconds part, like show below:

B052F22 Start date: 2008,330,01:45:05
B052F23 End date: 2008,330,02:00:11.9200

It works:

SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
Extracting evresp response for EW01, HHZ...

Station (EW01 ), Channel (HHZ )
Waveform multiplied by 1.000000 after deconvolution.
SAC>

As I could read from the Seed manual it should consider the miliseconds for
searching for the resp file don't ? Does anyone noticed this problem also ?
This bug was noticied on the folowing SAC version:

SEISMIC ANALYSIS CODE [06/07/2010 (Version 101.4)]
Copyright 1995 Regents of the University of California

SAC>

Regards,

Marcelo
--
Mobile ~ +47 9080 6225
http://sites.google.com/site/foo4funreborn/

  • Chad Trabant
    Re: bug on transfer evalresp
    2010-09-28 23:11:30

    Hi Marcelo,

    I don't think this is a very common error, most response definitions are not so precise to match the data to the millisecond. In fact most response information we have does not including any sub-second time component.

    I did some quick testing and there does seem to be a bug in evalresp where responses are not matched when the sub-second times are specified. We'll look into that. The practical solution is to not include such high precision times in your RESP files.

    cheers,
    Chad

    PS. Where did you get that RESP?

    On Sep 28, 2010, at 2:12 AM, Marcelo Bianchi wrote:

    Dear All,

    Today I was using the transfer command to remove the instrument from resp files and found something strange. The transfer evalresp couldn´t find the RESP file because of a time calculation error.

    My file started at 01:45:05.280 and the resp file, here is the output from SAC and the header from the RESP file:

    SAC> lh kzdate kztime


    FILE: 2008.330.01.45.05.2800.PD.EW01..HHZ.D.SAC - 1
    -----------------------------------------------

    kzdate = NOV 25 (330), 2008
    kztime = 01:45:05.280
    SAC>


    B052F22 Start date: 2008,330,01:45:05.2800
    B052F23 End date: 2008,330,02:00:11.9200

    when I try to run the transfer I got the folowing message:

    SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
    Extracting evresp response for EW01, HHZ...
    [PD.EW01.*.HHZ] WARNING: no response found for NET=PD,STA=EW01,LOCID=*,CHAN=HHZ,DATE=2008,330,1:45:5
    No transfer function applied!
    ERROR 2118: No transfer function applied.
    SAC>

    Pay special attention to the error output I noticed it was not considering the miliseconds, it was trying to find the date equal to 'DATE=2008,330,1:45:5'. As a test case, If I change the RESP file, removing the miliseconds part, like show below:

    B052F22 Start date: 2008,330,01:45:05
    B052F23 End date: 2008,330,02:00:11.9200

    It works:

    SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
    Extracting evresp response for EW01, HHZ...

    Station (EW01 ), Channel (HHZ )
    Waveform multiplied by 1.000000 after deconvolution.
    SAC>

    As I could read from the Seed manual it should consider the miliseconds for searching for the resp file don't ? Does anyone noticed this problem also ? This bug was noticied on the folowing SAC version:

    SEISMIC ANALYSIS CODE [06/07/2010 (Version 101.4)]
    Copyright 1995 Regents of the University of California

    SAC>

    Regards,

    Marcelo
    --
    Mobile ~ +47 9080 6225
    http://sites.google.com/site/foo4funreborn/

    _______________________________________________
    sac-help mailing list
    sac-help<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/sac-help


    • Marcelo Bianchi
      Re: bug on transfer evalresp
      2010-09-29 21:55:36
      Hi Chad,

      Actually I got this error from a dataset that I get from GEOFON. I requested
      data for P wave windows. And the responses I got
      (I don't know why) were matched to the windows I got. I will see if I could
      send you a package of seed that I results on the error
      for you to test since it's a restricted dataset. Lets see If I can get the
      permission to do it.

      The quick solution that I am doing is parsing my RESP files to sed filter
      like:

      sed -n '/^B052F22/s/\..*$/' InputResp > CorrectedResp

      regards,

      Marcelo Bianchi
      --
      Mobile ~ +47 9080 6225
      http://sites.google.com/site/foo4funreborn/



      2010/9/29 Chad Trabant <chad<at>iris.washington.edu>


      Hi Marcelo,

      I don't think this is a very common error, most response definitions are
      not so precise to match the data to the millisecond. In fact most response
      information we have does not including any sub-second time component.

      I did some quick testing and there does seem to be a bug in evalresp where
      responses are not matched when the sub-second times are specified. We'll
      look into that. The practical solution is to not include such high
      precision times in your RESP files.

      cheers,
      Chad

      PS. Where did you get that RESP?

      On Sep 28, 2010, at 2:12 AM, Marcelo Bianchi wrote:

      Dear All,

      Today I was using the transfer command to remove the instrument from resp
      files and found something strange. The transfer evalresp couldn´t find the
      RESP file because of a time calculation error.

      My file started at 01:45:05.280 and the resp file, here is the output from
      SAC and the header from the RESP file:

      SAC> lh kzdate kztime


      FILE: 2008.330.01.45.05.2800.PD.EW01..HHZ.D.SAC - 1
      -----------------------------------------------

      kzdate = NOV 25 (330), 2008
      kztime = 01:45:05.280
      SAC>


      B052F22 Start date: 2008,330,01:45:05.2800
      B052F23 End date: 2008,330,02:00:11.9200

      when I try to run the transfer I got the folowing message:

      SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
      Extracting evresp response for EW01, HHZ...
      [PD.EW01.*.HHZ] WARNING: no response found for
      NET=PD,STA=EW01,LOCID=*,CHAN=HHZ,DATE=2008,330,1:45:5
      No transfer function applied!
      ERROR 2118: No transfer function applied.
      SAC>

      Pay special attention to the error output I noticed it was not considering
      the miliseconds, it was trying to find the date equal to
      'DATE=2008,330,1:45:5'. As a test case, If I change the RESP file, removing
      the miliseconds part, like show below:

      B052F22 Start date: 2008,330,01:45:05
      B052F23 End date: 2008,330,02:00:11.9200

      It works:

      SAC> transfer from evalresp to none freqlimits 0.01 0.5 2. 5.
      Extracting evresp response for EW01, HHZ...

      Station (EW01 ), Channel (HHZ )
      Waveform multiplied by 1.000000 after deconvolution.
      SAC>

      As I could read from the Seed manual it should consider the miliseconds for
      searching for the resp file don't ? Does anyone noticed this problem also ?
      This bug was noticied on the folowing SAC version:

      SEISMIC ANALYSIS CODE [06/07/2010 (Version 101.4)]
      Copyright 1995 Regents of the University of California

      SAC>

      Regards,

      Marcelo
      --
      Mobile ~ +47 9080 6225
      http://sites.google.com/site/foo4funreborn/

      _______________________________________________
      sac-help mailing list
      sac-help<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/sac-help




SAGE Facility has been certified as a trustworthy data repository by the CoreTrustSeal Standards and Certification Board
10:22:52 v.22510d55