Fix transfer-function plotting condition in fig_TF()

[starmetal-13]

While running the ATaCR transfer-function workflow for the ELVES station 3O.EL23A, the fig_TF() routine raised a KeyError: 'ZH' when generating the transfer-function figure.

The issue was traced to two conditions in obstools/atacr/plotting.py. The code was checking whether the transfer-function key existed in the day_list and sta_list dictionaries:

if key in day_list.keys():
if key in sta_list.keys():

However, these dictionaries contain all possible transfer-function names as keys, with their corresponding Boolean values indicating whether each transfer function is actually available. Therefore, checking only for key membership always returned True for existing keys, regardless of whether the associated transfer function had actually been calculated.

This caused fig_TF() to attempt to plot transfer functions that were not available in the corresponding object. For 3O.EL23A, for example, ZH is present as a possible daily transfer function but is not available in the monthly StaNoise transfer functions. The plotting routine therefore attempted to access the missing ZH transfer function and produced the KeyError.

The conditions were corrected to test the Boolean values themselves:

if day_list[key]:
if sta_list[key]:

This makes the plotting routine distinguish between a transfer-function name being defined in the dictionary and that transfer function actually being available for plotting.

No changes were made to the transfer-function calculations themselves or to the ATaCR processing workflow. The modification only corrects the logic used by fig_TF() when determining which already-calculated transfer functions should be plotted.

The fix was tested by rerunning atacr_transfer_functions for 3O.EL23A with the transfer-function figure enabled. The workflow completed without the previous KeyError, and the transfer-function figure was generated successfully.

[starmetal-13]

atacr_download_event currently aborts event processing when the ?DH pressure channel is not available, even though the code reports that it is continuing.

This change makes the pressure channel optional:

If ?DH data are available, they are processed as before.
If ?DH data are unavailable, the event continues using the three seismic components.
Pressure response removal is only attempted when a pressure trace is actually present.

No existing behaviour for stations with pressure data is changed.

Verification

Tested with the ELVES station 3O.EL23A, which has three seismic components (CH1, CH2, CH3) but no pressure channel.

Using the January 8, 2024 M6.7 earthquake SE of Sarangani, Philippines, atacr_download_event successfully:

downloaded CH1, CH2 and CH3 from the local SDS archive;
continued when ?DH was unavailable;
processed the three seismic components;
generated the three event SAC files.

The modified script also passes py_compile and git diff --check.