Low-freq proc

[ahmadtourei]

Description

This PR adds a recipe for the low-frequency processing routine. It also adds a delta patch (with unit value at the center of time or distance dimensions and zeros elsewhere) as an example patch.

This PR, in conjunction with #341, deprecates DASDAE's low-freq-real-time package.

Checklist

I have (if applicable):

• referenced the GitHub issue this PR closes.
• documented the new feature with docstrings or appropriate doc page.
• included a test. See testing guidelines.
• your name has been added to the contributors page (docs/contributors.md).
• added the "ready_for_review" tag once the PR is ready to be reviewed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.85%. Comparing base (d8e1ff5) to head (925ed0e).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #470   +/-   ##
=======================================
  Coverage   99.85%   99.85%           
=======================================
  Files         118      118           
  Lines        9670     9700   +30     
=======================================
+ Hits         9656     9686   +30     
  Misses         14       14           

Flag	Coverage Δ
unittests	99.85% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[d-chambers]

Hey @ahmadtourei, it's looking good so far. I just have two main suggestions.

1. It would be nice if the delta patch wasn't restricted to time/distance if you pass in a template patch. I provided the code that (probably) fixes that.

2. Do you think we could make the recipe executable? That way, we will have much more assurance the code continues to work as DASCore evolves (or the docs wont build). Moreover, we aren't using any dependencies we don't want to include like we did in the other non-executable recipes (eg the MPI one) so I don't see why not as long as the example spool is small, but maybe you have a reason I didn't think of?

[d-chambers]

Can you just use patch.resample here?

[ahmadtourei]

Apparently, they do not provide the same results:

import numpy as np
import dascore as dc

pa = dc.get_example_patch()
dt = 5 

resampled_pa = pa.resample(time=np.timedelta64(dt, 's')) # has one time sample at zero

new_time_ax = np.arange(pa.attrs["time_min"], pa.attrs["time_max"], np.timedelta64(dt, "s"))
interpolated_pa = pa.interpolate(time=new_time_ax) # has two time samples at 0 second and 5 seconds, as it should because the patch has 8 seconds

[d-chambers]

Ah, that is odd. I think #10 might be related.

[ahmadtourei]

I haven't worked with patch.resample() much; do you think this behavior is expected?

[d-chambers]

In both cases they are just calling underlying scipy functions so I don't think there is much we can do about it anyway.

[d-chambers]

Feel free to merge when you are happy with it. Do make sure the docs build before you do though.

[ahmadtourei]

Feel free to merge when you are happy with it. Do make sure the docs build before you do though.

Thanks for your input and review! Let's merge the get_name branch first and then I'll merge this.

[ahmadtourei]

The api/dascore/proc/filter/slope_filter.qmd doc fails with this error:

AttributeError: module 'dascore.io.segy.core' has no attribute 'SegyV2'

I've merged master branch (after having the optional_segyio branch merged into the master's). Any thoughts on how this can be fixed? @d-chambers

[d-chambers]

Any thoughts on how this can be fixed?

Yes, this is a quirk of python's entry points. Any time you change them (eg with the IO functions) you have to re-install dascore. Try re-installing.

Merging get_name into this branch is probably not prudent. When we merge get_name into master it will squash all the commits, then when we merge master back into this branch there will probably be a few merge conflicts. You can either undo that commit with git revert or just wait and deal with the merge conflicts.

[ahmadtourei]

@d-chambers The only thing left here is resolving #474. It will be ready to merge after addressing that issue.