Potential future performance issue with multiple Meshes and FFTW

[johnomotani]

At some point we intend to support simulations with multiple Mesh objects. We might then have different grids with different nz. At the moment rfft, irfft, DST and DST_rev are functions which use static variables to initialise buffers and FFTW plans https://github.com/boutproject/BOUT-dev/blob/17706e1344964b7f756cafaf6a4378740bd40429/src/invert/fft_fftw.cxx#L84-L88 If variables with different n are passed, this will be very inefficient as the FFTW plan will be re-created each time n changes, which is expensive.

At some point we should probably make these methods of some sort of class that can cache plans for different n.

[bshanahan]

Might I also suggest this would be a good time to implement nonuniform FFTs? If we implement support for different nz, then we might as well let that nz vary. This would be an immediate improvement for curvilinear FCI grids.

[dschwoerer]

@bshanahan Do you want to support different nz - or do you want non-uniform dz support?

[ZedThree]

Ouch, yes, good spot @johnomotani !

@bshanahan Non-uniform FFTs would definitely be nice, but we'd need to use a different library, as FFTW doesn't support them (at least, not to my knowledge)

[johnomotani]

Another possibly nice-to-have thing: if we allocated all our arrays with fftw_malloc() (using some change under the hood in Array), it's possible to use an FFTW plan with arbitrary input and output buffers. We might be able to get rid of a few copy operations with this.