Response removal prevented unneccessarily for response list type response in some cases

[megies]

In the case of Responses containing (or well, sometimes solely built of) a Response list type stage (Frequency-Amplitude-Phase tuples), we are forcefully raising an exception if an extrapolation would have to occur, i.e. the given response list stage does not span the full range of frequencies needed for response removal.

obspy/obspy/core/inventory/response.py

Lines 1387 to 1394 in 38d86b1

	if min_f < min_f_avail or max_f > max_f_avail:
	msg = (
	"Cannot calculate the response as it contains a "
	"response list stage with frequencies only from "
	"%.4f - %.4f Hz. You are requesting a response from "
	"%.4f - %.4f Hz.")
	raise ValueError(msg % (min_f_avail, max_f_avail, min_f,
	max_f))

File .../lib/python3.9/site-packages/obspy/core/inventory/response.py:1385, in Response._call_eval_resp_for_frequencies(self, frequencies, output, start_stage, end_stage, hide_sensitivity_mismatch_warning)
   1379 if min_f < min_f_avail or max_f > max_f_avail:
   1380     msg = (
   1381         "Cannot calculate the response as it contains a "
   1382         "response list stage with frequencies only from "
   1383         "%.4f - %.4f Hz. You are requesting a response from "
   1384         "%.4f - %.4f Hz.")
-> 1385     raise ValueError(msg % (min_f_avail, max_f_avail, min_f,
   1386                             max_f))
   1388 amp = scipy.interpolate.InterpolatedUnivariateSpline(
   1389     f, amp, k=3)(frequencies)
   1390 phase = scipy.interpolate.InterpolatedUnivariateSpline(
   1391     f, phase, k=3)(frequencies)

ValueError: Cannot calculate the response as it contains a response list stage with frequencies only from 0.1000 - 80.4000 Hz. You are requesting a response from 0.0038 - 125.0000 Hz.

When this was implemented this was probably chosen just as the easiest and safest route possible, however it prevents response removal in some very valid scenarios. Even if the response list stage does not cover all frequencies technically needed, it may well cover the frequency range of interest (a lot of times a bandpass is applied later on anyway) and in any case it is very easy to ensure there are no problems by using pre_filt (or water_level) to suppress out-of-range frequencies.

I think we should change this exception into a warning. If we want, we could even make the warning conditional and check in the high level routines (probably just need it in Trace.remove_response) if water_level/pre_filt seem sufficient to prevent problems.

This is a (simplified) example response to illustrate the issue, green box with red borders is the frequency range defined in the response list stage:

When interested in e.g. 1-20 Hz, there really isn't a problem why the response shouldn't be usable, a simple pre_filt=(0.1, 0.3, 50, 80) can make sure there are no problems in the deconvolution.

PR Checklist

• Correct base branch selected? master for new features, maintenance_... for bug fixes
• This PR is not directly related to an existing issue (which has no PR yet).
• If the PR is making changes to documentation, docs pages can be built automatically.
  Just add the "build_docs" tag to this PR.
• If all tests including network modules (e.g. clients.fdsn) should be tested for the PR,
  just add the "test_network" tag to this PR.
• All tests still pass.
• Any new features or fixed regressions are covered via new tests.
• Any new or changed features are fully documented.
• Significant changes have been added to CHANGELOG.txt .
• First time contributors have added your name to CONTRIBUTORS.txt .
• If the changes affect any plotting functions you have checked that the plots
  from all the CI builds look correct. Add the "upload_plots" tag so that plotting
  outputs are attached as artifacts.
• Add the "ready for review" tag when you are ready for the PR to be reviewed.

[trichter]

I agree. I'd suggest to just extrapolate the amplitude and phase values constantly beyond the smallest and largest frequencies in the reponse list and raise a warning as you suggest. I guess, the real amplitude of the response at undefined frequencies is lower than the amplitudes given at the lowest/highest frequency in most cases. Therefore, after response removal, amplitudes will be lower than real amplitudes for the frequencies outside of the defined range and no distortions are expected. As you said with using pre-filt you are even more on the safe side.

[megies]

I'd suggest to just extrapolate the amplitude and phase values constantly beyond the smallest and largest frequencies in the reponse list

Yes, that's pretty much what is done currently if you just comment out that block that raises the exception, the spline interpolation just extrapolates outside of the given range, like shown in the response plot above (that is with the "raise" statement commented out)

[megies]

Changed raising an exception into showing a warning.
I'd like to have this in 1.3.0, for absolutely selfish reasons ;-)