Case 3:  This requires a good Fourier Transform lens and I would design such a lens in sequential mode, check the performance with point sources off-axis in the back focal plane and then import that to a non-sequential model.

I would design Case 3 conventionally; almost as an F-Theta lens.

I think GBD is an excellent addition to OpticStudio.  I like it when Ansys (Zemax) adds core features that enhance our generic ability to design / analyze, so I’d much rather see this feature added than a “new surface”.

Happy to collaborate on ZOS-API code to execute this feature.  DM me to discuss.

There has been discussion of GBD from time to time among the Zemax teams. I don’t know what the current status is, but I do see that it has not been formally submitted in the new feature requests system, though it is in the older system. I am going to change that today, so thanks for the reminder. I think it would be an excellent addition in sequential as a supplement to POP and in NSC as well.

I’d like to see Paul Colborne’s excellent Skew Gaussian work being implemented in the code. It would made a much more robust reference frame for POP than the existing pilot beam calculation. 

@Mark.Nicholson / please provide a reference to P. Colborne’s work.  I think this is off topic.

@MichaelH is referring to Gaussian Beam Decomposition - the use of multiple Gaussian beams to represent an entire complex wavefront.

Are you expressing that Skew Gaussian’s are necessary to achieve GBD?

-B

It is a bit off topic, sorry. But connected.

You can search this site for Paul’s work. There are KB articles and dlls that are included in the OS distribution. And although it isn’t strictly necessary for GBP, as soon as you go off axis you’ll have to address the very issues that Paul’s work makes so much easier.

Seems that it is time to follow @MichaelH ‘s suggestion and connect POPPY to OpticStudio…an activity for my copious spare time!

-B

Hi all,

I’ve been working on GBD in my spare time for quite some time. I have tried to use Paul Colbourne’s approach at first to trace off-axis Gaussian beams, but struggled to compute the phase of said beams with his method. I managed to reproduce the results of the paper: https://arxiv.org/pdf/2106.09162.pdf that @Brian.Catanzaro refered to. However, as far as I can test (and it is most-likely my fault), it only works at specific axial distances. For example, in Fig. 3, I can get the nice Airy disc if the distance is 5.52, which is exactly the EFL of the lens. However, if I move away form this distance, I don’t get the effect depicted in Fig. 5. I did speak with the author @Jaren.Ashcraft (who happens to be on this very forum too , and there seem to be an issue with the underlying equation that is being used, namely Eq. 12. This equation was described by Cai and Lin in Eq. 9 of their paper https://opg.optica.org/ao/fulltext.cfm?uri=ao-41-21-4336&id=69426. One thing for sure is that the first determinant of Eq. 9 should be raised to the power -½ and not +½. But for the rest, it is hard for me to double check the derivation of that equation, but I had an insight from a mathematician (who is still working on it) that it might be correct assuming Eq. 3 and 6 are correct (so I’m looking to confirm Eq. 3 and 6 next)! One important thing I noticed is the following. Assuming the following system matrices (according to Cai and Lin Eq. 9):

Which describes a thin lens of focal length f = 100.0 mm followed by an air space of length z = 100.0 mm. If we use a beam like so:

Which describes a non-decentred symmetric Gaussian beam at its waist position with a Rayleigh range of 1 / 0.0031831 = 100 * pi (the wavelength is 0.01 mm, and the waist is 1 mm, leading to the 100 factor). Simply looking at position:

We see that we are left with the first determinant and exponential of Eq. 9. If one calculates the determinant of E(r_2), assuming I did not make a mistake, one gets a value of 1.5707723114645764 instead of the expected Gouy phase shift of 0.3081690711931703 that POP and this equation return:

I’m not sure at all whether this is the problem, but just something I noticed. And that problem doesn’t prevent the correct calculation of the Airy disc at Z = f.

I’m a bit desperate at this point so if @Brian.Catanzaro or @MichaelH or anyone else are interested, I’m happy to share whatever I have done so far (which is Python based).

Take care,

David

Hello all!

Thanks for the tag David. Hi yes I’ve thought a lot about the GBD problem and have since made some strides into making it a little faster.

The SPIE proc that @MichaelH linked was my first big crack at the problem where I thought I had more or less solved the propagation. However, I found that the results only really converged for paraxial optical systems (where Angular spectrum is much more practical and accurate).

I’ve since developed a more general method and submitted it for publication, but alas the review process has taken about 7 months. However I do know an awful lot about it now, so a few comments…
 

• re: @MichaelH’s point: GBD does have problems with modeling high-spatial frequency errors (MSF, sharp-edge diffraction). This is a problem that isn’t “solved”, but various investigators have proposed solutions that have not been compared to eachother
• re: @Brian.Catanzaro’s question; GBD does generally require skew beamlets for computing nonparaxial system diffraction. 

I’ve actually been developing a Python package to connect POPPY to OpticStudio and CODE V, which has benefitted quite a bit from @MichaelH ‘s faster BatchRayTrace.dll. I’m looking for collaborators to help me turn it into something more useful for the community, if anyone is interested.

The package is called Poke, and it operates by using Ray-tracer Python API’s to save ray data to a Python environment and do Physical optics calculations. I have an experimental GBD module built in, but also a Polarization Ray Tracing (PRT) module. I was able to use PRT with POPPY to do some “polarized field propagation” in this demo. https://poke.readthedocs.io/en/latest/notebooks/jonespupils.html

The code is fairly immature, but for those interested in collaborating feel free to send me an email or open an issue on the Poke GH: https://github.com/Jashcraf/poke

Can you help me understand the POPPY and POKE references please? Are these trying to reproduce the built-in POP or Huygens results, or are they trying to add something different to the existing capability?

• Mark

It’s more of an addition to existing capabilities. One example for migrating to Python is to take advantage of supercomputer-scale GPUs for rapid forward modeling while propagating arbitrary amplitude and phase errors. AFAIK, ray tracers can’t presently do that, but if you want to capture the influence of your Ray OPD for example - you can use Poke to link the ray model to the diffraction model.

Good luck with that!