Generic Labels for channels names supported

[kkappler]

In general it would be very nice to allow for generic channel labels.

"hx", "hy", "ex", "ey" are good channel labels, but it would be nice if we had a place where these default channel labels were stored, and a user could change these.

This relates to mth5 Issue38 https://github.com/kujaku11/mth5/issues/38 and mth5 Issue54
but more than just "h1", "h2", "h3", "e1", "e2", we should be able to support
"label1", "label2", "labelN"
This implies an underlying channel naming schema, that defaults to "hx", "hy", "hz", "ex", "ey" but could support "foo", "bar", "moonunit", "dweezil", etc.

If we want to do Egbert's MMT method, or other methods we can for example concatenate channel label and station name.

Note:

• The regression is already agnostic to channel names, being cast in terms of input channels X and output channels Y.
• Most of the time series operations simply loop over channel names so these shouldn't be a major issue
• The assigning of TF values will need either a mapping to "effective hexy labels" or the tf will need to be created with generic structure. This won't be too hard, the main issue is actually when we call apparent resistivity calculation, and a layer to map the channel names can be put in before we call apparent_resistivity()

This is particularly important if we want to work in a transformed domain. For example PCA, ICA representations of the data will not correspond to the hexy convention.

[kkappler]

In general we should have a place where the channel_name _convention is configured.
There should also be a config for "measurement_type", such as Electric is E, Magnetic is H, but also can do FDSN, ie.. magnetic is F, and electric is Q.

A good test would be to process the data with channels named john, paul, george and ringo

[kkappler]

After stewing on this for a while, although I really like the idea of generic channel names, it is not clear that is appropriate for standard MT processing. The TFs are generally relationships between two electric fields that span the plane of the local earth, and three magnetic fields. The nomenclature of "ex", "ey", "hx", "hy", "hz" supports this in general. Generic channel names could be supported up to TF estimation step, and then could be mapped onto these common labels during TF estimation. That would be fine for the SS and RR cases.

For multiple station, we would need to address some variant of this issue, even if it were to replace the channel name with the concatenation of survey-station-component

[kkappler]

This issue has reared it's head now that we are working on LEMI data, because LEMI standard names its channels:

'bx', 'by', 'bz', 'e1', 'e2', 'e3', 'e4'.

[kkappler]

Presumably, we could process
{'bx', 'by', 'bz', 'e1', 'e2'}
and
{'bx', 'by', 'bz', 'e3', 'e4'}
separately,
(or maybe for some reason {'bx', 'by', 'bz', 'e1', 'e3'} or something) but always the magnetic channels and a dipole pair. This seems like the easiest way to move forward.

If we tried to accomodate TFs that were w.r.t. magnetics and an arbitrary collection of dipoles, this would be really great because we could use this for NFIP surveys, but this is an MT project, and probably should stay with the current scheme.

So, that means that processing LEMI can be approached with a channel-map
{"bx":"hx"
"by":"hy"
"bz":"hz"
"e1":"ex"
"e2":"ey"
}
for example.

But where to put the channel map? There is a fork in the road here.

[kkappler]

It probably would live in the processing config.

[kkappler]

I have successfully remapped channels names on synthetic data using a dictionary and produced TFs from LEMI-like labelling on synthetic data.

Some wrangling was needed to make the TF class in mt_metadata write out and to avoid tests/synthetic/test_synthetic_driver.py yielding:

2022-07-31 13:09:17,383 [line 370] mt_metadata.transfer_functions.core.TF._validate_input_dataarray - ERROR: Output dimensions must be ['ex', 'ey', 'hz'] not ['bz', 'e1', 'e2', 'hz']
Traceback (most recent call last):
File "test_synthetic_driver.py", line 197, in
main()
File "test_synthetic_driver.py", line 193, in main
test_process_mth5()
File "test_synthetic_driver.py", line 168, in test_process_mth5
z_file_path=z_file_path, file_version="0.1.0", return_collection=False
File "test_synthetic_driver.py", line 96, in process_synthetic_1
return_collection=return_collection,
File "/home/kkappler/software/irismt/aurora/aurora/test_utils/synthetic/processing_helpers.py", line 46, in process_sythetic_data
return_collection=return_collection,
File "/home/kkappler/software/irismt/aurora/aurora/pipelines/process_mth5.py", line 476, in process_mth5
survey_dict=survey_dict,
File "/home/kkappler/software/irismt/aurora/aurora/pipelines/process_mth5.py", line 226, in export_tf
tf_cls.transfer_function = tmp
File "/home/kkappler/software/irismt/mt_metadata/mt_metadata/transfer_functions/core.py", line 491, in transfer_function
self._set_data_array(value, "tf")
File "/home/kkappler/software/irismt/mt_metadata/mt_metadata/transfer_functions/core.py", line 430, in _set_data_array
nda = self._validate_input_dataarray(value, atype=atype)
File "/home/kkappler/software/irismt/mt_metadata/mt_metadata/transfer_functions/core.py", line 371, in _validate_input_dataarray
raise TFError(msg % (ch_out, da.coords["output"].data.tolist()))
mt_metadata.transfer_functions.core.TFError: Output dimensions must be ['ex', 'ey', 'hz'] not ['bz', 'e1', 'e2', 'hz']

Will open a ticket on mt_metadata for this.

[kkappler]

ToDo:

• modify function export_tf in process_mth5 to take a channel_nomenclature kwarg (default="default");
  Specifically, pass the kwarg into
  merged_tf_dict = tf_collection.get_merged_dict()

• Add a channel_nomenclature string to Processing config class

• modify call to export_tf() in process_mth5 to pass channel_nomenclature form the config

• modify synthetic_processing_configs to support channel_nomenclature, so that it can do synthetic processing in LEMI or NIMS nomenclature via a kwarg

• modify TTFZ.apparent_resistivity() to take channel_nomenclature kwarg in the module and where it is called in the pipeline

[kkappler]

Tests passing, only needed left is

• to process RR using LEMI12 notation

[kkappler]

Test is still failing on the beatles however.

[kkappler]

We are supporting most common combinations at this point such as b or h for magnetic channel indicators, symbols x,y,z for direction as well as 1,2,3 for direction of magnetic and 1,2,3,4 for direction of electrics to conform with LEMI. If we wanted 100% generic labelling more changes would need to be made because mt_metadata assumes these sorts of structures. The Beatles test will be removed as it is too general, and kind of silly