Summary
In previous design notes, we described the GENII “expert designer” error function and the default quadrature-based error function used in OSLO. Both of these functions have been successful in the design of thousands of optical systems over a period of many years. But if you need to design the best possible system, it is unlikely that any default error function will do the job. You need to modify the default error function, or perhaps even develop your own function customized to the job at hand.
The success of an optical design program for serious optical design is closely coupled to the facilities that it provides for user-defined error functions. The program should allow error functions based on system and paraxial data, aberration coefficients, ray displacements, spotsizes, optical path differences, MTF data, even user-computed data. Error functions should allow data computed at any surface, wavelength, or zoom configuration. User-defined error functions must be both easy to set up and efficiently computed. OSLO provides innovative and elegant solutions to meet these requirements. To see how they work, please visit our web site.
Discussion
The most important aspect of optimization is the error function, which determines the single number that controls whether one system is better than another. Although predefined default error functions are useful for basic optimization tasks, most successful designs require that the error function be tailored to the particular task at hand. This requirement does not mean that user-defined error functions need to be set up by expert lens designers. Most applications of user-defined error functions are simply to set up some basic constraints that a design must satisfy, such as correct paraxial properties, acceptable ranges of aberrations or ray displacements, etc.
Different optical design programs use quite different approaches to setting up error functions. Historically, the early optical design programs separated into two groups. On one hand were programs that contained extensively pre-programmed error functions with a minimum of user control. On the other hand were programs that provided no default error functions, requiring the user to define everything. Each approach had its own merits. The first was easier to program, because it had a fixed evaluation sequence. Moreover, the programmer could use his knowledge of lens design to create a sensible function for its intended range of applications. The second approach was much more flexible, but required sophisticated programming to provide efficient evaluation. Now, most programs include both features, but its original heritage gives each program a distinct personality.
OSLO follows the second approach. In OSLO, the term operands denotes the terms in the error function; that is, the error function is the weighted sum of squares of the operands. Each operand consists of one or two components linked by either a mathematical (+, -, *, /, **) or relational (<, >) operator. Operands are expressions rather than commands.
OSLO provides its default error functions as operands generators, i.e. built-in routines that automatically generate the same input commands that a user would provide to set up an error function. This makes it easy for the user to understand and modify a default error function, but it requires sophisticated data handling within the program to achieve fast computation times. OSLO solves this problem by providing an operands compiler that converts user-defined operands into an internal form that can be evaluated very quickly.
Using two-component operands, it is possible to build operands that effectively consist of more than two components. You just define an operand component whose value is that of another operand. In addition, the two-component form allows all operands to have zero targets. If a non-zero target is desired, you set up an operand where the first component is the operand and the second component is minus the target value of the operand. OSLO has several types of operand components.
When an operand definition is entered in OSLO, it is immediately compiled into an internal representation. The definition echoed on the display is a reconstructed version of the operand definition, which reflects how the entered operand was compiled by the program. The displayed version uses the most efficient syntax, which may not be the syntax that was used in entering the definition.
The syntax of operand components varies according to the type of operand component. With the exceptions of cross-reference and constant components, each component can take one or more integer arguments that specify such quantities as ray number (index into the ray set), wavelength number (index into the wavelengths set), surface number, configuration number, etc. Many of these arguments have default values that need not be entered explicitly by the user; indeed, any default arguments at the end of the argument list for a given component will not be displayed by OSLO even if the user enters them explicitly. A good understanding of the role of arguments in defining operand components can be gained from ray components.
Because of the wide range of design tasks that can be completed using user-defined error functions, an efficient and easily understood implementation of this feature is one of the most important aspects of any optical design program. In the case of OSLO, user-defined error functions constitute the core of the optimization section, reflecting the importance that its developers have attached to this feature.