Thanks for your input David. I’m also interested to hear what others have to say. I’ve been investigating Synopsys OSD software and they have a very elegant ‘implied stop’ option that doesn’t require a dedicated surface and can be easily varied as part of the optimization. Maybe Zemax can take some notes….

This is a good question.  I hope that Zemax can add this capability (please note that Synopsys has had this ability for years). 

The only workaround I’m aware of is the “negative dummy surface trick” as I call it.  Make the first surface the stop. Then add a dummy surface before the stop. Make the thickness variable. Pickup the stop surface thickness from the dummy surface, with a factor of -1.  Now the stop can move around but the total thickness of those two surfaces stays constant. Add reasonable constraints on the thickness to the merit function so it doesn’t blow up. 

This trick isn’t perfect, but it works reasonably well when there’s no pupil aberration.  If you have, for example, a fisheye with lots of pupil aberration, then I would not put the dummy and stop at the front of the lens. Since most of the pupil aberration comes from the first few elements, put the dummy and stop surfaces after the first few elements. 

Again, this trick isn’t perfect and may not always work.  I use it to find good forms, but I would not use it to come up with finished designs, because there may still be some pupil aberration. Hence the last step: 

IMPORTANT: after you find a design form you like, and you know where the stop needs to go, then remove the dummy surface and pickup, put the stop on the appropriate surface as usual, and then reoptimize. 

When working with systems that don’t fit the mold of a standard analysis, I use the API.

I tend to move the STOP around using the API and explore each of these as independent cases.  In this way, I can keep track of parameters that may be vary disparate such as:  relative illumination, vignetting, size/volume of parameters.

What I truly find a challenge is the interface between the ZOS-API and Python.  While I am primarily a Matlab user, I can’t afford all the Toolboxes that I might be able to use (including the Optimization Toolbox).  So, it’d be nice to connect ZOS-API to standard Anaconda/Python.  However, there are some problems with this that make it cumbersome, including limitations in the version(s) of Python that are supported.

-B

I think you can implement that with the ZOS-API in a relatively straightforward manner.

At the moment, I’m using the ZOS-API to map out the entrance / exit pupil for highly vignetted systems.  In these systems, one needs to ignore the paraxial magnification of pupils and find out for yourself where the rays land.

There’s little to prevent you from picking any arbitrary plane for a STOP and then tracing forward / backward to find the exit pupil and performance yourself.

I’ve also been playing with multiple models that simultaneously model different aspects of the same system.  The ZOS-API allows you to hold several systems in memory at once.  You can feed results back and forth between the models to further your understanding without having to sequentially load multiple systems into memory.

-B