Non-standard combinations of Input-Output channels

[kkappler]

Currently MT TFs are only supported for the usual transfer functions. This means (neglecting the Remote reference station) we are regressing Y on X where Y is ["ex", "ey", "hz"], and X is ["hx", "hy"].

What if someone wanted to regress ["ex", "ey"] on ["hx", "hy", "hz"] for example. This is supported in principle by the processing configuration in aurora. After building the processing config, one would simply call:

for decimation in config.decimations:
    decimation.input_channels = ["hx", "hy", "hz"]
    decimation.output_channels = ["ex", "ey",]
    # decimation.reference_channels = ["hx", "hy", "hz"]

before process_mth5.

Expected Behavior

A TF would be yielded mapping ex to a linear combination of all three magnetics, and likewise for ey.

Current Behavior

This fails to work for the following reasons

Failure Reason 1

• [ ] around line 303 in aurora/pipelines/transfer_function_helpers.py the `effective_degrees_or_freedom_weights cannot handle the 3-input, 2-output model. However, if we comment out the lines:

  # W = effective_degrees_of_freedom_weights(X, RR, edf_obj=None)
  # X, Y, RR = apply_weights(X, Y, RR, W, segment=False, dropna=True)

  then the TF processing seems to work fine, so we could add a try/except, or upgrade the dof weights function.

Failure Reason 2

• [ ] After the TF is calculated it is packaged into an mt_metadata object: around line 552 of aurora/pipelines/process_mth5.py is the call to:

  tf_cls = tfk.export_tf_collection(tf_collection)

  this fails around line 610 of transfer_function_kernel.py at the time a tf is assigned to the mt_metadata object: tf_cls.transfer_function = tmp this traces to the core of mt_metadata

24:11:08T16:25:32 | ERROR | line:753 |mt_metadata.transfer_functions.core | _validate_input_dataarray | Input dimensions must be ['hx', 'hy'] not ['hx', 'hy', 'hz']

There is actually a legacy workaround for this in aurora, which is to pass the optional argument

return_collection=True to process_mth5. This will skip return the legacy TransferFunctionCollection object, like this:

Possible Solution

If we want to support non-standard TFs in general, we would need to modify mt_metadata, but to do this in aurora and use the legacy TFCollection, only minor changes are needed.

[kkappler]

To allow this functionality with the legacy TransferFunctionCollection output I forked a branch of aurora fix_mtpy_issue_67 where the changes are pushed.

There is an example tutorial here to see what (minor) changes need to be made when you process an mth5.

This seems to work for a single station, and in the remote reference case. To use these changes, one currently must work off of the fix_mtpy_issue_67 branch of aurora.