search

NanoComp / meep

free finite-difference time-domain (FDTD) software for electromagnetic simulations
GNU General Public License v2.0
1.22k stars 622 forks source link

FFT acceleration of near2far #2269

Open smartalecH opened 2 years ago

smartalecH commented 2 years ago

Currently, the Near2Far features use the full Green's function to project an equivalent source into a user-specified point in the far field. This approach is very flexible, but in some cases overkill. For example, we often wish to view the far-field response "infinitely far away", where the Green's function convolution integral simplifies to a simple Fourier transform.

It would be nice to add a feature that does precisely this. It's significantly cheaper than the "brute-force" approach. (of course, one could do this "by hand" using the python API... but a dedicated routine would be much appreciated).

stevengj commented 2 years ago

It seems to be that the big gains are for implementing FFT-acceleration for equally spaced points in the far field. That gives us a factor of n/log(n) speedup. Furthermore, it can use the same API, and should give exactly the same results to nearly machine precision, which should make it easier to debug.

Your additional far-field trick gives you at most a factor of 2, and requires a new API and more debugging, so it seems like a lower priority.

stevengj commented 2 years ago

@mawc2019, didn't you or Zin implement FFT-based near-to-far field in Python at some point?

mawc2019 commented 2 years ago

Both Zin and I once wrote the code for FFT-based near-to-far-field transformation in user files, but I did not try to incorporate it into Meep. I think Zin probably did not do this, either.

In my code, the spacing between adjacent far-field points is the same as the spacing between adjacent near-field points. If the spacing of user-specified far-points are different from the spacing of near-field points, interpolations in far fields may be needed. In particular, if a user specifies only a few far-field points, with their spacing much larger than the spacing of near-field points, a lot of redundant far-field data would be generated and stored (during some intermediate steps). Would FFT-based near-to-far-field transformation in such cases still be beneficial?