Closed liamtoney closed 3 years ago
This could work and would be an improvement. However, I think a better/more complete solution would be to read in extra data on either end and taper on that extra data, rather than tapering on the data we want to process. What do you think?
a better/more complete solution would be to read in extra data on either end and taper on that extra data
Thinking about this more, isn't that essentially the same as specifying a starttime
and endtime
to grid_search()
? I'm thinking of this step:
if starttime:
S = S.where((S.time >= np.datetime64(starttime)), drop=True)
if endtime:
S = S.where((S.time <= np.datetime64(endtime)), drop=True)
So by providing data with some padding on either end of starttime
and endtime
(that gets tapered) and then discarding the resulting tapered ends of the stack function, aren't we doing the same thing?
(In any case, I think we'd still want this option for long data durations for the reason described in the initial post...)
When running for long data durations, the 5% taper we're using can cut into the data significantly. This is relevant for e.g. creating an explosion catalog, where we don't want to miss events on each "end" of the Stream due to the amplitudes being tapered out (e.g. for a 6 hr time series, 36 minutes are tapered).
This PR simply creates an additional keyword argument,
taper_length
, forprocess_waveforms()
that allows users to set a fixed taper [on each end] in seconds. The default behaviour (taper_length=None
) still performs the 5% taper [on each end].