Skip to main content

During optimizations, it would be useful to see how much the Merit Function value is changing as a function of time and the number of Systems evaluated.  When I run Hammer Optimizations, it’s a bit of a guess about when I can stop the optimization to evaluate the result.  Understanding how the merit function is changing over time would help me to understand when most of the merit function gains are being achieved and when a reasonable time to stop it is. 

Hi Mike,

Thank you so much for your suggestion! I will submit a feature request on your behalf.

As a workaround, you will need to use programming way to do the task since one cannot save the merit function value during the optimization.

By programming one can mimic the manual operation, for example, run a cycle of optimization and stop to check the current MF value, and continue to get MF values.

The simplest programming way is by using Zemax Programming language.    

You may refer to the following KB article for an introduction to ZPL :  

ZPL – Knowledgebase (zemax.com)

To check what kind of Keywords can be used, please go to the following chapter in helpfile:

The Programming Tab > About the ZPL > KEYWORDS (about the zpl)

To run optimize, keyword OPTIMIZE is needed.

And use numeric function MFCN() can extract the current MF value.

A full list of available numeric function can be found from the following chapter in helpfile:

The Programming Tab > About the ZPL > Numeric Functions

If you would like, you can make the interval MF values stored in an array, and then use PLOT keywords to draw a graph.

How to use the PLOT keyword in ZPL – Knowledgebase (zemax.com)


Hey Yuan,

This really needs to get bumped up and implemented directly in OpticStudio.  LightTools directly offers this visualization (as well as the ability to “rewind” to a previous version) and CodeV’s optimization has a DER (derivative) user input so a user can “pick up where they left off” from a previous optimization.  Zemax’s competitors have put a lot of effort into not just their optimization algorithms, but their optimization workflow and it shows.  It would be nice if Zemax could put in similar effort.

As for the proposed solution, not only is the ZOS-API (and ZPL) going to be way slower, it will also produce divergent results from the built-in local optimization.

Since OpticStudio does not allow the user to define the step size (derivative) of each variable, running 10 one-step optimizations will not produce the same result as running 1 ten-step optimizations.  Once you stop an optimization cycle (i.e., to read the current MF value in the ZOS-API), then restarting the optimization will use default hard-coded initial step sizes, not the last step size from the previous optimization step.  

So, from a ZOS-API standpoint, OpticStudio should do one of the following:

  • provide an option to save the current “step size” for all the variables to a text file.  Then, if through the ZOS-API, a user passes in a valid “step size” file, the optimizer will use these values for the initial guess and then continue the optimization like normal.  If the user doesn’t provide a “step size” file, then the optimizer’s behavior won’t change.
    • this is probably the easiest to implement.  The “step size” file should have the following information (one row per variable, 5 columns per row):
      • variable editor, variable row, variable cell, variable step size
    • if there is a row in the “step size” file that isn’t a current variable (i.e., the user messed up and entered the wrong file name), then OpticStudio will simply ignore this value
    • if there is a variable defined in an editor but is not present in the “step size” file, then the current method of determining the step size should be used
  • allow a “pause” method on the Optimization tools so a user can query the IOpticalSystem
    • this can be more logical for new optical designers over derivative step size files
    • this is the better choice vs simply reporting the MFCN value because as a programmer I might want to be able to save a system based on specific values of the LDE 

If Zemax puts some effort into the optimization workflow, you will have thousands of happy customers; besides a Layout, optimization is something that almost all your customers do.


Please add my vote to this!


Hey Yuan,

This really needs to get bumped up and implemented directly in OpticStudio.  LightTools directly offers this visualization (as well as the ability to “rewind” to a previous version) and CodeV’s optimization has a DER (derivative) user input so a user can “pick up where they left off” from a previous optimization.  Zemax’s competitors have put a lot of effort into not just their optimization algorithms, but their optimization workflow and it shows.  It would be nice if Zemax could put in similar effort.

As for the proposed solution, not only is the ZOS-API (and ZPL) going to be way slower, it will also produce divergent results from the built-in local optimization.

Since OpticStudio does not allow the user to define the step size (derivative) of each variable, running 10 one-step optimizations will not produce the same result as running 1 ten-step optimizations.  Once you stop an optimization cycle (i.e., to read the current MF value in the ZOS-API), then restarting the optimization will use default hard-coded initial step sizes, not the last step size from the previous optimization step.  

So, from a ZOS-API standpoint, OpticStudio should do one of the following:

  • provide an option to save the current “step size” for all the variables to a text file.  Then, if through the ZOS-API, a user passes in a valid “step size” file, the optimizer will use these values for the initial guess and then continue the optimization like normal.  If the user doesn’t provide a “step size” file, then the optimizer’s behavior won’t change.
    • this is probably the easiest to implement.  The “step size” file should have the following information (one row per variable, 5 columns per row):
      • variable editor, variable row, variable cell, variable step size
    • if there is a row in the “step size” file that isn’t a current variable (i.e., the user messed up and entered the wrong file name), then OpticStudio will simply ignore this value
    • if there is a variable defined in an editor but is not present in the “step size” file, then the current method of determining the step size should be used
  • allow a “pause” method on the Optimization tools so a user can query the IOpticalSystem
    • this can be more logical for new optical designers over derivative step size files
    • this is the better choice vs simply reporting the MFCN value because as a programmer I might want to be able to save a system based on specific values of the LDE 

If Zemax puts some effort into the optimization workflow, you will have thousands of happy customers; besides a Layout, optimization is something that almost all your customers do.

Thank you so much Michael!!!!! 

 


Please add my vote to this!

Hi David, many thanks for your vote!


Reply