I have started writing some SpecArray class which inherits from DataArray and defines some methods useful for dealing with wave spectra, such as calculating spectral wave statistics like significant wave height, peak wave period, etc, interpolating, splitting, and performing some other tasks. I'd like to ask please if:
The text was updated successfully, but these errors were encountered:
I do lots of multidimensional spectral analysis on geophysical data (mostly
One huge source of confusion for students starting out with such
My view is that spectral analysis is out of scope for xray. However, I
I think such a package would really take off in popularity and would help
On Tue, Jan 5, 2016 at 2:55 AM, Rafael Guedes firstname.lastname@example.org
Back when I was doing spectroscopy in grad school, I wrote some routines to keep track of the units in Fourier transforms. I put this up on GitHub last year: https://github.com/shoyer/fourier-transform. I'm sure I'm not the only person to have written this code, but it still might be a useful point of departure.
As for xray, I agree that the full extent of what you're describing is probably out of scope for xarray itself. However, a basic labeled FFT does seem like it would be a useful addition to the core library.
Nevertheless, I am very interested in supporting external packages like this, either via subclassing or a similar mechanism.
One possibility would be a mechanism for registering "namespace" packages that define additional methods (as I have mentioned previously). You could write something like:
# this code exists in your library "specarray" class SpecArray(object): def __init__(self, xray_obj): self.obj = xray_obj def fft(self): ... return freq, transformed_obj xray.register_accessor('spec', SpecArray) # this is what user code looks like import specarray import xray ds = xray.DataArray(...) ds.spec.fft() # calls the SpecArray.fft method
This might be easier than maintaining a full subclass, which tends to require a lot of work and presents backwards compatibility issues when we update internal methods.
I find @shoyer 's suggestion about custom accessor attributes very interesting!
the simplest of my use cases would be quite easy to implement:
# MyLib class MyLibGis(object): def __init__(self, xray_obj): self.obj = xray_obj self.georef = read_georef(xray_obj) def subset(self, shapefile=None, roi=None): """Return a subset of DataSet (or DataArray)""" # compute regions of interests slicex, slicey = self.georef(stuff...) # return a sel of DataSet return self.obj.sel(x=slicex, y=slicey) xray.register_accessor('gis', MyLibGis) # user code import mylib import xray ds = xray.DataArray(...) ds = ds.gis.subset(shapefile='/path/to/shape')
This would already be quite cool! But would the mechanism allow to pass arguments to the
I guess that with these two mechanisms, I would be able to do almost everything I want to do with my netcdf files.
However, one other very important use case for me would be to add lazy "diagnostic" variables to a netcdf dataset. For example, if an atmospheric model output file contains the variables
My suggested approach here would be to simply write functions instead, e.g.,
This is similar to how I would suggest inserting lazy variables, i.e., write your own functions using
@shoyer : the approach you propose for registering additional methods for datasets or dataarray would certainly open very nice applications for xarray. This is for instance something that would very useful to the library we have discussed here (see e.g. this issue about oocgcm). Is there a way how I could contribute to having this register functionality available in xarray ?
@rabernat : your idea of a spectral analysis package on the top of xarray is interesting. I am happy to contribute to this (probably in the frame of the library mentionned above ?). As many others I guess, I have my own script for this (here), but having a more robust and shared code is certainly a good way to go.