Thank you so much Steven for this step-by-step explanation! It makes much more sense to me now.
Regarding the actual field calculation, I noticed that green3d uses the point source field computation from a dielectric dipole moment (adopted from SCUFF-EM with some modification that changes eclectic dipole moment to current). I was wondering when we use the point source formula ( http://homerreid.github.io/scuff-em-documentation/reference/IncidentFields/) for near to far field calculation, whether we can drop the higher-order terms since we are in the far field (MEEP still keeps them). Also, I wonder if there is a reference I could look up the derivation of this point source formula. I'm trying to understand whether it is equivalent to the other from shown in other references, e.g. https://en.wikipedia.org/wiki/Electric_dipole_moment#Potential_and_field_of_an_electric_dipole . This question might be too much of detail, but I'm trying to implement a near to far field calculation for a periodic structure that uses the spectral representation of the periodic green's function to avoid the slow convergence when summing spatially so I want to make sure I understand all the details. Thank you! On Mon, Nov 2, 2020 at 10:58 AM Steven G. Johnson <[email protected]> wrote: > > > On Nov 2, 2020, at 1:35 AM, Mandy Xia <[email protected]> wrote: > My high-level understanding of the near to far field calculation is that > it uses dft to compute equivalent current on the near field box and > convolve with the green's function to compute the field in the far field. > When I looked into the implementation of the > function dft_near2far::farfield_lowlevel, I was wondering where the > integration over current sources is done. It seems that the code it's > adding up the field contribution from each equivalent current source on the > near field box. Maybe I'm missing a place where the numerical integration > is performed or I have some misunderstanding. > > > That's right, this line in farfield_lowlevel is adding up the contribution > of each near-field source point computed by the preceding call to the > "green" function: > > > https://github.com/NanoComp/meep/blob/accad0a827f95e89bd05da08d92f4b4d6ecb7f5e/src/near2far.cpp#L380 > > In fact, this sum is a numeric integral, because the "dV" integration > weight is already included in the Fourier transformed fields array f->dft. > That's done by passing "true" for the 5th argument of add_dft here: > > > https://github.com/NanoComp/meep/blob/accad0a827f95e89bd05da08d92f4b4d6ecb7f5e/src/near2far.cpp#L633 > > which creates the object that accumulates the Fourier-transformed E and H > fields, which corresponds to the include_dV_and_interp_weights argument > here: > > https://github.com/NanoComp/meep/blob/master/src/dft.cpp#L158-L161 > > which leads the DFT object to include the dV factor when it accumulates > the Fourier transforms here: > > https://github.com/NanoComp/meep/blob/master/src/dft.cpp#L232-L233 > > The basic reason for all of this is that the knowledge of how to compute > dV factors and interpolation weights for a Yee grid point contributing to a > user-specified volume is all concentrated in a single place in the code, > the loop_in_chunks function defined here: > > https://github.com/NanoComp/meep/blob/master/src/loop_in_chunks.cpp > > which is used to loop over the Yee grid when updating the Fourier > transforms, and which is described in section 7.2 of the Meep paper ( > http://math.mit.edu/~stevenj/papers/OskooiRo10.pdf). >
_______________________________________________ meep-discuss mailing list [email protected] http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
