Feature/etalon cavity

[pslocum]

These changes include minor, optional adjustments to the ideal pillbox cavity model. To approximate an etalon [caterpillar] cavity with N subsections and N channels, the readout is divided into 3 channels isolated by subsection. Additionally, the Doppler shift is calculated in terms of the length of each subsection.

[jkgaison65]

This implementation should work consistently internal to this class, but may run into other issues when called with the CavitySignalGenerator class. See further comments around (new) line 343.

[jkgaison65]

I'm a little worried about the current implementation. First, I do believe it's internally consistent. Because the probes are all in the longitudinal center of their respective subcavities, and because we're always normalizing the modes anyway, there's no numerical difference between what you're doing and just setting up three separate ideal modes. One issue, though, would be if you move the probes off center (e.g. z=0.1 in some systematic study), where the L/D ratio in your doppler calculation would be different by a factor of 3 from this EfieldAtProbe part. Thus displacing your probe from the center could have an improperly scaled effect (e.g. partial effect from z=0.03 or z=0.3 rather than z=0.1, depending on how you define your displacement).

[pslocum]

Thanks for the read. For a test with a probe at e.g. z=0.1, should the Doppler shift (as implemented) be affected? In general, it looks like we have not been doing that. Or is there a different interpretation?

[jkgaison65]

Let's take an example where the total cavity length is 12m, with each segment being 4m long. The doppler frequency is properly getting adjusted to use L=4m in the linked reference. But since tProbeLocation stores the z-coordinate in real units, and GetNormalizedModeField works in the units of the full cavity (L=12m in this case), setting tProbeLocation = (r,theta,z=0.1) would effectively only be using tProbeLocation = (r, theta, z=0.033) if you're interpreting it as being the position in the segment rather than the whole cavity.

[pslocum]

aha, thanks. so I was thinking that the probe z-locations should be defined in terms of the whole cavity length, as in e.g.
"cavity-length": 4.9,
"caterpillar-cavity": true,
"cavity-probe-z0": 0.817,
"cavity-probe-z1": 2.450,
"cavity-probe-z2": 4.084,

and that GetNormalizedModeField() should return the field that was normalized over the whole cavity volume (a.k.a. over the entire imported mode map, as usual). But, even assuming that all of that happens, then there is still a complication in the Doppler shift. So the present approach is to consider each etalon segment as a standalone cavity when implementing the Doppler shift, independent of the overall field normalization.

[jkgaison65]

If we just want to test some functionality with getting multiprobe readout working, this should be sufficient to start testing that. Moving forward, I'm a little worried about how this interfaces with the CavitySignalGenerator, though. In that, the electron will more prominently couple to the 2nd segment over the 1st and 3rd due to the shape of the TE011 mode across the whole setup, while the probe couplings will have equal couplings within their given sections. Also, since this is modeled as a single mode in the CavitySignalGenerator there is an innate coupling between the phases in the three different segments that may not hold accurate when modeling as three independent modes. And realistically, I think these independent modes will have a relative phase relationship dependent on the pitch angle, which may not be accurately modeled using this implementation.

Seperately, one pitfall of our current multimode implementation is that we assume all modes are uniquely identified by their l,m,n indices, but for mode imports there won't be a clear distinction using those indices. We may need to reimplement how we define imported modes, but that's probably a problem for a future implementation.

[pslocum]

Thanks very much for the comments. A couple of points that may help clarify:

[pslocum]

Thanks very much for the comments. A couple of points that may help clarify:

• We are assigning default mode indices to our mode map imports so that we can use one workflow in our calculations. Agreed that "mode indices" for imported mode maps might not be obviously meaningful.
• The signal phases are presently calculated from the orbit phases. The signal amplitudes are extracted from the mode field amplitudes, which can vary somewhat independently between the segments. So we might expect the channels to have phase coherence, but with some amplitude modulation.

I agree that this preliminary approach could benefit from more thinking and discussion. A cross check would also be helpful. Thanks again.