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….

Hi John and David

I agree with David that we don’t have a tool to vary the STOP surface, but I will send your comment to our developers working on optimization. That is interesting.

Sandrine

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. 

Hi Rick,

That’s not really a ‘trick’ though, is it? The entrance pupil is the image of the stop, so letting it fly backwards (or forwards I guess) is a good way to guess the stop location, no? You clearly need to follow up with a real stop surface and ray aiming, but as a way of identifying an approximate location for the stop it’s fine, isn’t it?

I’d be interested in what the other codes do in this regard. The Implied Stop in Synopsis is very like this, I have been told. But I don’t know.

• Mark

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

Hi Mark,

Yes, I use that method to find the rough stop location, then I finish with a real stop, as usual. 

From Synopsys website: “Not sure where the stop should go? SYNOPSYS™ lets you vary an implied stop position during optimization. One variable, no dummy surface needed.”

I think what they’re doing is varying the object space chief ray angle. That way there’s no need to pre-define a stop surface. Wherever the chief ray crosses the axis is where the stop ends up.

Best,

Rick 

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

Or maybe they’re varying the chief ray intercept height at the first surface after the object. In any case, whatever they’re doing seemed to work.