In most cases, we want to optimize for best performance over some average of the field of view or wavelength range of a system. In some cases, its useful to optimize only the worse-case scenario.

For example, the default merit function tool will create a merit function which minimizes spot size, wavefront error, angular radius etc as an RMS average over the defined field of view. But what if your specification states that the MTF should never be worse than say 50% at 30 cycles/mm at any point in the field of view?

Here's an example. The file you can download from the last page of this article is a derivative of the double Gauss sample file that is distributed in the samples folder with ZEMAX. It's an f/3 photographic objective, optimized across the visible wavelength range and across a 28 degree field of view. The default RMS wavefront error merit function was used, with reasonable boundary conditions of glass and air thicknesses.



The MTF looks fine:



But, our customer requires the MTF at 30 cycles/mm to be greater than 50% everywhere in the field. Open Analysis...MTF...FFT MTF versus Field, and set it to showe the response at 30 cycles/mm:



The horizontal line at 50% MTF was drawn in by hand using Window...Annotate...Line, and it shows that we are outside of our customer's specification. How do we put this 'minimum MTF across the field' requirement into the merit function?

The MINN optimization operand looks at a range of optimization operands in the merit function and reports the minimum value. MINN is one of a range of 'operational' operands which are used to perform operations on the return value of other operands. Consider these three operands in the merit function:

1. MTFA(field = 1, frequency = 30 cycles/mm, weight = 0)
2. MTFA(field = 2, frequency = 30 cycles/mm, weight = 0)
3. MTFA(field = 3, frequency = 30 cycles/mm, weight = 0)

These operands compute the average of the S and T MTF at the stated field, and for the stated spatial frequency. Because the weight of each operand is zero, the operands do not contribute to the merit function, and so do not affect optimization. But this operand:

4. MINN(starting_operand = 1, ending operand =3, target = .5, weight =1)

will look at all operands starting from operand 1, and ending at operand 3, and return the minimum value reported in that range. We then target that minimum value to have a value of 0.5. So we compute the MTF at three field points, and target only the worst to have a value of 0.5. Neat!

Even better, we could use this:

4. MINN(starting_operand = 1, ending operand =3, target = .5, weight = 0)
5. OPGT (operand = 4, target = 0.5, weight = 1)

Operand 4 computes the worst-case MTF, but as the weight of this operand is now set to zero, it does not affect optimization. The OPGT operand however picks up this value, and requires it to be greater than 0.5. As long as the worst-case MTFA is greater than 50%, there is no contribution to the merit function, but if the worst-case MTFA is below 50% the design will be optimized to increase it.

This is an excellent, and easy, way to enforce design specifications in which a minimum performance requirement is specified, but as long as the minimum is achieved we do not care what the actual value is. The same approach can be used with tolerancing, in which performance can be set to degrade within a defined level and still be acceptable, but the lens can be rejected if peformance falls below some threshold.

Although our example here uses MTF, any operands can be operated on in this fashion: wavefront, spot, physical optics, non-sequential etc. This is the beauty of operational operands. The following operands are available:



See the User's Guide, Chapter 14 ("Optimization") for full details. See also the sections of that chapter 'Understanding Boundary Operands' and 'Defining Complex Operands' for a thorough discussion.

The file 'Double Gauss minimum MTF.zmx", which you can download from the last page of this article, shows our double Gauss file with an updated merit function. In addition to the default wavefront merit function, it contains multiple MTF operands to compute the MTF across the field of view, and then the MINN/OPGT structure discussed on the previous page.

One way to sample the MTF versus field is just to define multiple field points across the field of view in the Field dialog box (System...Field). This limits us to 12 field points however, and may not be helpful if multiple field points are already needed, or when tolerancing. A more elegant approach is to use the FDMO operand to re-define the field of view of a given field point 'on the fly':



In this case we use the FDMO operand to re-define the hy value of field point 2 from 0 to 1 in steps of 0.1, and we compute the MTFS and MTFT at 30 cycles/mm at each value of hy. The MTF* operands have zero weight, so they do not affect the optimization. Then:



Line 40 gets the minimum value of all the merit function lines between operands 7 and 38, and line 42 requires this value to be greater than 55%. Why 55%, when the customer's specification is 50%? Because we have not yet toleranced the design, and so we need to budget some extra performance to allow for the degradation that manufacturing tolernaces will cause. After optimizing with this new merit function we go from the original MTF vs field curve:



to this curve:



So we have computed the lowest value on the MTF vs field plot, and optimized this value to be >50%

It is easy to optimize for 'worse case' performance. Simply compute the required parameter at multiple values of field (or whatever parameter is of interest) and use MINN to compute the minimum value over the range, and OPGT to force a minimum threshold of performance.