Hi Greg,

I have spoken with the author of the DLL. She has sent me the source code and a higher-resolution version of the documentation. I am attaching both here. In this version of the documentation, the image which shows how position is defined is a little clearer. Although I agree that it is not obvious that a positive position represents having the source placed +Z away from the waist. I will submit an update to the Help System files to modify that point. 

The provided code is in C++, which is now preferred over C. With the code, you can clearly see how each parameter is defined. You should feel free to update the DLL code with the parameters you require. Instructions for compiling the code are given in the Knowledgebase article 'How to compile a User-Defined DLL.' 

Best,

Allie

PS: I will ask about adding a Non-Sequential tag for use on the forums!

I agree with Greg and it would be good to see the Skew Gaussian stuff being properly integrated into OpticStudio rather than just a user-defined DLL. In particular, it would be good to add it to sequential mode, and upgrade the existing Skew Gaussian calculation:

The existing calculation is fine if the astigmatic Gaussian is perfectly lined up with the local x,y coordinate system, and Paul's method would let you add a rotation angle to this dialog so that you could support a general astigmatism angle Ø. In turn this would make POP much more useful in cases where the beam hits a surface at some general angle rather than a nice, well behaved Ø=0 or 90° angle. 

Hi, Allie and Mark (and Sandrine and David?).

Thank you, Allie, for providing the source code and additional documentation for the circular DLL.  It will help me understand how it is done, but I don't plan on learning C++ or implementing a modified DLL myself as soon as I would like...  I hope that this topic is interesting enough, easy enough, and strategic enough to elevate my request in Sandrine or David's priorities.

Mark, thank you for your endorsement and your musings about more tightly integrating such features into (especially Sequential) OpticStudio.  Right now the Sequential UDS DLL from Paul Colbourne is available through the KnowledgeBase article, but not through e.g. a menu.  That is not a problem for me.  And my own immediate need, as I said, was for a Non-Sequential Source DLL capable of generating rays for 'beams' having 'general astigmatism.'  If it comes through this Forum thread or in another KnowledgeBase article, that's fine!

I have never used the 'Skew Gaussian Beam' feature myself under the Laser and Fibers Group under the Analyze tab, which Mark referred to.  I think this is a bit different, tell me if I am wrong.  Note that the word 'skew' in this Skew Gaussian Beam tool refers to the Gaussian beam axis being skew... not to using 'skew rays' as implemented by Paul Colbourne to 'simulate' and optimize generally astigmatic Gaussian beams.  So we might want two, more different-sounding names for these two features in order to avoid confusion.  I'm not sure what to suggest, since the word 'skew' is correct for both and has already been used for both.

Finally, Mark's suggestion of a Rotation Angle Ø is very interesting.  It could apply to the NSC Source DLL that Sandrine wrote as well.  There is more than one way to define an ellipse.  For example, instead of WaistX and WaistY, a similar set of parameters (yet another 'Definition?') could be WaistMajor and WaistMinor (with, say, the major axis always being in the same starting orientation e.g. local Y) plus Rotation Angle (about the local 'beam' axis).  I was trying to use the Source DLL in global coordinates to point the beam along X, Y, or (best!) Z.  As a result, I always thought of defining the WaistX and WaistY in local coordinates for the Source DLL, using the Object Placement parameters in NSC (see manual p. 480) X, Y, and Z, and then Tilt X, Tilt Y, and Tilt Z to point and twist the Source.  But this could get confusing if the beam is not propagating e.g. in the purely Z (or other Cartesian) direction in global coordinates.

So having a Rotation Angle parameter that is in the local coordinates ('beam coordinates') of the Source DLL might be nice.  Think about it... is it easy enough to specify an arbitrary-oriented (and twisted) Source DLL using Object Placement parameters and Reference Objects, or would this Rotation Angle parameter defined within the Source DLL object be really handy?

Although I mentioned more possible variations above, I don't require ALL possible 'Definition?'s for parameter input.  The user can be expected to do SOME calculation!  But the less one has to do, the more intuitive and user-friendly the tool becomes.  This is a tradeoff between convenience for the programmer--what is easiest and fastest to implement, and convenience for the user.  I'd vote for the programmer...whatever makes it easiest/fastest to get a version of the generally astigmatic Source DLL done so I can start using it!

-- Greg

Hi Greg and Mark!

Thank you for your interest in the DLL. I really appreciate your feedback. Sorry that the parameters were not that clear, but weirdly it is not the same when you are programming and using.

We initially added this dll because one of our users was interested in seeing the propagation of a circular gaussian beam in non-sequential mode but there was no interest on their side to take into account general astigmatism. So we ended up with the easy implementation.

For the general astigmatism, yes it would be great to have it implemented. We need to spend a bit of time on it to get an idea of the work involved and also validate if this could work. Depending on this, we will decide which way to move forward. We can then also decide to update the current Skew Rays in sequential mode works is indeed limited to simple astigmatism.

Sorry it is not a yes or no answer, but I think a bit of work is needed on our side. But it is nice to see the interest.

Sandrine

Thanks for your attention and the update, Sandrine.

I think the astigmatic version of the Non-Sequential DLL should behave fine if the rays are launched as prescribed by Colbourne.

The Skew Gaussian in Sequential appears to me to be a different beast,

i.e.,from that described in Colbourne's KA-01772 , but you might be able to get some ideas from his User Defined Surface (sequential DLL) us_gaussXY.c .  This sequential DLL takes in a set of diverging rays and offsets them in position in angle to generate the rays to be traced.

Using skew rays to model Gaussian beams - webinar – Knowledgebase (zemax.com)

From his journal article on the method:

Generally astigmatic Gaussian beam representation and optimization

using skew rays

Paul D. Colbourne

SPIE-OSA/ Vol. 9293 92931S-8

'This was accomplished in Zemax

(optical design software available from Zemax, LLC) by creating a user-defined surface which offsets rays according to

their angle and the beam waist radii ω0x and ω0y which are entered as parameters of the user-defined surface:

. (28)

The system aperture type is set to “Object Space NA” with aperture value corresponding to θ0x so that rays originate

diverging from a point. It can be verified that the user-defined surface placed at the input converts each launched ray

(with arbitrary pupil value) to a skew ray meeting the conditions of Eq. (8), or Eq. (12) with γ=δ=0, and appropriate

values of p and α or β. The absolute value of θ0x is used in Eq. (28) so that by specifying positive or negative values of

ω0x and ω0y, right skew or left skew rays may be generated. The use of Eq. (28) requires that the input beam is elliptical

and aligned with the x-y axes, with both x and y waists located at the input surface. If the desired input beam does not fit

this condition, for example if it is astigmatic with x and y waists located at different planes, paraxial lenses or coordinate

breaks may be inserted so that an input beam meeting the condition is transformed into the desired input beam.

...'

The method is currently completely available in Sequential if one follows Colbourne's instructions, so I am interested in the Non-Sequential Source DLL above all.

Mark's suggestions to integrate Colbourne's method more tightly into Sequential OpticStudio would be icing on the cake!

-- Greg

I think we're all falling over each other in agreement Paul's method for generalized astigmatic Gaussians is so good and so simple that any and every user who uses OpticStudio for laser beam delivery systems would benefit from it. That has to be a big enough segment of the market to justify adding Paul's methods as a built-in feature.  

About the possibility of a skew ray source for an astigmatic beam (different waist size in X and Y), this is not so easy because a simple ray bundle such as that implemented in SkewRaysCircular.dll only accurately represents the true shape of a Gaussian beam if the beam is circular. If the beam is elliptical, you need to propagate two sets of rays (left skew and right skew) and average the beam sizes to get the true size and shape of the beam, which is not very convenient (see Fig. 3 in the paper 'Generally astigmatic Gaussian beam representation and optimization using skew rays' by Paul D. Colbourne, SPIE-OSA/ Vol. 9293 92931S-8). Having said that, it is possible to generate a ray set that has the true shape of the beam even when the beam is elliptical. One approach is to produce a ray set with a Gaussian distribution of ray positions and a Gaussian distribution of ray angles, which produces a ray density proportional to the beam intensity at all points in space, which is useful for many purposes such as analyzing stray light. However if you want to get a hard-edged visual depiction of the beam size and shape like what you get from SkewRaysCircular.dll, the ”soft” edges of this ray set may not be the best choice. It is possible though to create a hard-edged ray set which shows the size and shape of an astigmatic Gaussian beam; the procedure for this is given in the book chapter “Representation of Gaussian Beams Using Rays,” by Colbourne, P. D., in Advances in Engineering Research, Volume 30, Nova Science Publishers, New York, 1-45, 2019.  I have done this, an example is shown below.

Re: M-squared (M^2) and beam divergence

I didn't mention it above, but we are currently using the new SkewRaysCircular DLL to try to model multimode VCSEL sources having an M^2 of 'a few' (~3-5).

To at least a first approximation, this can be usefully modeled by a Gaussian source having a waist size determined by the VCSEL aperture, but having a larger beam divergence by the measured M^2 factor.

It would be VERY useful (and simple to implement) to have an 'M^2' parameter, in BOTH the NSC Source DLL and also Sequential implementation(s) of Dr. Colbourne's skew ray representation of Gaussian beams.

Paul has confirmed to me that this should just involve increasing the ray angles iin proportion to M^2 ...without changing the ray positions at the waist(s) that are prescribed by the Colbourne procedure.

-- Greg Magel

Hi Greg!

Yes I was thinking. We also added another source DLL called GaussianSource.dll that was written by a user. It defines the spatial and angular distribution of the rays using the beam waist, the beam position and the M^2 factor. Would that DLL work for you?

Sandrine

Come to think of it, adding a parameter for M^2 might come in handy in the 'Source Gaussian' NSC Object.

The 'Source Diode' NSC Object might not need this M^2 parameter; it already admits independent control of waist sizes, positions, and beam divergences in X and Y directions (and even independent X and Y 'supergaussian' factors).

I haven't studied the single 'astigmatism' parameter in Source Diode ('the distance to offset the XZ distribution') to determine whether truly *general* astigmatism is supported in the Source Diode object.  I'll have to play with the Source Diode to see what the 'astigmatism' parameter really does.

It may be that, instead of having a single 'astigmatism' parameter (as is currently the case in Source Diode), having TWO parameters, independently setting the displacement of the X waist and the Y waist along the (source local) Z 'beam' axis with respect to the X, Y, Z 'zero' position of the Source Diode, could be more intuitive--and more consistent with the approach we have been discussing for SkewRays.  If the 2-parameter waist offset is implemented in a future release, perhaps the existing 'astigmatism' parameter should also be retained for backward compatibility with people's legacy models, with instructions to leave it at zero if the new waist offset parameters are used.

-- Greg

I see that Sandrine replied while I was typing my latest message.  Thank you!

Sure, a circular Gaussian with specified M^2 is useful for our multimode VCSEL modeling.  I just found the GaussianSource.dll in the list of currently-available NSC Source DLLs.  Didn't know it was there!  Of course, it only does a circular, non-astigmatic Gaussian.

But please comment on Source Diode, too, and whether its independent control of divergence (both X and Y) accomplishes the same thing as a M^2 factor, and whether the astigmatism implementation is general.

We're going to need some new names to tell these apart, there are too many features that all sound like Source Gaussian and GaussianSource!!

-- Greg

Hi Greg,

Here is some additional information about the Source Diode:

1. The 'Astigmatism' parameter defines the distance along the Z-axis from the Source Diode object to the X-waist of the beam. The Y-waist of the beam is always located at the local of the Source Diode object. Therefore by changing the 'Astigmatism' parameter you can move the X-waist position with respect to the Y-Waist and therefore introduce astigmatism into the beam.

2. Regarding the divergence - if you use these parameters, there will be a change in angular divergence which is similar to what you see with the M^2 factor, but the definitions are not the same. For example, M^2 is defined with respect to the beam waist (w0) whereas the X and Y Divergence parameters are defined with respect to the half angle in degrees at which the intensity of the beam falls to 1/e^2 of its initial value:

Does that help?

Best,

Allie

Thank you, Allie, for chiming in again. This is helpful.

1. Your explanation of theSource Diode Astigmatism parameter does help to clarify what it does.

2. I'm afraid I didn't understand your discussion of divergence and M^2.

An elliptical Gaussian beam has two waists w0x and w0y, not just one w0. Divergence --and M^2-- can be different in x and y, too; in fact, Siegman's tutorials discuss the possibility of an Mx^2 and an My^2.  So a Source DLL for an elliptical beam should probably accept two parameters for Mx^2 and My^2 (which can be the same)--much like Source Diode has separately-defined divergences for x and y.  In addition, of course to parameter(s) for the positions (or separation) between the waists along the propagation axis.

There are also more complicated beams having various kinds of 'twist' as they propagate (according to Siegman), but I'm happy with just a general elliptical Gaussian with astigmatism.  And some way to rotate the x and y axes conveniently (if only using the local Tilt About Z for the NSC Source Object I am requesting; but as Mark mentioned, more flexibility is also needed in the Sequential versions than exist now).

-- Greg

BTW, Allie, perhaps one reason I didn't follow your M^2 comment is because the image just below it doesn't load for me.

-- Greg

Hi Greg,

Yes, OpticStudio provides a GaussianSource DLL that can be used to model the spatial and angular distribution of a Gaussian beam using the beam waist, the beam position and the M^2 factor. It scales beam waist size and far field divergence angle based on the M2 factor provided, as shown below. However, as you've noticed, this is for a circular beam with no astigmatism. And we cannot provide the source code for sharing and modificuation at this point due to proprietory reason. 

We also provide two built-in source models, Source Gaussian and Source Diode, to model Guassian beam, however they don't include aberration or effect of M2 factors. Source Gaussian models an ideal Gaussian distribution emitting from a point, while Source Diode allows an elliptical beam with different X and Y divergence angles as well as different X and Y waist sizes. But again, they don't take in M2 factors. 

It seems there isn't any model, built-in or source DLL, that's currently available in OpticStudio that can consider both astigmatism (different divergence angles in X and Y) and different M2 values along X and Y. If that's your goal, you'll probably need to compile your own source DLL to accomplish the task. And i agree, if we could introduce more flexibility in source modelling, it'll be very helpful for our customers. 

Hope this helps clear things up a bit. Please feel free to let us know if you have any other questions. 

Best regards,

Hui

Here is the link to the non-sequential astigmatic gaussian Source DLL: