offer DFT decimation option

[stevengj]

To improve performance, it would be nice to offer the option to to "decimate" the DFT sum: accumulate the DFT coefficients on every n-th timestep instead of on every timestep. (Note: we should also increase the dt_factor by n on this line.)

We can default to n=1 (the current behavior) for now, and then run some tests to see what the impact of different n values is. Possibly in the future we may be able to default to a larger n (it should depend in the highest DFT frequency and on the source bandwidths, in principle), but in the meantime users can just try doubling this and see if it affects the results significantly

[stevengj]

In particular, if all of the sources have known narrow bandwidths (e.g. all are Gaussian sources), then we can calculate the largest Δt that will not alias a source frequency into the DFT bandwidth.

[stevengj]

In principle, we could make this a parameter of each DFT object, but it might be easer to use if it is per-Simulation?

[stevengj]

In particular, if the Meep timestep is Δt, and we DFT using NΔt (every N-th) step, then frequencies f that differ by 1/NΔt will be aliased.

Suppose that the source bandwidth is within (f1,f2). For real simulations, we take the real part of the source and this means that the bandwidth also covers (-f2,-f1) along the negative-frequency axis. Suppose that the DFT bandwidth is for frequencies within (F1,F2).

We want to make sure that no source frequency is aliased to a DFT frequency. If I understand this correctly, this means we want F2-(-f2) < 1/NΔt, and hence N < 1/Δt(f2 + F2).

[stevengj]

It would be nice to try this "by hand" for a sample calculation with a Gaussian source, and check that making N too large indeed causes aliasing artifacts, with the threshold being about what is predicted above.