Sheila Peacock
On 06/27/2011 06:39 PM, George Helffrich wrote:
(linearly from extremal two points; to zero at zero or infinite frequency,
etc.) The frequency limits aren't fully relevant -- the cut points are,
but not the pass points.
does with frequencies outside the FAP range.
me if I am wrong, but it looks like you would like to associate a
freqlimits with the FAP files. It that is the case we can add in a
comment that tells SAC to extrapolate the response or truncate using
freqlimits. See possible example below. It would impose more control
over how the response is applied/removed from your data.
I've circulated the above to my colleagues and await their
responses. Mine is to think that Brian's suggestion is
good. I appreciate George's second point. If
"* Extrapolate Response: YES" was set instead of
the "NO" above, there is a risk with extrapolating linearly from
the final two points of a FAP file, that in a particularly
badly prepared FAP file, the final two points might define
an UPWARD trend, or a flat trend, or a vertical step, rather than
the desired downward one, and that the user might need a warning of
this. On the other hand, extrapolating by "joining the dots"
between the end point of the FAP and zero at the Nyquist
might bring on some Gibbs' phenomenon if the top of the
FAP was near in frequency to the Nyquist and had an amplitude
far from zero. See the second example I sent you, which
looked as if it might have tapered decently from its peak
at 6 Hz to zero at 20 Hz if someone had not taken a cleaver
to it at 10 Hz. It was a lousy FAP - but maybe that's
what the world will throw at your code...
While I agree with George's statement that only the cut points
of the frequency limits are relevant (as a means of limiting
the decon to the bandwidth contained in the FAP), I think that
there is an advantage to specifying all four frequency limits
in the same form as is used by the "transfer" program.
"transfer" would then be expected to use these frequency limits
unless they are overridden by frequency limits specified on
the command line, or by a switch, which you would have to
introduce as a new feature, indicating "ignore default
frequency limits set in file".
It is educational to put frequency limits into a PAZ file
because we should be reminded when Poles and Zeros have
been derived from bandlimited data.
Regards,
Sheila Peacock.
Dear All -The key factors are 1) whether to extrapolate or not; 2) how to extrapolate
While metadata might be a good idea, what's suggested here isn't.
(linearly from extremal two points; to zero at zero or infinite frequency,
etc.) The frequency limits aren't fully relevant -- the cut points are,
but not the pass points.
My own view is that SAC should warn the user that some extrapolationis being done and leave it to the user to diagnose. This is what MacSAC
does with frequencies outside the FAP range.
On 27 Jun 2011, at 18:30, Brian Savage wrote:We might be able to do such a thing for the FAP files as well. Correct
Sheila,
We, along with IRIS, are attaching metadata to the polezero files.
me if I am wrong, but it looks like you would like to associate a
freqlimits with the FAP files. It that is the case we can add in a
comment that tells SAC to extrapolate the response or truncate using
freqlimits. See possible example below. It would impose more control
over how the response is applied/removed from your data.
Dear All,Thoughts ?
Brian
* First one (LP seismo)
* Freqlimits : 0.011 0.01 10.0 11.0
* Extrapolate Response : NO
* Comment Here
* Another Comment Here
1.00000E-02 0.394768 282.522
2.00000E-02 3.11046 146.286
3.00000E-02 6.05993 53.0681
4.00000E-02 7.18071 -21.5560
5.00000E-02 6.35654 -82.4200
6.00000E-02 4.83388 -130.514
......
I've circulated the above to my colleagues and await their
responses. Mine is to think that Brian's suggestion is
good. I appreciate George's second point. If
"* Extrapolate Response: YES" was set instead of
the "NO" above, there is a risk with extrapolating linearly from
the final two points of a FAP file, that in a particularly
badly prepared FAP file, the final two points might define
an UPWARD trend, or a flat trend, or a vertical step, rather than
the desired downward one, and that the user might need a warning of
this. On the other hand, extrapolating by "joining the dots"
between the end point of the FAP and zero at the Nyquist
might bring on some Gibbs' phenomenon if the top of the
FAP was near in frequency to the Nyquist and had an amplitude
far from zero. See the second example I sent you, which
looked as if it might have tapered decently from its peak
at 6 Hz to zero at 20 Hz if someone had not taken a cleaver
to it at 10 Hz. It was a lousy FAP - but maybe that's
what the world will throw at your code...
While I agree with George's statement that only the cut points
of the frequency limits are relevant (as a means of limiting
the decon to the bandwidth contained in the FAP), I think that
there is an advantage to specifying all four frequency limits
in the same form as is used by the "transfer" program.
"transfer" would then be expected to use these frequency limits
unless they are overridden by frequency limits specified on
the command line, or by a switch, which you would have to
introduce as a new feature, indicating "ignore default
frequency limits set in file".
It is educational to put frequency limits into a PAZ file
because we should be reminded when Poles and Zeros have
been derived from bandlimited data.
Regards,
Sheila Peacock.
-
Sheila and others,
As I see it, there are two issues here:
1. Your specific situation in which you have a "motley" set of FAP file
that are to be applied in either convolution or deconvolution to a set of
instruments with various sample rates.
2. What does SAC do and is there something it should be doing
differently?
Regarding the first point, I think that to map your response into an
instrument for which you have a FAP file with band limits of 0.001 and 0.3
Hz, you need to prepare your data before calling transfer so that there is
little energy at 0.3 Hz and above either by SAC decimation or something
equivalent. Once that is done, a freqlimits argument to transfer with f4
= 0.3 Hz should work fine. At the high frequency end, the FREQ command
calls taper with a cosine taper from F3 to F4 and zero for frequencies
above F4.
I think it dangerous to extrapolate a response from two points. An
alternative is to prepare a new FAP file in which you do some kind of
spline fit and extrapolation to new frequency limits.
Regarding the second point, George raises a point I had overlooked:
warning the user if the FAP bands extend beyond F1 and F4. My thought had
been that FAP files would come from somewhere like EVALRESP which covers
the full spectrum. This should at least go into the HELP file. George, I
would appreciate it if you could send your macsac code so I can see how you
test and report.
Brian's suggestion is an interesting one of putting something into a FAP
file regarding limits, and Sheila's suggestion that it might be
interesting to have some meta statements in a PZ file might be useful. As
the current TRANSFER help file warns, it is a bad idea not to accompany a
polezero or fap argument with a freqlimits as the solution can blow up.
An alternative is to put in automatic FREQ limits for a FAP file with F1
and F4 set to the limits.
I personally do not use SAC to do an instrument correction because I think
one can do better than FREQ. I call my routine from within a sac script.
It does both decimation and instrument correction and handles up to
hundreds of stations.
Arthur Snoke
