Implementation of FFT geophysical filters in Harmonica

Hi everyone!

I’m Santiago Soler, one of the core developers of the Fatiando a Terra project: open-source tools for geophysics. We have been quite interested in the development of xrft, specially for managing FFT-based processes and filters that we are planning to include in Harmonica, a library for processing, forward and inverse modelling gravity and magnetic data.

We are very interested in using xrft for managing the whole FFT and inverse FFT processes that these functions need. Our potential fields data (gravity and magnetic) is usually given as a 2D regular grids whose coordinates are projected geographical coordinates: easting and northing (Cartesian coordinates in meters). See this gallery example to get a better picture of them. In the old fatiando package we used to have some implementations of these methods using numpy.fft directly, although we are very interested in a FFT implementation that harness xarray objects, since we are using DataArrays and Datasets as our default structure for our 2D grids. We therefore find xrft the perfect solution to our problems. We really appreciate you developers for taking the time to build this great project!

I personally started drafting an implementation of a directional derivatives of a regular grid using FFTs (https://github.com/fatiando/harmonica/pull/238) using xrft under the hood for computing the FFTs and their inverse. On this process, I started getting some user experience of xrft and wanted to share them with you. We also found that we might have some special needs and we would like to know if you would want to include solutions to them into xrft. We are absolutely willing to help with the implementation and maintenance of those.

Differences between dft and fft

We found that xrft hosts two different functions for handling FFT computations: dft and fft. We found out that fft is a wrapper of dft that passes hard-coded values to certain parameters. IMHO, it sounds slightly confusing at the beginning, and in fact I had to surf through the code to finally understand the difference between them.

Is there any strong decision for this design?

Mathematical docstring of dft

The docstring of dft states that it returns the Fourier transform computed as

daft = \mathbb{F}(da - \overline{da})

where I assume that the \overline states the mean value of the array. Am I right?

If so, the function only removes the mean value if we pass detrend="linear", right?

True Phase and True Amplitude

I’ve been struggling to understand what true_amplitude and true_phase actually mean. I think it would help to add some mathematical background on the intended behavior of enabling and disabling them.

Coordinates shift

Most of the FFT-related functions we will implement on Harmonica can be summarized in the following workflow:

• compute FFT of a 2D regular grid
• apply a filter in the frequency domain
• compute inverse FFT to obtain the modified grid on the same coordinates.

While implementing the derivatives (https://github.com/fatiando/harmonica/pull/238) I’ve noticed that xrft.xrft.ifft returns a DataArray whose coordinates are centered around zero. Although this might not be a big deal in the general case, for the Harmonica use cases it’s extremely important that the output grid has the same coordinates as the original one, since they mean actual geographical locations. I tried passing a tuple to the lag parameter with the western and southern coordinates of the original region, but ifft returns a warning saying that it ignores this parameter.

So far, we manage to implement this feature on our side: https://github.com/fatiando/harmonica/blob/4e865f00f0464e24d8f1cbb8b3c825ab70aa899d/harmonica/filters/fft.py#L34-L85

Nevertheless we don’t intent to maintain wrappers of the xrft functions in the future.

Would you like to see something like this implemented in xrft?

Plans for future padding functions

In the future we will be very interested in having functions to apply padding to our 2D grids before passing them to fft. We’ve been following the implementation of xarray.pad, although it currently fills with nans the extended coordinates which cause a lot of problems when trying to compute FFTs (see https://github.com/pydata/xarray/issues/3868). Since xarray is not intended to be used exclusively with regular grids, extending the coordinates of a DataArray is not trivial. But since xrft assumes regular grids, will you be interested in implementing specific padding functions in xrft?

---

Thanks again for all your work on this subject! We really appreciate it. And sorry for my long issue. If you think it might be better to split this Issue into several ones, please let me know and I’ll split it so we can chat about every topic in a more organized way.

Cheers!

cc @leouieda @aguspesce @andieie

[lanougue]

I think the fft and ifft functions should resemble the mathematical description of the Fourier transform and its inverse as much as possible.

Actually this question raised up some time ago. Should xrft.fft mimic the numpy.fft (because users are used to it) or should it be the closest as possible to the mathematical Fourier transform, as you suggest. At time, the chosen option was to make xrft.fft to mimic numpy.fft and to make xrft.dft the closest to the mathematical Fourier Transform (I agree that the dft name was not a very good choice but it was for historical reasons).

We now need to choose how xrft.fft should behave. I also raised this question in PR #155 too because it is of central interest

[lanougue]

I did not say “no” ! I only started a discussion 😃 I like the round-tripping argument 😃 @roxyboy, I can start this PR too if you need