Deformation rate to strain rate conversion

[ianis-g]

Hi

Is there a way to convert deformation-rate data to strain-rate data using XDAS existing tools ?

The use of xdas.signal.differentiate XDAS function along the spatial dimension is unfortunatly not possible since the conversion requires a smooth spatial derivative schemes over a gauge length, as far as I understood from Eq.5 of the nice paper of Trabattoni et al., 2023 https://doi.org/10.1093/gji/ggad365

Thanks :)

[atrabattoni]

Hi @ianis-g

There is this documentation page about strain-rate to any quantity conversion. But if I understand well you want to do the opposite. In that case xdas.signal.differentiate is the correct way to go. Converting in that direction is less problematic and does not require spatial filtering (as when going from velocity to acceleration).

Do you encounter some problems while doing so ? You can further explain your use case if you want further help.

[ianis-g]

Thanks @atrabattoni for your answer

Well, I am working from native 'deformation-rate' data recorded using Treble+, and I would like to convert them to 'strain-rate' using a specific gauge length value, which is most often different to the spatial sampling, and therefore xdas.signal.differentiate is not adapted I guess.
Using standard Numpy array, the operation consists in doing (data[:, gauge_samples:] - data[:, :-gauge_samples]) / (gauge_samples * dx), with data are DAS data in deformation-rate with dx spatial sampling, and gauge_samples number of samples in a gauge length.

Thus I am wondering whether it is possible to do that whithin the XDAS framework.

Thanks !

[atrabattoni]

Oh I see,

You could almost do what you describe with Numpy with Xdas BUT if you try it you will have some trouble with the space coordinates as da[:, gauge_samples:] and data[:, :-gauge_samples] will not have the same space coordinate anymore. For now Xdas raises an Error when you try to do arithmetic with data arrays with different coordinates because it is not clear how to handle coordinates in that case.

Bellow a function that does what you want for any dimension you want :

import xdas

def differentiate(da, span=1, method="forward", dim="last"):
    d = xdas.get_sampling_interval(da, dim)
    before = da.isel({dim:slice(None, -span)})
    after = da.isel({dim:slice(span, None)})
    data = (after.values - before.values) / (span * d)
    match method:
        case "forward":
            out = before.copy(data=data)
        case "backward":
            out = after.copy(data=data)
        case "central":
            out = before.copy(data=data)
            out[dim] = before[dim] + (span * d / 2)
        case _:
            raise ValueError(f"unknown method '{method}'")
    return out

Notes:

• da.copy(data=...) is used to reuse preexisting coordinates and just changing the data.
• da.isel({dim:slice(...)}) is equivalent to da.isel(dim=slice(...)) but you can programmatically choose the name of dim. Here the use of isel insteat of da[:, ...] allows to work wherever the dim is and whatever dim you want.

Tell me if it works as expected, I will add this to Xdas whenever I have some time.

[atrabattoni]

@ianis-g did this helped?

[ianis-g]

Yes it works !

I apologize for my very late feedback. I have been really busy those last weeks.

I just tried today and it works smoothly. Thank you very much :)

I think it could be really nice to have the reverse, i.e. an xdas.integrate function allowing for integration step greater than spatial sampling DX to take into account gauge length effect when converting from strain to deformation, as you explain in the documentation .

Would it make sense ?

[atrabattoni]

Do you mean having a function that does both integration and sliding mean removal ? We could but it just turns two line of codes into one. I'll think about it. Or do you mean something else ? Cause for me integration is more acurate if you do it on smaller steps. Y can always decimate after.

[ianis-g]

I agree spatial integration is more accurate on the smallest step (i.e spatial sampling DX in most case), but if the gauge length (GL) is greater than DX , that seems strange to consider DX as the step for integration (and not GL) when converting from strain to deformation

I do not think that would be equivalent to integration + sliding mean removal over a GL samples window, but I am 100% sure...

I understand deformation is a gauge length free measurand, but when converting from strain to deformation, my feeling is that deformation result depends on the gauge length used to create the strain (from native deformation measured by the DAS unit)

Does it make sense ?

[atrabattoni]

Oh BTW a more modern approach could be to do xdas.signal.differentiate followed by xdas.signal.decimate. Because this N span differentiation is just a very poor decimation scheme in the end. If you want to 'reduce' the number of points you could use a antialiasing lowpass FIR filter.

Actually the N span differentiation can be seen as the convolution of a diff kernel [1, -1] (or the opposite and you must normalize) and a smoothing kernel [1, ..., 1] (with len the span of interrest and you must normalize again, i.e. rolling mean). This latter is the worst decimation kernel ever. You can replace it with a hann window or something better.

[ianis-g]

Interesting !
But I prefer to use the function you proposed in previous post, more readable to me :)