UI unbearable slow


  • Infrared
  • 7 replies

I am using a sequential Zemax file with 22 configurations and therefore a huge Merit function.

I am using a Workstation with a 20core (physical, 40core virtual) CPU which is used at 1-3%

Only a few percent of the 160GB RAM are used.

Every action in the UI is mindbogglingly slow. Changing a single value in the Merit function needs about 10 seconds.


I have change everything mentioned here:

https://my.zemax.com/en-US/Knowledge-Base/kb-article/?ka=KA-01332

But it does not help.


 


10 replies

Userlevel 3
Badge

What type of MF do you use? Can you check if it will be the same with only Spot or WFE operands (default MF)? 


 


Some operands can calculate quite long. It looks that you use some of them that use only one core. 

Userlevel 5
Badge +1

Hi Steffen,


To echo Andrey, what is defined in the Merit Function Editor can certainly contribute to the slowness in execution of any operation in OpticStudio.


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.


Please let us know how these thoughts work out for you, and thanks for your time!


~ Angel

I experience this, but I do not understand why is that?


A huge MF should not need any calculation time until it is calculated, and there is no need to calculate while I change anythings in the editors because I switched updates off.


Are there MF operands not only using one core?


I am using a lot of REAX,REAY, REAA and REAB to control Pupil positions and intermediate image size. Are there quicker operands?


It is really a pain in the rear end, that the MF is not able to make a benefit of more than one core, especially if You have 40.  :(


Best


Steffen


 


 

I have slimmed down the MF and it speed ab significant.


I mainly skipped a lot of lines to control a Binary1 I am not using at the moment but I will soon.


There I control that the coefficients are not exceeding some Boarders.


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.


No higher mathematics involved. Can this drag down the speed so much?

Userlevel 7
Badge +3

Hey Steffen,


How long does your MF take to recalculate? If you just update it by hand, roughly how long does it take?


One solution to your problem is to save your merit function, clear the editor and only load the MF when you are going to optimize the lens. Use the Save and Load icons on the MFE:



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 support@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.


Hope that helps,


- Mark

Userlevel 4
Badge +1

Hi Steffen,


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?


Best,


Kevin Scales

Hi Mark,


the update of the merrit functions takes I would say two seconds. (one second with the reduced version).


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.



Yes I am very frustrated about the geolical timescale the optimization takes...


Best


Steffen

Userlevel 7
Badge +3

Hey Steffen,


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.


You're just doing a really big calculation, that's all. As Kevin says, if you really need all those variables and all those calculations, it just takes time to chunk through it all.


- Mark

Hey Mark,


Thanks for Your expertise!


The Computer is using 75% of the time only one of its 40 cores.So as dumb user I think it could be 4times faster if it would use all of them... :)


But this was the slimmed down MF, with skipped all calculations not necessary at the moment.


With the original MF in the same System one cycle takes about 5min. (95% of the time on one core).


But still 176 dimensions to search in. Can the search be slowed down by the merit funktion? All the calculations should be done then.


Best


Steffen

Userlevel 7
Badge +3

The Computer is using 75% of the time only one of its 40 cores.So as dumb user I think it could be 4times faster if it would use all of them... :)


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. 


 

Reply