Skip to main content

Hi everyone,

 

I stumbled across an odd behaviour in the ZOS-API regarding CENY with GetOperandValue. I’m using Python 3.8.15, and Pythonnet 3.0.1.

If you run the following code in an interactive extension with the Double Gauss 28 degree field sample file:

import time

t = time.time()
print('Sampling 0: ' + str(TheSystem.MFE.GetOperandValue(ZOSAPI.Editors.MFE.MeritOperandType.CENY, 0, 1, 2, 0, 0, 0, 0, 0)))
print('Time lapsed: ' + str(time.time()-t))

t = time.time()
print('Sampling 5: ' + str(TheSystem.MFE.GetOperandValue(ZOSAPI.Editors.MFE.MeritOperandType.CENY, 0, 1, 2, 5, 0, 0, 0, 0)))
print('Time lapsed: ' + str(time.time()-t))

The console output reads (code run multiple times):

Sampling 0: 17.450689876377123
Time lapsed: 0.001974821090698242
Sampling 0: 17.450678324665706
Time lapsed: 0.003976583480834961

Sampling 0: 17.450689876377123
Time lapsed: 0.0019915103912353516
Sampling 5: 17.450678324665706
Time lapsed: 0.0029811859130859375

Sampling 0: 17.450689876377123
Time lapsed: 0.001978635787963867
Sampling 5: 17.450678324665706
Time lapsed: 0.0030303001403808594

The only difference is the sampling of CENY. In the first case, I used 0, and in the second case, I used 5. In the user-interface, if one types 0 in the Samp column, it defaults to 5 (so both cases are identical in the user-interface). As you can see, with 0 the centroid position is slightly different, but more importantly the calculation speed is almost doubled, which is quite valuable for me. In practice, running this snippet multiple times doesn’t always show double the speed, but the calculation time is always smaller for a sampling of 0.

Have you noticed the same? Where does the difference in centroid value come from?

Take care,

 

David

Hey David,

Check your GetOperandValue.  I think you are changing the Pol? column and not the Samp column.  Although in the GUI you can only have either 0 or 1, I think the core code is actually looking at Pol? > 0 to check if polarization should be used.  Since a polarization ray trace needs to trace 2 rays, so you will have double the execution time.  

I think there is similar logic for min Samp value in the core code which could differ from what the GUI shows, but I’m not certain.


Hi @MichaelH,

 

Sorry for the obvious mistake on my side. I think I tunneled vision onto the speed improvement…

Thanks a lot for looking at my code anyway.

Take care,

 

David


Reply