reduce pvss computation via find_peaks

[S-Hanly]

I'll need to dig into the batch tests, I think it's because I added the resultant...

But basically, I'm using find_peaks to only process the shock response function on peak events. For the recording I was testing on, it takes over 2 minutes to calculate the spectrum on the whole range, but then 2 seconds by just using the peaks. For shorter recordings with repeating events it's not as drastic a savings but for one went from 7 seconds to 2 seconds. The question is... by doing this we may be missing some lower frequency content slightly.

Here's one axis comparing the full vs the peak calculation and they match exactly (there are two lines drawn over each other):

But for the less prominent axes we can see this deviation slightly. I'm not sure if this a big enough deal where we will allow the user to effectively turn off this performance feature via setting max_time to a very large number.

[S-Hanly]

@CrepeGoat @theflanman you may have a comment, no pressure though (hope all is well)!

[codecov-commenter]

Codecov Report

Merging #195 (5421164) into development (3be10ed) will increase coverage by 0.46%.
The diff coverage is 93.82%.

@@               Coverage Diff               @@
##           development     #195      +/-   ##
===============================================
+ Coverage        69.09%   69.56%   +0.46%     
===============================================
  Files               34       34              
  Lines             2964     3036      +72     
===============================================
+ Hits              2048     2112      +64     
- Misses             916      924       +8     

Impacted Files	Coverage Δ
endaq/batch/analyzer.py	91.83% <ø> (ø)
endaq/calc/stats.py	92.43% <ø> (-0.85%)	⬇️
endaq/plot/plots.py	63.56% <93.44%> (+7.90%)	⬆️
endaq/calc/shock.py	88.63% <95.00%> (-0.19%)	⬇️
endaq/calc/utils.py	85.00% <0.00%> (-1.67%)	⬇️

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[S-Hanly]

This would close the following issues:

• Create Shock Detection function for use with PVSS #169
• Segregate Large Time Series into Shock or Vibration Portions, then Run PVSS or PSD for Each #156
• Improved PVSS Processing Speed #155

[S-Hanly]

Next I will add a function to generate these 4 coordinate plots:

• Tripartite or 4 Coordinate Plot for Shock Response Spectrums #33

[S-Hanly]

@StokesMIDE in looking back at older commits, the bulk of this PR was passing on my second commit: https://github.com/MideTechnology/endaq-python/pull/195/checks?sha=d1968621e33c02ebf18046e7d024bdb2d3dc0724. So I went ahead and made a new branch off that commit to try and do a PR on (#197) but that's now failing... no code has changed since it passed.

So in this updated PR that is now passing, I just commented out the unit tests that were causing issues, they pass when I run it locally. I'm not sure how to proceed here? Do we merge this in and then create an issue to later figure out how to get these unrelated unit tests to pass again someday?

• endaq-python/tests/calc/test_integrate.py

  Line 67 in a878efd

  def test_integrals_iter_vs_list(df, **kwargs):

• endaq-python/tests/calc/test_integrate.py

  Line 31 in a878efd

  assert np.diff(calc_result.to_numpy(), axis=0) == pytest.approx(expt_result_diff)

• endaq-python/tests/calc/test_psd.py

  Line 65 in a878efd

  def test_to_jagged_modes(psd_df, freq_splits, agg1, agg2):

• endaq-python/tests/calc/test_shock.py

  Line 390 in a878efd

  def test_pseudo_velocity_zero_padding(

• endaq-python/tests/calc/test_stats.py

  Line 19 in a878efd

  def test_rolling_rms(df, window_len):

• endaq-python/tests/calc/test_utils.py

  Line 27 in a878efd

  def test_logfreqs(input_vars):

[StokesMIDE]

The tripartate plot is out of my wheelhouse, so I can't critique too deeply, but the code looks sound.