Update_model throws error with .SEQ import of aspheric

[ebflagg]

After constructing an optical system, I was trying to vary the image distance and plot the spot diagram. But after just a few iterations of varying the distance and calling update_model() on the OpticalModel, it threw an error. After further investigation, I found that just calling update_model() more than 5 times without even changing anything threw the same error. I made a minimum reproducible example to demonstrate the problem.

Results: The error happens within EvenPolynomial.sag, which sounds like it has to do with the aspheric properties of the lens. I couldn't reproduce the problem with just a single achromatic doublet lens. But it is reproducible with the single aspheric lens imported here.

I tried running update_model() multiple times on the 'Cell Phone lens' notebook from here, which contains a lot of aspheric surfaces. However, it did not throw the same error (although that notebook must be written for an older version of rayoptics than I have (0.9.2) because it threw other errors). That implies that maybe something is wrong with the OpticalModel produced by importing the .seq file from Edmund Optics. But I don't know enough to figure out what that might be.

The question is whether the problem is just in the .seq file I imported, or whether there is something deeper wrong within update_model() or EvenPolynomial.sag.

[mjhoptics]

Hello @ebflagg,
Thank you for the detailed writeup of the problem you encountered. I was able to reproduce and fix the issue. The gist of the problem was the CODEV import for even polynomial aspheres had a bad case of software rot. I originally wrote the ashpers to have separate attributes for each coefficient. This lines up with CODE V's syntax. But it's unwieldy when there are lots of coefficients and so the code transitioned to use a list of coefficients. All of the other importers as well as the __init__ function are written in terms of a coefficient list, coefs. For CODE V imported models, the attributes and coefs could get out of sync, and worse, the coefs could get wiped out. If the model was saved as a .roa file and restored, the attributes were restored but never copied into coefs, breaking the model.
The commit aa980fb addresses the problems above as well as the behavior you reported. Your comment regarding not seeing the problem with the cell phone model is interesting as that model was created directly as a rayoptics script using only coefs, and would not have encountered this attribute problem.
I hope to put a version 0.9.5 out in a few days.
Thanks,
Mike

[mjhoptics]

Fixed in v0.9.5