Using our own timedelta class to support float*timedelta64 multiplication in Kernels?

[erikvansebille]

I want to get your quick thoughts on a stumbling block I've hit with the particledata-xarray implementation (implementing #1822).

I've made particle.dt a numpy.timedelta64 object, but this means that we can't do something like

lon += u * particle.dt

in a Kernel (or anywhere else) because multiplying u (a float) with particle.dt (a timedelta64) results in a TypeError...

Three possible solutions I see

1. Don't use np.timedelta64 for dt, but instead keep them as float. This however means that we'll probably lose all the advantages of particle.time being a np.datetime64 too; because particle.time + particle.dt won't work anymore
2. (on-thy-fly) convert any mention of particle.dt in a Kernel to a float; but that means a codeconverter (again...), which we wanted to get rid of in v4
3. Create our own parcels.timedelta64 class that inherits(?) from np.timedelta64 but also adds multiplications with a float (and then returns a float). Something like

class timedelta64:
    def __init__(self, value):
        self.value = np.timedelta64(value)

    def __mul__(self, other):
        # Returns float seconds
        return (self.value / np.timedelta64(1, "s")) * other

    def __rmul__(self, other):
        return self.__mul__(other)

What do you think, @VeckoTheGecko? Do you have a preference? Or do you see another solution?

[erikvansebille]

@VeckoTheGecko and I just had a f2f discussion, and we decided to (at least temporarily) implement a fourth option:

4. Keep datetime64/timedelta64 in the pset.execute and kernel loop, but use floats for time and dt inside the kernel. That would ensure backward compatibility of v3-kernels, at the cost of users not being able to use datetime64 objects in their kernels

[erikvansebille]

Another complication is that we may want to use particle.time in its original datetime64/timedelta64 format in the Interpolators (see #2081), so that option 4 above (cusing float iniside the Kernels) may not be a good choice after all.

For the moment, I've simply converted dt to a float inside the Advection Kernels in be87206, using

dt = particle.dt / np.timedelta64(1, "s")

This pragmatic solution allows us to continue developing the particles data class (#2079) and Interpolators (#2081) while we chew on the Issue discussed here