Thank you so much for these pointers and they helped me a lot. I was able to implement a 3D Periodic Green's Function (PGF) in MEEP based on equation 3 in Rapidly Convergent Representations for Periodic Green’s Functions of a Linear Array in Layered Media ( https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6059491).
In my problem, I have a periodic cylinder structure along z-direction and I would like to compute the scattered field in the far field. Using the spectral representation of PGF, I'm able to compute, for a particular point in the simulated period, what the total contribution summing over all the period is, without an expensive spatial sum. In order to collect all the contributions from the cylinder, the last step I need is to integrate over the simulated period and I was trying to rely on the numerical integration over near-field box in MEEP to handle that. However, I found that the computed results are off. I suspected this was due to the staggered grid we are using. I examined the coordinates of the discrete points on the near field box. For some (x, y) combinations, we have z coordinates going from -period/2 to period/2 in z and in total an odd number of points. In some other (x, y) combinations, we have z coordinates going from -period/2+half_cell to period/2-half_cell and in total an even number of points. So it seems that in the above two scenarios we are integrating over different lengths in z. However, in order to get the correct contribution, I need to integrate over exactly one period of the structure. I'm wondering if you have any suggestions on this. Or maybe there is something wrong with my understanding of the staggered grid, and it would be great if you could point it out. Thank you! On Mon, Nov 2, 2020 at 2:10 PM Steven G. Johnson <stevenj....@gmail.com> wrote: > > > On Nov 2, 2020, at 11:49 AM, Mandy Xia <m...@cornell.edu> wrote: > 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). > > > You're right that, far enough away, only the leading-order 1/r terms will > matter. However, technically the "near-to-farfield" transformation can be > evaluated anywhere in space, not just in the far field, thanks to the > Equivalence Principle. So, we keep all of the terms just in case someone > evaluates a point close enough for their contributions to matter. > > In the future, a possible optimization would be to preprocess the > far-field points and check that they are far enough away to drop the > higher-order terms, and if so call a simplified Green's function. But I'm > not sure how much this would actually matter in practice. > > 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 > . > > > That Wikipedia article is for the electrostatic field, which is different > from the field of an oscillating dipole (also called a "dipole antenna"). > > You can find lots of references for the field of a dipole antenna; e.g. > Jackson's *Classical Electrodynamics* book covers the topic. > > 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. > > > SCUFF-EM implements a Ewald summation for this case; see: > > > https://github.com/HomerReid/scuff-em/blob/324bfd2c88a663b062f547184c666752075f9128/doc/docs/tex/EwaldTake1.tex > > https://github.com/HomerReid/scuff-em/blob/324bfd2c88a663b062f547184c666752075f9128/libs/libscuff/GBarVDEwald.cc > > We discussed porting it to Meep (https://github.com/NanoComp/meep/pull/769) > but haven't worked on it yet. >
_______________________________________________ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
