Closed yaugenst closed 1 year ago
Interesting! We have this example showcasing various filed pojrection results, as well as various tests vs analytic results (e.g. far field emission of a dipole, scattering from nanoparticles,...). We know that our projection works as expected in many cases, so it's important to figure out what is going on here. The dependence on resolution is indeed very weird. The projection distance should not matter when you have the far field approximation on, which is true by default (more precisely, it should just be an overall scaling factor).
@shashwat-sh could you take a look?
I'll take a closer look, but right off the bat my initial guess is that the fields are being projected backwards. I'll look into this more carefully though.
Ahh so it's just some numerical-precision-level power? That makes sense.
Yeah. The definition of angles
should be with respect to the global coordinate system. So here, since we are projecting "downwards" along -z, I think the angles
(in degrees) should be (165, 185)
rather than `(-15, 5).
Or rather (175, 195)
Ooooooh... well, that solves it then:
Thanks a lot for the quick resolution.
I think this has come up before - maybe we should add a validator that warns when the requested angles are "behind" the monitor, to make sure the user is aware? @momchil-flex
I'm wondering if perhaps from a user standpoint it would make sense to flip the global coordinates depending on the normal_dir
? Intuitively most people would define their coordinates like that I guess.
Yeah that's also a good point
I think the challenge was that in some cases, like scattering from a sphere, the projection monitor is a closed surface, and the normal_dir
doesn't have much meaning unless you look surface-by-surface. In that case, it made sense that the angles are always defined in the global system. But maybe we can treat the open-surface and closed-surface cases differently.
Right that makes sense. Then a warning as you proposed is probably a better approach.
Yeah we probably don't want to break backwards compatibility on this, even though in the 3D case we actually support giving the monitor a 3D geometry, and we handle the normal direction assignment internally for all surfaces. For a 2D monitor, what exactly does normal_dim
affect, if not the global axis orientation? In this particular example what happens if I set the angles to (175, 195), but use normal_dim = "+"
?
normal_dir
affects how the equivalent surface currents are computed from the fields, i.e. it is the n
in n x E
, n x H
. So its definition actually does not relate to the projection space at all, but rather the source current definition
Well, implicitly it does relate to the projection space, but yeah, in your example, it would again be as though you're projecting "backwards" if you set normal_dir
to +
Changing it just adds a global - sign to the projected fields then? I think that makes sense, but yeah not super useful (or natural) if it doesn't flip the coordinate axis. But yeah I think historically it was mostly for accounting surfaces of 3D boxes.
I think a warning is fine yeah, if a 2D monitor with normal_dim = "-" but theta < 90.
Ok sounds good. I guess in future major releases when backwards compatibility is being broken anyway, we could try to think of a better design, maybe treating the 3D and 2D cases differently
Curious why +/- propagation direction matters here when propagating to infinity? In free space wouldn't the fields look the same whether you propagate to +infinity or -infinity?
If a plane wave going up has (E, H) then the plane wave going down has (E, -H). The sign matters and is what makes the field projection directional. The quick and dirty near2far script in the code above takes only the E field into account and cannot make that distinction though. In our projection, both E and H contributions are included.
Ah I see, yes including H is more accurate. Thanks!
We have come across some potential issues with the
td.FieldProjectionAngleMonitor
. In particular, we seem to be unable to reproduce far field radiation patterns when compared to either Lumerical or our own implementation of the Fraunhofer approximation, which both match each other (courtesy of @bhnzhang). Maybe we are not using the monitor correctly? But what is especially weird is that the monitor does not seem to converge with higher resolutions. Is there documentation on what exactly thetd.FieldProjectionAngleMonitor
implements? Since there is aproj_distance
parameter, I'm guessing it's a different calculation.This is what our comparison looks like:
It is strange that the two plots (very roughly) match only for the lowest resolution. If we zoom in a little on the higher resolutions the difference becomes even more pronounced:
This is the simulation setup:
Here is the code to reproduce these results. Note that we originally came across this issue in a different setting (grating coupler simulations), but I reduced it to the MWE below:
The match does become better when the near field is not perturbed as much.