use mt_metadata for reading z-files

[kkappler]

To avoid maintenance of multiple z-file readers the mt_metadata TF class will be used exclusively.

This means we need to replace calls to from aurora.sandbox.io_helpers.zfile_murphy import read_z_file

• aurora/transfer_function/emtf_z_file_helpers.py:16:from aurora.sandbox.io_helpers.zfile_murphy import ZFile
• aurora/transfer_function/emtf_z_file_helpers.py:66: aux_data: aurora.sandbox.io_helpers.zfile_murphy.ZFile
• tests/synthetic/test_compare_aurora_vs_archived_emtf_pytest.py:40:from aurora.sandbox.io_helpers.zfile_murphy import read_z_file

Fixing the test is a bit tricky. The test has some adhoc methods to compare the stored EMTF results against the aurora outputs. These have been recorded.

Steps:

• 1. Verify MTH5 Metadata:
  Ensure that the MTH5 file contains the correct azimuth and tilt values for Hx and Hy channels in its metadata. Incorrect or identical azimuths (e.g., both 0.0) will cause the impedance tensor rotation to fail.

• 2. Validate Z-File Azimuths:
  Confirm that the generated z-file (e.g., test1_aurora_fortran.zss) correctly reflects the intended azimuths and tilts for each channel. The z-file should inherit these values from the MTH5 metadata.

• 3. Integrate RMS Misfit Checks:
  Once the azimuths are correct and the impedance tensor can be rotated, update your comparison test logic (using CompareTF) to assert that the computed RMS misfits match the expected values from get_expected_rms_misfit. This ensures your test validates both numerical closeness and physical correctness.

@kujaku11

[kujaku11]

@kkappler I found the issue and fixed the missing survey metadata propagating through to the zss files in mth5. The issue was that the logic was testing if the start time of the run and the start time of the first channel were the same, and they were because of the synthetic data starting on the epoch 1980-01-01T00:00:00, which is also the default value for time. So this edge case skipped the logic to pull the channel metadata when building the run metadata. I added logic to test the end time as well, which should be different from the default value. This fixed the issue and now the channel metadata is rediscovered in the run metadata and propagates through such that the zss file now has the azimuth values.