When I write a *.dll such as n(x,y,z) = a*x → where I expect a linear GRIN (non radially symmetric), instead what happens is that the rays do not bend at all, and the result is modeled as wavefront error with no ray deflection. I made sure to mark it as non-radially symmetric.  However, I do know that GRIN4 exists and works. But, there is no example of GRIN4 in sequential mode under surfaces. Any tips for what I might be doing wrong? I did double check all the derivatives, and an analogous version of my code works in non-sequential mode.  

This forum post is a place to collect update history of diffractive tools beta functions, which includes all RCWA DLLs (and visualization API), polygon DLL, and Zemax Grating Data (ZGD) DLL. Content:1. Overview2. Resources3. Change history OverviewCurrently in OpticStudio, we are adding some useful DLLs to enhance the ability of fully simualting gratings. They allow OpticStudio to consider the efficiency when rays pass through diffractive optical elements (DOE), such like 1D/2D gratings, binary optics, or volume holograms. These extensions can be found in OpticStudio installations.These tools improve frequently based on users’ feedback. We decide to provide functions with DLL so it can be updaetd fast upon users' request. Between each OpticStudio public releases, there might be several minor updates and bug fixes. This forum post is a place for changes history.Note all tools provided here are only available with OpticStudio Premium Subscription. If users are interested in these functio

   I created a DLL to model a gradient index surface and while it is working, the modeling results are very similar to a standard surface. It seems that somehow Zemax is not using the gradient index during the refraction process. I have been investigating what I am doing wrong and got more confused.  Your help will be greatly appreciated! :-)   Looking into the example from /zemax/dll/surfaces/us_grin1.c, the refractive indices used for refraction in case 5 are FD->n1 and FD->n2, which are the indices before and after the GRIN surface. In case 6, which is where the index and its derivatives are defined, the refractive index is calculated and the assignment UD->index = index is made, as well as the dn/dx, dn/dy and dn/dz.   So, I am a bit confused:Which refractive index is used during refraction, UD->index or FD->n2? I was expecting that I would use UD->index, but that is not what happens in case 5. How does Zemax ‘know’ that it is dealing with a gradient index materia

I am trying to develop a UDS (User Defined Surface) DLL and have been reading the excellent articles in knowledge base about this. Taking as the starting point the “us_stand.c” code for the standard surface (available in the folder /Zemax/DLL/Surfaces), I understand that Zemax provides an intercept point to the tangent plane (x0, y0, z=0) and direction cosines (l0, m0, n0) for the ray at that point. Then the real ray trace is performed in case 5 and for complicated surfaces there is no analytical solution for the ray intercept point on the surface. Hence an iterative solution is needed.What I am struggling to understand is: how do those equations in case 5 work? I thought that there would be no analytical solution to find the ray intercept point with the standard surface. However, the equations in case 5 seem to be quite simple, although I was not able to derive them.  Therefore, my questions are:Is the algorithm in case 5 of “us_stand.c” implementing a closed-form analytical solution,

In some surface types, e.g. Paraxial XY or Grid Gradient, data entry for Radius and Conic is disabled (their cell value is returned to a blank after typing in a value).Can this behaviour be programmed in a UDS?

What is the best way to validate that the parameters input by the user are valid? For example, say that I have a parameter “n_rows” that needs to be an integer greater than zero. Should I check this upon initialization of the DLL (case 8)? If the input is invalid, should I then change the corresponding FD->param[i] it to be a valid value (e.g., if the user input 0 then change it to 1)? Or is this a bad idea? The example files state that the DLL should only modify FIXED_DATA in case 7, when Zemax is asking for safe data. Thanks

溶液中に存在する粒子の吸光、散乱を評価できるようなモデルをノンシーケンシャル系で作成していて質問があります。Mie.1dllを使用し、光源、溶液、ディテクタの３つのオブジェクトで評価しているのですが、Particle Indexの設定時にわからないことがございます。シェードモデルで光線を確認しながらParticle indexを大きく（初期値から溶液の屈折率より上）していくと、散乱が発生する回数が増える事象が起きました。（光線を保存して光線データベースビューアで確認し、実際に代わっていることも確認しました）想定では屈折率が変わったときに散乱方向や散乱強度に影響はあるが、散乱回数は変わらないと思っていたのですが、こちらはどういった理由で起きているのでしょうか。 

I have created a custom object based on the sample of the HalfCylinder.DLL object. So far, this works. I would like to return a value directly to the non-sequential component editor. E.g. for the half cylinder, add a field volume and return the current volume. This way during optimization, I can control the volume of the cylinder without using extra scripts to use the volume. I tried to use an extra field, and then attribute a value inside the code:in the given half cylinder, in line 64 (just before the switch(code)):data[104] = volume;but the volume field in zemax’ non-sequential component editor is not updated.I hope to get along the idea of I want to do. For the volume, I could use a script in zemax, but imagine it is value that I calculate in cpp anyway, it would be more efficient to reuse this. Is this possible?

In OpticStudio, currently we only support one dimensional grating. However, it's not difficult to simulate 2D grating. Here we will show an example using diffractive DLL.You may compile it with the instructions or use the DLL file attached to this article. Before we start, here are some articles for required background knowledge that we will not repeat in this forum post. How diffractive surfaces are modeled in OpticStudio (KBA) How diffraction ray-tracing is calculated | Zemax Community(forum post) Custom DLLs in OpticStudio: An overview of user-defined surfaces, objects, and other DLL types (KBA) How to compile a User-Defined DLL (KBA) Let's simply open the attached cpp file and observe how it works in non-sequential mode.This example is mainly modified from the built-in sample \Documents\Zemax\DLL\Diffractive\diff_samp_1.c To compile the program as C++ code. We package the functions with extern 'C'.  In this example, we only want to return diffraction ray direction and its rel

I have used User-defined DLL (Source DLL) by myself with compiling CPP to DLL. It is working well in 2023 R2 but it can’t be loaded in 2024 R1. Is there some difference in loading DLL? Please let me know if there is someone who has experience. Thank you. Best Regards,Munseok

I’m working on a pair of DLL files. The sag of the second DLL depends on the parameters of the first DLL, plus a few other parameters. What’s the best way to share information between these two user-defined surfaces? Do I need to add pickups for every parameter (manually or via script)? Or is there some way to pass the entire 1st surface as a parameter/argument to the 2nd surface?

Dear community,I am wondering how the zemax calculate the power of ray, which comes out of the DLL surface (RCWA model for a grating). In the DLL, data [30] represents relative energy of the ray. Here I assum it is diffraction efficiency, which is power flow. Besides, the output electric is also required to give in data [40-45]. Based on my test, the zemax detector seems to calculate the energy of the ray from DLL based on its square module of electric field instead of diffraction efficiency. However, when the diffraction efficiency of first order of light is high, e.g. 99.9%. The square module of electric field is usually larger than 1 because the k-vector changes. Therefore, I have normalize the electric field and multiple square root of the diffraction efficiency to achieve the right number on detector, which is contradictory to the law of wave propagation. Besides, If I did this, the detector energy will change again when this ray from DLL interact with next surface, which is a gla

Hi, I am writing a user-defined scattering dll. I know that Zemax allows users to implement the wavelength shift during the scattering simulation (by specifying a certain shifting ratio in the dialog),  However, my application requires more complex way for determining the wavelength shift, so is it possible that I define the wavelength shift directly in the self-written dll file? If yes, how could I do that? Thanks a lot in advance! 

I have used Gaussian.dll in Non-sequential mode for my application (Stray Radiation in the Launcher). However, there is a problem because Gaussian.dll can only generate the ray bundle with random seed (Stray radiation shows different results in each of calculation). Can I use Gaussian.dll without random seeds? Another option is the generation of Gaussian source using a source file but I also failed to find the direction cosine of the Gaussian beam.  

Hey everyone![All necessary files are attached]I am coding a User-Defined Surface (.dll) to simulate the behaviour of a Diffractive Optical Element (DOE), which in this case will have a phase profile given by the following equation:phase  = (X0Y1 * y) + (X2Y0 * x^2) where X0Y1, and X2Y0 will be coefficients that the user can input in the LDE to later use it for optimization.So far, the code I wrote for compiling the DLL was based on the code written by  @Michael Cheng : “us_binary_mix12.c”, where I adapted it according to my needs. To check whether or not the code is working correctly, I am comparing the rays/beams behaviour when this User-Defined surface is used and when the equivalent “Binary 1” surface is used. If the coefficients X0Y1, and X2Y0 are the same, then I expect the same results, regardless of the surface I use. (Of course, assuming that the units for these coefficients are consistent with each other).Problem: In the front pass of the system, i.e. no mirror space, the res

Hi, I used Rust to build a very simple DLL, inspired by the examples in C and C++ provided with Zemax. The source code can be found here. I compiled it from Windows and a Unix machine with cross compiling. Both versions were as fast as the C alternative I wrote. The compilation method is pretty straightforward and documented in the repo README.It was quite easy to implement similar workflows and structures for some of the other types of DLLs used in Zemax.Yet, I would like to do the same with the 2D version of the diffraction grating. I could only find mentions to the 1D grating in the Zemax docs. The provided code sample covers only a portion of the elements of the pointer and not all of them are fully documented. Does anyone have that piece of information?

I am trying to write a custom GRIN *.dll file for non sequential mode that will allow me to limit refractive index above or below a certain value and just set it to a constant. However, I am having a hard time defining the derivatives to return as required in the GRIN *.dll files. As an example, if my refractive index looks something like below: I would like to cut everything off above and below a certain threshold, even if my n(x,y,z) function gives me a value thats within it. I have currently been doing this with just a merit function and limiting index that way, but would like to be able to just programmatically restrict it. I also tried a variant where I set the derivatives to 0 or ignored them, but had errors tracing the rays. Anyone have a good solution? Happy to provide any files needed.

Dear all:I'd like to run a program organized by python. But it can only be executed once as following.In [1]: runfile('D:/untitled1.py', wdir='D:')In [2]: runfile('D:/untitled1.py', wdir='D:')Reloaded modules: CLR, clr, ZOSAPI_NetHelper, ZOSAPITraceback (most recent call last):  File "D:\untitled1.py", line 139, in <module>    zos = PythonStandaloneApplication()  File "D:\untitled1.py", line 20, in __init__    clr.AddReference(NetHelper)AttributeError: module 'clr' has no attribute 'AddReference'I use the anaconda 64 bits with spyder 5.3.3.I have installed the pythonnet by pip install pythonnetAnd it seems working normally so the program can be run once. But it cannot be run more than twice.Does anyone encounter this problem before? 

I have defined a new Surface Scatter DLL with 8 user defined parameters, but only the first 6 are displayed in OpticStudio. Is there a limitation on the maximum number of parameters (in this case 6)?

I am using us_array.dll to model a lens array. I would like to define clear aperture of each lens in the array, for example the pitch is 500um, but clear aperture is 400um,  is there a way to do this?Appreciate your advice.

I have the latest version of OpticStudio and trying to run an example https://optics.ansys.com/hc/en-us/articles/18254409091987When I open the.zprj file from step 6 of the manual, I get the following error (Image attached). What is wrong with it? How I can fix it?

Hi, could somebody help me, why I can not use a compiled dll using the code from native cpp-file CoatingSample.cpp? Zemax says “Unable to load "UserObjectDefinition" function from DLL”. I hoped, the code from cpp-files are fully ready to become a dll. (Of course, if I use a native dll called “CoatingSample.DLL” everything works) Thanks!Alexei

Hi,I’m looking for “us_gskew.dll” shown to be used in “Using skew rays to model Gaussian beam propagation in OpticStudio” webinar.I download the attached zip files which contained *.c file. I wonder where can I find the complied file. is there a reasone why I couldn’t used an allready complied filed? (and instead have to complie it myself)Thank you,Amir

Hello,It seems that the number of inputs for order efficiency is limited when using Diff2DSample.dll. The image below shows inputs missing orders above 2,-2. Is there any workaround for this? I’m on Zemax OpticStudio 23.1, PremiumThank you,John

 According to Zemax’s online help https://support.zemax.com/hc/en-us/articles/1500005578722-Simulating-diffraction-efficiency-of-surface-relief-grating-using-the-RCWA-method, for the particular diffraction grating that we are trying to model,  we need to increase the Max Order parameter.In the help on “simulating diffraction efficiency  of a surface relief grating using the RCWA method” authored by Michael Cheng and updated on April 28, 2023 under the subsection Max Order it is stated“This is currently limited to 10 (totally 21 harmonics). When the number is larger than 10, it’s modified to 10 in the DLL. Contact support team to increase the limitation.”What is the procedure to increase the limitation?