Hi Rob,

I had the issue a couple of times. For me, it can happen when I start optimizing lots of terms on multiple aspheric surfaces.

In your case, I only see two variables, which I had thought would be fine.

Any chance you can share this file here? Or perhaps a simplified example that demonstrates the issue.

Good luck, and take care,

David

The merit function should never increase during optimization, so this is clearly not correct operation.

That said, hammer should not be needed for a two-variable system. Can you post your file here, as an archive (ZAR) file so we can see what is happening? I can see you have a POPD operand in the MF at line 15 that is returning a value of zero, and that's where I'd look first. The optimizer might be looking an a design variant where the POP calculation fails. It should back itself out of that case without problems though.

For a two-system file, I'd suggest using the Standard DLS optimizer, or maybe the Orthogonal Descent optimizer

Hello both, thanks for the replies.   2 variables is certainly somehting you would expect Zemax to optimise with the standard optimizer.   But, from my experiments Zemax just isn't able to do a good job of optimising using POPD.  It isn't because the POP is failing it just doesn't itterate downwards.   POPD is slow, sure andI have left it for considereable lengths of time without sucess.

If I switch to a wavefront or spot size merit, optimise lens curavtures,  and then switch back to tweak distances then I always get a better result.

Unfortunetelly I don't have time to investigate futher.

thanks again for your replies.

Hey Rob,

That's the process I would advise. Use a ray-based merit function from the Optimization wizard to generate the basic shape of your system, and then use POPD for a final refining pass. I'd certainly not want to start a design from plane-parallel-plates and only use POPD.

That said, the behavior you reported initially is a bug, but support will need a sample file to see exactly where and what it is. 

Hi Mark, support have a file from last year and were able to recreate the problem so hopefully a fix is in the pipeline.

I'm happy with the ray approach - it works and works well - but I wonder why POPD fails for such a simple system - I only have 2 radii to change, and I'm starting from a nearly optmised state.   Maybe POPD is at fault rather than the optimisation.  Hopefully we'll get an answer soon.

regards

Rob

I can help with that :-)

There are problems with optimizing with POPD from a poor starting point. The optimization can stagnate, which means that the optimizer cannot compute a change vector: every change makes the MF larger. The design may have to get worse in performance terms before it can get better (you are trapped in a local minimum) and a single target in the merit function (POPD) in this case) generates only a single difference.

In contrast, the ray-based methods that the Optimization Wizard uses can generate hundreds of targets in the merit function and each one peforms continuously with perturbation. It's actually a huge achievement to have a merit function that works from a completely-out-of-focus design to diffraction limited without modification! The key is that you have many targets (operands) and so can compute the change vector better.

There's also a more prosaic reason. Physical Optics typically generates small changes compared to the ray calculations: the focal point may shift by 10s to 100s of microns say over whatever the EFL of the lens is. Using POPD to iterate from the ray-based solution to the POP based solution is much faster than using POP to compute the entire history of the lens from initial setup to final design.

So bottom line: always use the ray-based default merit functions from the Optimization Wizard until you have a system that is near to the diffraction limit, or is diffraction limited. Then use POP to identify the beam waist minima/other POPD data rather than the ray-based minima.