[Webinar] Using Skew Rays to Model Laser Beams [Q&A]


Userlevel 1
Badge +2

This thread is dedicated to the upcoming webinar: Using Skew Rays to Model Laser Beams. Any questions received during the webinar will be responded to as a reply on this thread. Feel free to post your own questions! The speaker will be notified and will respond as long as the thread is still open.

Be sure to subscribe to this thread if you want to see additional discussion regarding this webinar topic. The thread will be open to new replies until Friday, April 22nd. 

 

Webinar details

Register here: [The webinar has concluded.]

Date: Thursday, April 14th. 

Time: 6:00 - 6:35 AM PDT, and 11:00 - 11:35 AM PDT

Presenter: Paul Colbourne, Senior Optical Designer at Lumentum

Abstract:

In this webinar, Lumentum’s Paul Colbourne will describe how to use skew rays to model Gaussian beam propagation in OpticStudio. Skew rays are an efficient and accurate representation of Gaussian beams and can be used to quickly optimize for best focus or to minimize aberrations. Paul will demonstrate how to set up User-Defined Surfaces to generate skew rays, how to view circular Gaussian beams in 3D layout diagrams, and how to optimize systems with circular Gaussian beams. In addition, Paul will explain general astigmatism, and how to calculate the properties of a generally astigmatic Gaussian beam in OpticStudio using a ZPL macro. Paul will also show how to use a merit function macro to optimize systems with elliptical or generally astigmatic Gaussian beams.

 

Allie 1 year ago

Watch the recording!

A recording of this webinar is available here: On-demand Webinar: Using Skew Rays to Model Laser Beams

View original

This topic is closed to new comments

27 replies

Badge +1

Looking forward downloading the related files, do not see links here.

Userlevel 6
Badge +2

Watch the recording!

A recording of this webinar is available here: On-demand Webinar: Using Skew Rays to Model Laser Beams

Userlevel 3
Badge

Hi, Allie and Paul.

I, like Elena in the previous post, am looking for a set of Paul’s presentation slides to download.  I went to the webinar recording and can’t find any links for such a download there (either through your link in the posts above, OR from post-webinar attendee email, which leads to the same place, i.e. to re-register for the webinar to watch the recording).

-- Greg

Looking forward downloading the related files, do not see links here.

Same here, how to access the related files?

Thanks very much.

Userlevel 1
Badge +2

@Elena.Sokolova , @bingshao , @PhGeek , Here are the files related to this webinar.  Thanks for watching!

 

Badge +1

Thanks!

Hello Paul,

If I may, I’d like to ask a question related to general astigmatism. It came to my mind after seeing the webinar, that’s why I’ll post it here. I hope that’s okay.

So basically, I’d like to know if general astigmatism is covered or neglected by Zernike aberration analysis. Imagine an imaging system which fulfills the necessary conditions for Zernike computation (circular pupil, homogeneous illumination etc.) but induces general astigmatism for specific field angles. Is a wavefront analysis for these field angles sufficient to cover general astigmatism?

And furthermore, are the Zernike astigmatisms (e.g. Z5/Z6 or higher) and general astigmatism even comparable? Or do I need to think of them as different concepts?

--Fabian

Userlevel 1
Badge +2

Hello Paul,

If I may, I’d like to ask a question related to general astigmatism. It came to my mind after seeing the webinar, that’s why I’ll post it here. I hope that’s okay.

So basically, I’d like to know if general astigmatism is covered or neglected by Zernike aberration analysis. Imagine an imaging system which fulfills the necessary conditions for Zernike computation (circular pupil, homogeneous illumination etc.) but induces general astigmatism for specific field angles. Is a wavefront analysis for these field angles sufficient to cover general astigmatism?

And furthermore, are the Zernike astigmatisms (e.g. Z5/Z6 or higher) and general astigmatism even comparable? Or do I need to think of them as different concepts?

--Fabian

Hello FabHen,

“General astigmatism” as I used the term in my webinar is not really an aberration, it is a property of a Gaussian beam. A Gaussian beam with “simple astigmatism” has different focal points in X and Y, but this is not necessarily an aberration, unless it is unintended; when we pass a beam through any lens, we change its properties (waist size, etc.) but this does not mean the beam has become aberrated. “General astigmatism” is just a condition that the beam can be in, without necessarily being aberrated.

Having said that, yes Zernike aberration analysis is capable of describing any wavefront, so the wavefront of a Gaussian beam with general astigmatism could be expressed using Zernike coefficients.

Paul C.

Userlevel 1
Badge +2

@Ted 

Q: Can you model decentered beams this way?

A: Yes, decentered beams can be modeled by subtracting the central ray’s position and angle from each ray’s position and angle.  The process for doing this is a bit involved, but you can refer to the GenAstigGaussianBeam.zpl macro for reference.  The way the macros are currently written, the input beam is centered on the optical axis, if you want your input beam to be decentered, you can use field points or coordinate breaks.

Paul C.

Userlevel 1
Badge +2

@ld 

Q: Can we get Zemax example file used in this presentation that include your ZPL31 macro?

A: Please see the file uploaded in a previous comment.

Paul C.

Userlevel 1
Badge +2

@Zhilin.Hu 

Q: where did you get us-gaussXY.dll? 

A: I wrote this myself as a C program, starting from the supplied example file us_stand.c.  See the files uploaded in a previous comment.

Paul C.

Userlevel 1
Badge +2

@slava.kachkanov_01 

Q: Can you show the merit function?

A: The example files I showed in the webinar are in the file uploaded in a previous comment, see above.

Paul C.

Userlevel 1
Badge +2

Q: Can we use skew ray method for High NA (0.55) of diverging beam? divergence angle: 67 deg (full), emmiting area: 1 x 1.2 um, collimating beam: 8 mm

Does Paul speak now or recorded version? I watched recorded version before.

A: The skew ray method can work for high NA diverging beams.  In the macros I wrote, the beam is defined by the waist size, so you need to be careful to specify the correct waist size which corresponds with the divergence you wish to have.

This time, the webinar did not have a live question and answer session, the questions are answered in this forum.

Paul C.

Userlevel 1
Badge +2

@Rob.Stead 

Q: Can you explain the purpose of the coordinate break in this model?

A: The coordinate breaks were used to provide arbitrary rotation of the cylinder lenses.

Paul C.

Userlevel 1
Badge +2

@Patrick.Thompson 

Q: Skew ray pattern looks like a "finger trap" ?

A: Yes it does! 😀

Paul C.

Userlevel 1
Badge +2

@Ying 

Q: where to get ZPL31?

A: See the file uploaded in a previous comment.  If you install the included archive files, you will get the macros used.

Paul C.

Userlevel 1
Badge +2

@Kaia.Williams 

Q: Are there issues with using coordinate breaks with skew beams generally, or the ZPL macros specifically?

A: Coordinate breaks may be used with skew beams generally and the provided ZPL macros.  The central ray is subtracted from all ray positions and angles so that the beam properties can be calculated even after coordinate breaks.

Paul C.

Userlevel 1
Badge +2

@James.Sheil 

Q: Do you have any general rules of thumb for when to choose between the following methods? Physical Optics Propagation, your method of Skew Rays, Non-sequential propagation using fiber1.dll or Gaussian source, and other methods

A: My skew ray method is a robust method of computing Gaussian beam properties which works with generally astigmatic beams; almost all other methods of computing Gaussian beam properties use formulas which apply only for simple astigmatism and will give incorrect results with generally astigmatic beams.  POP is used when coupling efficiency information is needed. Non-sequential propagation would be useful for stray light analysis, or other applications where non-sequential modeling is preferred.

Paul C.

Userlevel 1
Badge +2

@shawn 

Q: compared to POP, what is the limit of this skew ray that may not replace POP?

A: The skew ray method cannot compute fiber coupling efficiency when the beam is affected by apertures or aberrations, for this a diffraction calculation such as POP is needed.

Paul C.

Userlevel 1
Badge +2

@Dusan 

Q: Does it make sense to represent a laser diode as an elliptical Gaussian beam and raytrace it as such?

A: Yes, this can be done using the us_gaussXY.dll user-defined surface or the gaussian.dll non-sequential source.

Paul C.

 

Userlevel 3
Badge

Thanks again, Paul.

Are you going to post your webinar slides?

I got all the example files, DLLs and macros from the link above.

-- Greg Magel

Userlevel 3
Badge

Re: Non-Sequential source models for Gaussian beams, there are various limitations in all of the “built-in” sources like “Source Gaussian” (which I have never used because it is so unphysical); I have had luck using the Source Diode model.

Besides the built-in “Source XXX” models that appear in the list of Non-Sequential Objects, there are also the choices listed under “Source DLL” -- which include “GaussianSource.dll” (models a circular Gaussian of arbitrary M2) and even “SkewRaysCircular.dll” (which is an earlier stab at Paul’s method for only circular stigmatic beams with M2 = 1, by Sandrine Auriol of Zemax).

There are many attempts by users to supply better non-sequential source DLLs.  And much confusion can be caused by their similar names, as you can see… (Source Gaussian vs GaussianSource.dll...)

My favorite user-contributed DLL has been available for download in this Community thread in Code Exchange (if you log in as a supported user):

 

Dirk Brömme has shared a very general DLL written by Steffen Erhard and @Dirk Broemme of Coherent that Sandrine posted there.

The DLL is called AstigmaticGaussian.dll , and it supports general astigmatism with different x and y components for waist w0x and w0y, waist positions z0x and z0y, and even separate M2x and M2y.  Just what I always wanted, and useful for simple circular Gaussian beams as well.  The other Sources and DLLs need only be retained for backward compatibility with earlier designs.

It can be downloaded here:

AstigmaticGaussian.dll is not included in release versions of OpticStudio, and so far the only way to get it is to download the .zar file containing it.

And there are many more Community threads with people (including me) asking similar questions on how to model Gaussian beams.  We should work with Zemax to unify this somehow and clarify their capabilities.

-- Greg

 

Userlevel 3
Badge

BTW, I said there are many questions/threads in the Community with answered questions on Gaussian beams;

to find them, I suggest trying a search on “gaussian” and see the many hits.  Some are useful for calculation/optimization (like Paul’s method) and some are just for visualizing the “envelope” (typically at the 1/e^2 radius w) of a Gaussian beam.

The AstigmaticGaussian.dll is relatively recent (“5 months ago” as of this post).

Here’s a handy post from Allie of Zemax from 3 years ago that belongs in the User Manual: how to set the Position parameter to get the desired divergence using the Source Gaussian built-in NSC source:

But remember, the Source Gaussian is not quite physical, since the rays generated by this source, while weighted with a Gaussian probability distribution, all appear to emanate from the same point.  So this is OK in the far field (outside the Rayleigh range zR), but not good within zR of the source point.

 

Erratum:

Sorry, guys, Steffen Erhard is with TRUMPF, while Dirk is at Coherent (both in Germany).

-- Greg

Userlevel 1
Badge +2

I have attached the presentation slides here.

Paul C.

Userlevel 1

Hi Paul,

Thanks again for this talk - I’ve found your tools to be massively useful so far.

When using us_gskew.dll, what is the significance of the aperture definition? I see that you’re using an Object Space NA of 0.3 - making this NA faster seems to increase the offset produced by the .dll, and likewise making it slower reduces the offset. Is there a “correct” setting of Object Space NA, or it situation-dependent?

Thanks again,

Kaia