You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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
then the TF processing seems to work fine, so we could add a try/except, or upgrade the dof weights function.
Failure Reason 2
around line 552 of aurora/pipelines/process_mth5.py is the call to:
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
There is actually a legacy workaround for this in aurora, which is to pass the optional argument
return_collection=True
toprocess_mth5
. This will skip return the legacyTransferFunctionCollection
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.
The text was updated successfully, but these errors were encountered: