fix hankel overflow from high index/freq

[hammy4815]

This should fix the issues with overflows from the hankel functions. I had to reformulate and manipulate a few things so I will explain in detail:

[hammy4815]

I am now using the exponential hankel functions and pass in the following wrappers that scale by the inverse of the exponential to correctly pass in a hankel function (or bessel at the origin).

In the exponential I am "shifting" by some amount shift, which really is just an extra factor being multiplied into the system. This is explained below:

[hammy4815]

I use sys.float_info.max to create a threshold. If the argument into the hankel functions ($kr$) has an imaginary component that is bigger (in magnitude) than this threshold, then I scale my entire system by a factor ($e^{-s}$ for scale s), to bring the magnitude smaller than what will overflow in the exponential. Without this extra scale component, reformulating with the exponential bessel functions would be useless because the overflow would instead still happen in my normalizing exponential term $e^{\pm kr}$ rather than in the old hankel functions.

If we want to use another way of deciding the threshold besides sys.float_info.max then I can change it.

[hammy4815]

I created this new function to minimize the amount of repeated code because I now need the term $kr$ in get_fields as well as green2d.

[hammy4815]

I am now passing in my masks for outgoing_arg, incoming_arg, and waist_points before calling green2D to eliminate the overflows that were happening when the wrong hankel was being used for a given argument despite those indices of X not being used. Before I was doing this while constructing the final fields2D array.

[stevengj]

So this changes the scaling of the resulting fields?

I would suggest rescaling all the time, not just when np.abs(max_imag) ≥ max_float. The reason is that we generally want Meep's outputs to be a continuous function of its inputs, not jump discontinuously when you vary some parameter (e.g. a beam waist) pass some threshold.

(Unfortunately, this complicates the meaning of the beam amplitude parameter.)

[hammy4815]

So this changes the scaling of the resulting fields?

I would suggest rescaling all the time, not just when np.abs(max_imag) ≥ max_float. The reason is that we generally want Meep's outputs to be a continuous function of its inputs, not jump discontinuously when you vary some parameter (e.g. a beam waist) pass some threshold.

(Unfortunately, this complicates the meaning of the beam amplitude parameter.)

The scaling only changes the order of magnitude of the Hankel amplitudes. Phase is preserved. In addition, after calling green 2D where needed, the final fields are normalized such that the beam waist is amplitude 1. Thus, the scaling only affects the algorithm’s intermediate magnitudes, preserving the magnitude of the final output. Thus I wouldn’t expect a discontinuity in the output.

in other words, when rescaling $H(x)\rightarrow aH(x)$, when we choose $a$ shouldn’t matter because the final normalization $\frac{G(aH(x))}{G(aH(0))}$ is independent of $a$ since the greens function $G$ is a linear combination of Hankel functions $H$.