Skip to content
Snippets Groups Projects
  1. Oct 22, 2024
  2. Sep 27, 2024
  3. Sep 26, 2024
  4. Sep 24, 2024
  5. Sep 23, 2024
    • Wilbur, Spencer Franklin's avatar
    • Erin (Josh) Rigler's avatar
      Merge branch 'fix-FilterAlgorithm-get_nearest_time' into 'master' · 84a6f967
      Erin (Josh) Rigler authored
      Function get_nearest_time() behaves as expected now
      
      See merge request !338
      84a6f967
    • Erin (Josh) Rigler's avatar
      Fix unit test for FilterAlgorithm.get_nearest_time() · 426ad8d4
      Erin (Josh) Rigler authored
      The previous unit test relied on broken behavior of get_nearest_time()
      to pass. With get_nearest_time() fixed, the unit test needed to be
      updated accordingly.
      426ad8d4
    • Erin (Josh) Rigler's avatar
      Function get_nearest_time() behaves as expected now · ffdb80da
      Erin (Josh) Rigler authored
      A FilterAlgorith.py module function get_nearest_time() is supposed to return
      the nearest *allowed* time for a given filter "step". This worked fine with
      steps for second and minute data, whose allowed times are the tops of seconds
      and minutes. However, for hourly (and daily, and any "average" type step),
      things failed since the allowed times are the center of the interval (for
      example, for hourly data, which is the average of all minute samples from
      00 to 59, the the allowed time is 29:30).
      
      One consequence was that if a user specified an interval with a start and
      end time that did not encompass a given hour's allowed center time (e.g.,
      start=AA:29:31, end=BB:29:29), the algorithm would still return a sample
      for time BB:29:30. More generally, requests for average type data would
      include an extra sample.
      
      In this fixed version, if start=AA:29:31, and end=BB:29:29, nothing is
      returned, as intended (and as always worked for non-average type steps).
      Furthermoref start=AA:29:30, and end=BB:29:29, a sample for hour AA is
      generated; if start=AA:29:31, and end=BB:29:30, a sample for hour BB is
      generated, and if start=AA:29:30, and end=BB:29:30, samples for both AA
      and BB are generated, all as intended.
      ffdb80da
  6. Sep 20, 2024
  7. Sep 19, 2024
  8. Sep 18, 2024
    • Erin (Josh) Rigler's avatar
      Remove sensitivity/response; fixes issue #117. · 0792d5a0
      Erin (Josh) Rigler authored
      Remove instrument_sensitivity if it exist. If it doesn't exist, then
      an instrument_polynomial must describe the response, which is how the
      Geomagnetism Program specifies an offset and gain response. We do not
      attempt to remove any frequency-depenent response since these all seem
      tailored to seismic data (e.g., no DC/zero-frequency response).
      0792d5a0
  9. Sep 16, 2024
  10. Sep 13, 2024
  11. Sep 12, 2024
    • Erin (Josh) Rigler's avatar
      Fix FilterAlgorithm.align_trace() method and unit tests · 0e3949f2
      Erin (Josh) Rigler authored
      The method FilterAlgorithm.align_trace() pre-processes the `trace.data` input
      array for subsequent processing by FilterAlgorithm.firfilter() such that the
      first input array element corresponds to a time step on which output samples
      must fall (as defined in the dictionary `step`) minus half the fir window
      width. In short, it ensures that output samples fall on desired time steps.
      
      Prior to this fix, it only worked as intended when input trace's starttime fell
      on an even time step. A bug became obvious when attempting to filter data from
      non-Geomag stations that did not have nice time stamps. This fix addresses that
      issue, and also ensures that `align_trace()` does what was claimed in its own
      original docstrings, which is to handle trailing misalignments as well.
      
      Note: one thing `align_trace()` does NOT do is ensure that all needed input
      data are available to generate desired outputs. The user is responsible for
      providing this, but can use the FilterAlgorithm.get_input_interal() method
      to calculate the actual required input starttime and endtime. The method
      `align_trace()` will trim or pad with NaNs only enough to align time stamps,
      and may actually result in `firfilter()` output that are NaNs if the input
      trace was not adequate.
      0e3949f2
  12. Sep 11, 2024
Loading