Zemax Sx

0 views

Skip to first unread message

Latrina Mosely

unread,

Aug 3, 2024, 6:00:59 PM8/3/24

to icaradam

You did, however, mention that you had a rather large amount of configurations, making a large merit function, which in turn made your resulting file behave slowly. Though I cannot see your file, I am thinking that one main drag on your system is really due to the large size of the merit function.

For example, even with a very simple file (our sample Cooke Triplet), if I make 25 identical, 'dummy' configurations, and build a merit function that takes into account all of these configurations with high sampling, no axial symmetry assumed, etc (essentially settings that will create as many operands as possible), I can observe similar behavior where even Comment cells take a few more moments to update as compared to an empty merit function file. We can also see that the file size is comparatively much larger:

So, my immediate recommendation is to try and either reduce the merit function size or potentially save as much of it as you can to a .MF file from the Merit Function Editor itself. That way, you could temporarily remove the merit function and make some modifications to your model as needed. I did also see that you're trying to modify the merit function itself, so if modifying the merit function editor is taking an extremely long time, I wonder if you might find some benefit to modifying the .MF file directly (it can be opened and modified in any text editor, but you won't see things like the headers for each column). This is a bit of an extreme step, but with this large of a merit function, I think it's all I can recommend at this moment.

I read six values with PMVA convert them to absolute values (ABVA) and multiply some with a constant factor (PROD) add these to others (SUMM) and than limit this to a constant value (ABLT). This are about 25 lines in the MF per config.

OpticStudio uses multiple threads in optimization at the variable level. So, if you have n optimization variables, it needs n+1 evaluations of the merit function for every optimization cycle, and it is the evaluation of the MF itself that is threaded, not the individual operands. (There are some exceptions, like IMAE and NSTR, but let's leave that.) The MF itself is a single long list of commands, and they are executed sequentially.

For functions like I read six values with PMVA convert them to absolute values (ABVA) and multiply some with a constant factor (PROD) add these to others (SUMM) and than limit this to a constant value (ABLT), there is no way to thread that, as every line depends on the previous line and so must be performed in order.

But, I am concerned about a merit function that is so long that it bogs down the UI...I can't see it being effective in optimization except on a geological timescale. If you can, I'd suggest you email your file to sup...@zemax.com so one of the engineers there can see exactly what's going on. There may be better ways to do what you want, but it's really hard to say without seeing what the file is doing.

Thanks for sharing your system with us. I've been looking over it and I'm not sure there's anything more we can do to address the speed issue beyond what Mark said. Your merit function is very, very long. One of the longest I've seen. And if it needs to be that size, so be it. But with the number of fields, configurations, and the complexity of the system itself, it just takes time to calculate the data.

Mark's idea should bring the problem to a stop. If there's no open merit function, then there's nothing to update. You probably don't need to see the results of any particular line as you're making changes, so this would be a good way to make OpticStudio wait for you until you actually need it. Is this feasible for you?

If the calculation of the merrit function is parallel for every variable (and I have quite a lot) I do not understand why it is calculating in optimization so much time on a single core. The below example is with a reduced merit funktion. Every Cycle the full power is used for about 10 seconds and than it is running on a single core for about 30-40 sec. With the original MF I shared these gaps are stretched to about 5 minutes.

Actually, I don't think that is slow at all: it's very fast in fact. You are trying to find the minimum value of a 176-dimensional space, where each evaluation needs 101,117 separate calculations. The multi-threaded part is the merit function evaluations (all 177 of them) and the single-threaded part of the cycle is the search in 176-dimensions for the lowest value. You're getting one cycle a minute, which I think is seriously good.

I totally get what you're thinking, and you're not being dumb. But not everything can be parallelized. We parallelize what can be done, but the rest has to be done in series. In local optimization we parallelize the n+1 evaluations of the merit function (n is the number of variables, 176 in your case). This gives us the value of the merit function at it's current location in solution space, and its gradient in 176 dimensions. Then we have to find the minimum value in that space...

But the bottom line is, nothing is wrong in your system or particularly capable of improvement on Zemax' end. You're just asking it to do a very big calculation, and it takes time. I hate to pull the 'when I was your age...' stuff, but I can remember when optimizing doublets, triplets etc could take hours, and zoom lens designs took days to weeks.

The best thing I can suggest is to simplify the problem as much as possible, or to take in in a stepwise manner rather than putting everything in at once. Other than that, I think you just have to set the calculation going and leave it to cook.

So far I have put two rectangular volumes to create the cavity and played around with the coatings for Front/Rear faces but the result is that all wavelengths get through. So the physics of resonance is not happening. Im doing something wrong

It should work with coatings in non-sequential mode. When you run your raytrace, you have to tick 'Use Polarization'. I have attached an example. I converted the file '\Zemax\Samples\Sequential\Polarization\Fabry-Perot.ZMX' to non-sequential.

So in general it doesnot react to any change. As you know, a Fabry-Perot filters wavelength by fine-tuning the distance between mirrors, and in the zemax sample files the distance between the two plates is zero. that is the point I dont see. Ideally , I would like to simulate in OS something like this web simulator:

So this coating is made of a thin .004 wavelength layer of aluminum, a 150 wave thickness of air, and another thin layer of aluminum. The FP is therefore comprised of two pieces of glass in the editor, with Al/Air/Al sandwiched between. In order to tune the etalon, change the thickness of the air.

The only limitation to the FP modeling is that the thickness of the layers does not draw on the layout plots. That's in common with the whole coating capability. Other than that, it will react to wavelength and angle changes just fine: as long as 'Use Polarization' is turned on so that coating effects are considered.

Sandrine, I think the issue with Coherent Irradiance isn't the FP: it's the paraxial lens model in the NS mode. It doesn't consider phase at all. Replace the paraxial lens with a real imaging system and it will work fine in Coherent as well as Incoherent modes.

- In your FP 'sandwhich', ALUM is defined before as a material (MATE) with = 0.55 0.7 -7.0 . So my next question is, where is the reflectivity of this aluminum defined?. The reflectivy defines then the Finesse and in general the performance of the FabryPerot experiment

The reflectivity is computed from the complex index of the coating layers, the number of coatings, their thickness etc. The reflectivity is a function of the whole stack. If you want to see the reflectivity of the Al layer, put it on a flat piece of glass and use Analysis...Reflectivity.

- There must be something that stays in memory so that Detector Viewers show incorrect signal. If I try to recover the default rings at 0,55 um , it shows something different. The same happens when I change to different wavelengths.

You only need one FP coating on the 2nd window. This is because in non-sequential, we have a rule called the nesting rule that says :

'If a ray strikes more than one object at the exact same point in space; the last object listed in the NSC Editor determines the properties of the surface or volume at that point.'

I managed to create the FP behavior of a coverslip just by using an AIR rectangular volume and use the specs of the slip (in this case 250 micron of silica) as coating of the that AIR rectangular volume. Note that the rectangular volume does not affect the ray tracing, it is just a holder.

I am in the process of modeling a FP etalon system and I have used both sequential and non-sequential modes implementing the etalon as a coating based on the zemax example file and as described above The results for this idealized case seem reasonable.

A useful simulation tool for my problem would be an opto-mechanical model where I can see the effect of tilt and stress on the etalon plates. I have tried to follow the approach above from Javier using an 80% reflective coating on each of the air spaced etalon plates but this does not seem to be working. Perhaps it is just not possible to trace enough rays. If this approach did work, I could tilt one of the plates , add curvature or a TIRR or Zernike sag surface to represent deformation to study these effects and develop an error budget for my system.

In the past, I have used Solidworks simulation and Sigfit to combine opto-mechanical effects from FEA results into my Zemax model. Are there any tricks you can recommend to develop an etalon model that would lend itself to this type of analysis? Can tilt or irregularity be introduced in the coating to simulate these effects?