Processing ideas

[ariellellouch]

Hi, I have 2 straightforward suggestions and one more complicated:

1. Tau-p transform (both linear and hyperbolic)
2. Linear/hyperbolic moveout correction for a given velocity parameter

Both of these made me think :
3) Do we actually hold an (x,y,z) coordinate for each channel? Because if so, a function to sort channels by offset (2-D or 3-D) relative to a given source location would be super useful

[d-chambers]

Hey @ariellellouch, its nice to hear from you.

I think both 1 and 2 are great ideas. Do you already have python codes for it? I think they could both be sub-modules of dascore.transform.

Do we actually hold an (x,y,z) coordinate for each channel?

We can keep almost anything we want in the coords/attrs. For example, coords_from_df uses linear extrapolation for mapping something like fiber distance to spatial coords (eg from a tap test) by adding new coordinates (eg x,y,z). We might need a new function to sort by 2/3d distance to a point though. Maybe something like this?

def sort_distance_to(patch, origin, norm='L2'):
    """"
    Sort the contents of the patch based on distance to origin. 

    A new coordinate called `origin_distance` is added to the output patch to specify
    the exact distance, and the original location is added to the patch attrs 
    (e.g, patch.attrs.origin_x, patch.attrs.origin_y, ...)

    Parameters
    -----------------
    origin
        A series or dataframe which contains index names that overlap with patch coordinates. 
        All of the referenced coordinates must be associated with the same dimension. 
    norm
        The norm for calculating distance. 

    Examples
    --------------
    import pandas as pd
    
    shot = pd.Series({"x": 10, "y": 10, "z": 0})
    patch = ... # Get patch with xyz values, we might have one in dascore.examples or maybe need to make one
    sorted_patch = patch .sort_distance_to(shot) 
    """"
    ...

Potentially, origin could represent more complex geometries, like a line or point cloud, but initially only supporting a single point seems very reasonable.

[ariellellouch]

@d-chambers Thanks!

I have a reasonable basis for 1 and 2, but for speed they utilize numba. Is that reasonable? I can get to work on it
The sorting function seems great, and I think will often be called to "linearize" the arrivals before using all sorts of linear transforms.

[d-chambers]

I have been thinking about how to incorporate numba. My thought is to make a jit decorator which will either warn or raise if numba isn't installed. That way DASCore can have numba as an optional dependency. I will try to implement that today or tomorrow and once it is done you should have all you need to work on (1) and (2). We can then add (3) after that. Sound good?

[d-chambers]

Actually, looking closer at this, we don't need an extra decorator. It can be done now like this:

from functools import cache

from dascore.utils.misc import optional_import

@cache
def make_jit_func():
    """Create a jit'ed function for some fancy processing"""
    numba = optional_import("numba")

    @numba.jit(nopython=True)
    def jit_func(array):
        for a in numba.prange(len(array)):
            pass
        return array

    return jit_func

Then in the patch function:

def taup(patch, ):
    numba_func = make_jit_func()
    data_out = numba_func(data)
    ...

The optional_import function will raise an error if the needed package is not installed and the cache makes it nearly free to call make_jit_func after the first call. What do you think?

[ariellellouch]

I should be able to make it work like that!
Not sure when I'll get to it, but I'll send a PR for both 1) and 2)

[ariellellouch]

@d-chambers I made a pull request but it's failing because numba isn't installed by default, so I can't make it run
I ended up splitting tau-p and linear correction, but linear correction will be a piece of cake once we sort this one