Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-standard combinations of Input-Output channels #67

Open
2 tasks
kkappler opened this issue Nov 9, 2024 · 1 comment
Open
2 tasks

Non-standard combinations of Input-Output channels #67

kkappler opened this issue Nov 9, 2024 · 1 comment

Comments

@kkappler
Copy link
Collaborator

kkappler commented Nov 9, 2024

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:
image

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
Copy link
Collaborator Author

kkappler commented Nov 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant