Reading origin time from SAC header vs Origin object

[ammcpherson]

I recently ran into an issue where, whilst attempting to use a Green's Function database generated in SPECFEM3D_GLOBE, the following error was thrown:

Reading Greens functions...

/home/ammcpherson/REPOSITORIES/mtuq/mtuq/greens_tensor/SPECFEM3D.py:26: UserWarning: SPECFEM3D modules have not yet been tested.
  warnings.warn("SPECFEM3D modules have not yet been tested.")
Processing Greens functions...

Traceback (most recent call last):
  File "3D_run_mtuq.py", line 237, in <module>
    greens_bw = greens.map(process_bw)
  File "/home/ammcpherson/REPOSITORIES/mtuq/mtuq/greens_tensor/base.py", line 363, in map
    [function(tensor, *args)]
  File "/home/ammcpherson/REPOSITORIES/mtuq/mtuq/process_data.py", line 599, in __call__
    cut(trace, starttime, endtime)
  File "/home/ammcpherson/REPOSITORIES/mtuq/mtuq/util/signal.py", line 22, in cut
    raise Exception('The chosen window ends after the trace.  Consider '
Exception: The chosen window ends after the trace.  Consider using an earlier window, or to automatically pad the end of the trace with zeros, use mtuq.util.signal.resample instead

I would receive this error regardless of if I was using taup or FK metadata to calculate P and S wave arrivals. After doing a little digging, I found that the windows for the data and the windows for the Green's Functions had extremely different values for the same station:

Data Type	Start Time	End Time
Data Window	1595398379.3	1595398394.3
Green's Function Window	1658470379.91	1658470394.91

As it turns out, I had mistyped the time in my Origin object as '2022-11-30' instead of '2020-11-30'. However, this does raise the question of why does MTUQ use the origin time in SAC headers for the data to create a window for a trace, but uses the origin time in the Origin object to create a window for the synthetics/Green's Functions for SPECFEM3D databases?

[rmodrak]

The data processing performed for moment tensor inversions is complicated and there may be opportunities to improve it. Currently

• you can explicitly pass station and origin arguments to process_data to directly specify/overload the origin time and location
• if these arguments are not passed, process_data attempts to fall back to attributes contained in the object (GreensTensor or Stream) being processed itself

These attributes in turn are determined by

• GreensTensor attributes are derived from the input arguments passed to the get_greens_functions query
• Stream attributes are derived from seismic files using a data reader (currently just a SAC reader), which handles all the metadata parsing in a file-format-specific way