Page 2 of 2

Re: Proposal for the implementaion of Fraunhofer far field

Posted: Mon 27 Feb 2017, 22:49
by gmichel
Hi Thorsten,

I have had a look at the reference you gave. The equation numbers in the comments do not agree with that reference. But all the rest including variable names does. So I guess it was that reference. In the end I think the methods there are a variant of the Fraunhofer approximation. The Fraunhofer approximation is a generic method for the Helmholtz equation, i.e. it could also be used for acoustical waves, and in the reference it is tuned towards vector potentials.

Eqations 8.26a/b below represent the main computing effort. They are helper quantities for the vector potentials A and F. These equations can be rearranged such that the integration kernel becomes a (2D spatial) Fourier Transform. This in turn can be done with a 2D FFT.

The only difference to my code is the fact that I calculated E_phi and E_theta solely from the E-Field, using the fact that the cartesian components of E individually fulfill the Helmholtz equation in free space. Taflove combines E and H on the nf2ff box to the vector potentials. They are used in turn to obtain E_phi/theta.

When the nf2ff box fully encloses the reactive near field zone (as it should), then both methods should give the same result. This is more or less the case in the above example. Although with the E-only method we save computing time because we need only three integrals (i.e. FFT's) for the three components of E. With the vector potential method we need four (two components of J_s and two of M_s).

So I think it would be worth to give it a try. Another benefit is that we do not need to store H dumps in order to calculate the far field. Maybe an implementation of the R-S integral would be also useful for the not-so-far-field. What do you think?


Re: Proposal for the implementaion of Fraunhofer far field

Posted: Thu 14 Jun 2018, 03:11
by Hale_812
>"FFT and interpolation routines in Octave and Python are fast enough"
just a note: "Fast Fourier transforms are computed with the FFTW or FFTPACK libraries depending on how Octave is built. " i.e. it is not related to Octave.
At least FFTW is blazingly fast with a bunch of boosting options. And, AFAIR, it makes partitioning of random-length data automatically. Scilab uses the same.
But there are tons of obscure overloadings for FFT/iFFT functions in toolboxes. That's why you should not load toolboxes, like "signal", when not necessary.