Draft: Attempt on waveplates and polarizing splitters

[TacHawkes]

Initial attempt to use the recent polarization improvements for waveplates and polarizing splitters.

[codecov]

Codecov Report

❌ Patch coverage is 84.39716% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.16%. Comparing base (16cecf8) to head (7076f59).

Files with missing lines	Patch %	Lines
...ticalComponents/Beamsplitters/PlateBeamsplitter.jl	42.10%	11 Missing ⚠️
src/OpticalComponents/Polarizers/JonesCalculus.jl	78.00%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
+ Coverage   71.57%   72.16%   +0.59%     
==========================================
  Files          57       59       +2     
  Lines        2881     2968      +87     
==========================================
+ Hits         2062     2142      +80     
- Misses        819      826       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TacHawkes]

@StackEnjoyer Please have a look at the recent changes. I have thought about the API and was not happy anymore with the structure introduced in #25

Therefore the last commit introduced the following changes:

1. Moved all Jones related code out of PolarizedRays.jl and into the JonesCalculus.jl because this is the natural "home" of this code and allows to introduce multiple parallel mathematical polarization frameworks in the future.
2. _calculate_global_E0 now works on <: AbstractObject as the dispatch is already Jones-specific due to restricting J to GlobalJonesMatrix. At the moment it is debatable if we actually need the type AbstractJonesPolarizer{T, S}.
3. _calculate_global_E0 now works for changing direction by calculating Q_out = I - out_dir * transpose(out_dir) and using this for P = Q * P *Q' instead. This seems to work but maybe needs more testcases/further testing.
4. Clearer docs for the newly introduced types in this PR. An entry in the general documentation on the polarizing components is still missing.

Note: While in my test cases you can use the wave plates and splitter fine for splitting beams based on polarization, the issue remains that we cannot properly track the electric field strength through components with n != 1.0 and so normalizing output against input power leads to violation of energy conservation 😲.

[StackEnjoyer]

Note: While in my test cases you can use the wave plates and splitter fine for splitting beams based on polarization, the issue remains that we cannot properly track the electric field strength through components with n != 1.0 and so normalizing output against input power leads to violation of energy conservation 😲.

This is a general issue with the "1D"-PolarizedRay. Tracking optical power through a system requires to track the imaging effects at all surfaces in order to consider "stretch" and "compression" of a 2D/3D-field with corresponding optical power. Test cases for individual rays can in general only consider the direction and phase of the E-field vector and will violate energy conservation.

As long as all components are non-imaging, some form of "power conservation" should apply however. Is this true for your testcases?

[StackEnjoyer]

Some todo's for myself

• check if P*in_dir = out_dir for the new global approach
• check orthogonal incidence beamsplitter testcase
• add "power conservation" test case
• check pi phase jump for the PCBS

[StackEnjoyer]

"Energy" seems to be maintained for the PCBS testcase, minus the losses via the Fresnel coefficients at the air-glass-air interfaces.

[StackEnjoyer]

I now had time to review these changes in detail. The waveplate features seem logical. However, there are some major issue regarding the newly introduced beamsplitters. I have primarily review the RectangularPolarizingPlateBeamsplitter and PolarizingCubeBeamsplitter.

PolarizingBeamSplitter

I think the pi phase jump must be considered when splitting the beams. This is not relevant for the Ray implementation of the splitter, but important here.

RectangularPolarizingPlateBeamsplitter

This type uses the API of the non-polarizing plate splitter but there are some issues with this approach. The PBS API bypasses coating-substrate refraction by directly calculating refraction. This is fine for non-polarized rays, however, for the E0 field vector an entire Yun-calculus step is missed, including Fresnel losses. Critically, this leads to "Ray dir. and E0 must be orthogonal." for n > 1.

PolarizingCubeBeamsplitter

I would expect this type to work out of the box with the cube splitter interface, since it is programmed more "elegantly". But I also got odd behavior here for n > 1. More investigation is necessary.

Conclusion

I think we need to consider the polarization calculus steps in more detail before we can ship theses components. The underlying thin polarizing splitter API seems fine so far and maybe we can unify the thin splitter interact3d methods by dispatching on Ray and PolarizedRay.

The robustness of the current PBS API can be improved, which should eliminate the errors that plague the RectangularPolarizingPlateBeamsplitter