Optical designs are usually driven by a list of requirements: first-order properties such as focal length and F-number, field of view, image quality targets such as MTF and spot size, detector and sampling constraints, and packaging limits. In many workflows these requirements live outside the optical model, in spreadsheets or specification documents, or are recreated indirectly through custom merit function calculations. The Requirements Editor in Ansys Zemax OpticStudio provides a structured way to record these requirements directly with the design, compare them against the current system, and export related operands to the Merit Function Editor for optimization.
This article introduces the Requirements Editor and walks through a practical example: defining and checking requirements for a comet-hunting telescope with an off-the-shelf CMOS sensor.
Authored by Fehim Taha Bagci and Flurin Herren
Introduction
Every optical design answers to a specification. During a project, the same questions come up again and again: does the design still meet the focal length target after that last optimization run? Is the spot small enough for the sensor pixels? Does the assembly still fit in its envelope? Answering these questions usually means jumping between analysis windows, a spreadsheet, and the original specification document, and it is easy for the model and the specification to drift apart.
The Requirements Editor keeps the specification inside the design file. Each requirement is a single row: a design parameter, a target defined either as a nominal value with a tolerance or as a range, the value the current design actually achieves, and a pass/fail status shown as a green check or a red X. One glance at the status column tells you where the design stands against its full specification. Requirements can cover first-order properties, field of view, image quality, detector geometry, sampling, packaging, environment, and user-defined items that OpticStudio does not calculate, such as weight or cost.
The editor is opened from Setup > Editors > Requirements Editor. Requirements are saved automatically in a .ZRQ file with the same name and in the same folder as the .ZMX design file, so MyLensDesign.ZMX gets a MyLensDesign.ZRQ. Because the requirement set lives in its own file, it can be imported into another design with the Import Requirements button, which is convenient when comparing candidate designs against the same specification. And when it is time to optimize, the Generate Merit Function button exports operands for the requirement parameters to the Merit Function Editor as a starting point.
The rest of this article shows how this works in practice, using a comet-hunting telescope.
Example: Requirements Tracking for a Comet-Hunting Telescope
Our example is a backyard comet-hunting telescope. The instrument is built around an off-the-shelf full-frame CMOS camera (QHYCCD QHY600 Photographic Color Camera) with the specifications listed below, and the mission calls for a 45 arcminute (0.75 degree) field of view so that a comet and a useful amount of surrounding star field fit in a single exposure. Because this is an amateur instrument, the packaging requirements are refreshingly concrete: the assembled telescope must fit through the lab doorframe (890 mm maximum width) where it is going to be assembled, stay under 890 mm in length so it remains manageable, and weigh no more than 34 kg so two people can lift it.
The optical design itself is already finished and optimized. Our task here is not to design the telescope but to capture its specification in the Requirements Editor and verify that the design meets it. The table below is the baseline specification we will enter, derived from the mission requirements and the sensor datasheet.
| Requirement | Value | Source |
| Full field of view | 45 arcminutes (0.75 degrees) | Mission requirement |
| Effective focal length | 3305.14 mm | Derived from field of view and detector size |
| Entrance pupil diameter | 268.146 mm | Light-collecting aperture for faint comets |
| Detector width X x Y | 36 mm x 24 mm | Sensor datasheet |
| Number of pixels X x Y | 9576 x 6388 | Sensor datasheet |
| Pixel width | approximately 3.76 µm | Calculated from detector width and pixel count |
| Detector angle in object space X, Y | 0.156 degrees, 0.104 degrees | Detector footprint on the sky |
| PSF FWHM on the image | approximately 15 µm | Seeing-limited resolution target |
| Sampling (PSF FWHM / pixel width) | approximately 4 pixels | Adequate sampling of the PSF |
| Bounding box length Z | less than 890 mm | Fit through a lab doorframe |
| Weight | less than 34 kg | Two-person lift (user-defined) |
Open the comet-hunting telescope .ZMX file, then open the editor from Setup > Editors > Requirements Editor.
Enter the Detector Data
Several of our requirements involve the sensor: detector width, pixel count, pixel pitch, the footprint of the detector on the sky, and sampling. These all draw on the detector definition in System Explorer > Detector, so enter that data first: detector width X = 36 mm, detector width Y = 24 mm, number of pixels X = 9576, and number of pixels Y = 6388. The detector is assumed to sit at the image surface, and the pixel pitch is calculated automatically from the width and pixel count.
Add the Requirements
Click Add Requirements to open the Add a New Requirement window. Pick a design parameter from the dropdown, and the current value from the open design is displayed for reference; then enter the target as either a nominal value with a tolerance or as a range, choose the units, and optionally add a comment. It is worth using the comment field consistently to record where each requirement comes from, such as “sensor datasheet” or “mission requirement”, since that context is exactly what tends to get lost between the specification document and the model.
Working down the baseline table, add the requirements in natural groups:
- First order: effective focal length of 3305.14 mm and the entrance pupil diameter of 268.146 mm, each as a nominal value with a sensible tolerance.
- Field of view: a full field of view of 0.75 degrees. Angular requirements can be entered directly in degrees or arcminutes.
- Detector: detector width in X and Y, number of pixels in X and Y, pixel width, and the detector angle in object space in X and Y. The current values for these come from the Detector data entered above, so this step doubles as a check that the sensor was defined correctly.
- Performance and sampling: PSF FWHM in X and Y with a target of roughly 15 µm, and PSF FWHM divided by pixel width in X and Y with a target of roughly 4, confirming the point spread function is spread over about four pixels and the sensor adequately samples the image.
- Packaging: bounding box sizes in X, Y and Z of less than 890 mm, entered as ranges. The bounding box encloses all surfaces from surface 1 through the image surface.
- User-defined: the 34 kg weight limit. OpticStudio does not calculate weight, but a User Defined requirement keeps it visible in the same list, with a comment recording the reason.
As each requirement is added, the Status column immediately shows whether the current design satisfies it. With an optimized design and a specification the design was built to meet, the result should be a column of green checks, which is itself a useful record: the design demonstrably meets its specification, and the evidence is stored with the file.
Break a Requirement on Purpose
The real value of the Requirements Editor appears when the design changes. To see this, deliberately break one of the packaging requirements. In the Lens Data Editor, increase the spacing between the primary and secondary mirror by only 1 mm, as might happen during a re-optimization or a mechanical accommodation. Back in the Requirements Editor, click Re-evaluate All Requirements to recalculate the current values. As it can be noticed, status of many requirements flips from a green check to a red X, while unrelated requirements stay green. Nothing about this change would look alarming in a layout plot, but the requirement list catches it instantly.
This is the intended working rhythm: modify the design, click Re-evaluate All Requirements, and scan the Status column. Any red X points directly at the requirement that needs attention, whether the fix is a design change or a negotiated change to the requirement itself. When you are done experimenting, restore the original spacing and re-evaluate to confirm everything returns to green.
Generate a Merit Function
If a requirement fails and the fix is a design change, the requirement list can feed the optimization. Click Generate Merit Function and OpticStudio exports operands for the requirement parameters to the Merit Function Editor. The generated operands report the current system values; the inequalities and limits from the requirements are not converted into constraints automatically, so add constraint operands such as CONS, OPLT, OPGT, MINN, or MAXX to suit your optimization. For example, for a requirement of 0.8 < MTF < 1, the generated merit function includes MTF operands at each field point together with a MINN operand that retrieves the lowest value, and adding an OPGT on the MINN result enforces that the minimum MTF stays above 0.8 during optimization.
For our telescope, generating the merit function after the spacing change produces operands for the bounding box, PSF FWHM, sampling, and first-order requirements, giving a ready-made scaffold for pulling the design back inside its envelope while protecting image quality.
Conclusion
The Requirements Editor turns the design specification from an external document into a live part of the optical model. For the comet-hunting telescope, the full specification, from focal length to doorframe clearance, sits in one table alongside the values the design actually achieves, and a single click re-checks every requirement after any change. The .ZRQ file travels with the design, can be imported into candidate designs for a fair comparison against the same specification, and its data is available to the API for reporting workflows. When a requirement fails, Generate Merit Function bridges directly into optimization. The result is a simple habit with a large payoff: the design and its specification can no longer quietly drift apart.
References
- Ansys Zemax OpticStudio Help File Page: Requirements Editor