FreeForm + GridData Not working

[lmarchen]

Dave,

I have done many tests on Windows, Linux (s383), and on my other Linux computer. GMI and mmacos fail to reproduce results produced by command-line MACOS. I have been using the MACOS Rx in ../GMI/test_fff: ff_pie.in and iris_dp_ZGD.in. If you try a very simple test with both GMI and mmacos:

1. compile on Linux (s383)
2. use iris_dp_ZGD.in make sure that the parameters lMon and GridSrfdx are correctly defined first, lMon= 70mm and GridSrfdx= lMon*2/(nGridMat-1)
3. You also have zern41em5z155em3.txt, make sure that Segment 1 (iElt 17 and iElt=35) set GridFile= zern41em5z155em3.txt.
4. set GridFile= Flat.txt for the other segments, we only want to see GridData on Segment 1
5. then simply compute OPD at ExitPupil with GMI, mmacos, and command-line MACOS.
6. what I see from this is that GridFile does not have any effect on the grid of Segment 1 for GMI and mmacos, you can increase the magnitude of GridData but you will not see any change for GMI, while for mmacos there seems to be a problem with how the grid is set up on the surface of FreeForm.

I think that more detailed work needs to be done on mmacos and GMI. By the way I ran the test above with pyMACOS and the results match the results of command-line MACOS for the same test. I still have plenty of tests to run with pyMACOS but so far this is encouraging since we are in desperate need to get a job done ASAP.

Luis

[ajax147]

Hi Luis!

I believe the GridData-not-applying problem is fixed -- but you better double check. Fixed code is in the latest sls-dev (and opt-dev).

Root cause: a GridFile= line with an inline comment keeps the trailing tabs before the %, so GridFile= zern41em5z155em3.txt% flat.txt parses to the filename with the two tabs attached. A tab isn't a blank, so GridInit tried to open zern41em5z155em3.txt, reported "does not exist", zeroed the grid, and silently dropped the figure — which is why bumping the GridData magnitude changed nothing.

The fix strips trailing whitespace and tabs from the GridFile= value at parse time (msmacosio.inc) and hardens GridInit before the open. Verified on your SAVE'd optiix_dp_zgd: the re-tabbed version now reads the grid ("Reading surface grid data file zern41…") and the figure moves the exit-pupil OPD as expected. It's on sls-dev and cherry-picked to opt-dev — pull and rebuild to pick it up.

The weird thing is, it's the shared macos/smacos prescription parser, so GMI, pymacos, mmacos, and command-line MACOS should all handle the same Rx file the same way -- but don't seem to in this case. So -- can you check that all is really OK???

 -Dave

[lmarchen]

This is what I see when I run your code:

[lmarchen]

Dave,

Actually the previous figure in my previous comment was applaying grid differently because of how the parameters lMon and GridSrfdx are defined, this picture here is the original one with the original files I checkout from the git repo:

Luis

[ajax147]

So- all good or still a problem?

[lmarchen]

Dave,

Let me get back to you tomorrow. Do the plots I provided look right? Is that what you are expecting to get from the test?

I will run a couple of tests tomorrow and let you know how it goes.

Luis

[lmarchen]

Dave,

What I found out today:

1. The parameter OpdRefRayLen is relevant in getting the correct OPD, the previous two plots I included here were wrong because the parameter was mispelled, it was OpdReRayfLen so it was not taking effect, that is why the third plot looks wrong.
2. If I flatten everything out for both files, GridFile= Flat.txt and ZernCoef= 6.0D-12 8.0D-12 2.0D-12 1.0D-12, all flat. Then I run your script I see the following (which is right):

3. if I take example 2 and comment out OpdRefRayLen for only one of them I see the following (which is right as well):

4. If I take one of the files in 2 and set GridFile= zern41em5z155em3.txt for Segments 1, 3, and 5 I see the following:

I expected to see this on segments 1, 3, and 5 (especially because the effect should only include Conic Sag + Grid Sag, What do you think?):

5. Here I am adding grid_dz= zern41em5z155em3.txt, I expect to see something on Segments 1, 3, and 5 (Which I see, again it does not look like zern41em5z155em3.txt):

6. Now I am running 5 but additionally I set Surface= Zernike for Segment 2, and I added same grid_dz as in 5, this is what I see:

7. Now I ran the same example as in 6 but I set Surface= GridData, I see the following which I did not expect, I expect to see Setment 1, 2, 3, and 5 with the same effect:

So I believe there is still something wrong. Maybe it is my understanding, or maybe there is still something going on in MACOS.

[ajax147]

Hi Luis!

As I recall the segments on iris are 0.5 m? In which case we should have GridSrfdx=0.002 to see the full shape. Instead the Rx has GridSrfdx=0.02, so only the very center of the grid is actually on the optic, and you can't see the full shape. I'll try your experiment to confirm, but I'm guessing that's the problem.

             -Dave

[lmarchen]

Dave,

That is a good point, I will make adjustments accordingly.

Luis

[ajax147]

Actually the segs are 280 mm diameter, so dx should be 0.0011=280/255

[ajax147]

Hi Luis!

Following up on the iris_dp ZGD grid-figure question. Three findings:

1. Trailing-tab bug (fixed allready, macos 31fad6b): a GridFile= line with an inline % comment kept the tabs before the comment as part of the filename, so GridInit silently failed and the grid figure was dropped entirely. A clean or SAVE'd Rx was never affected.

2. Non-sequential grid-frame bug (fixed today, macos sls-dev 60f886d): a typo in the trace passed the wrong element's grid coordinate frame at the two non-sequential call sites, so every ray sampled the grid's center pixel. Fixed.

3. GridSrfdx: the grid spans (nGridMat-1)*GridSrfdx, centered on pData. For a 256-point grid on a 280 mm segment: 280/255 ~ 1.1.

Verified with single-effect variants of the Rx (Conic / Zernike /GridData / ZrnGrData; mmacos/examples/ns_griddata, e6f4f17): each leg
images correctly, a flat grid is bit-identical to none, and ZrnGrData = Zernike + GridData to ~2e-4 relative -- that residual is the real second-order cross-term (each figure re-sampled at slope-shifted footprint points, mostly via the double pass), not an error.

Anyways, check out sls-dev, redo your tests and let me know either way!

  -Dave

[lmarchen]

Dave,

thanks!!! I will checkout right away.

Luis

[lmarchen]

Dave,

I think the latest takes care of the problem. I am testing on Windows and I was able to get good results the first time I ran, after that I am not getting the same results. I think I may have a different problem on windows. I will compile on Linux some other day and test again.

Luis