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:

1import time
2
3t = time.time()
4print('Sampling 0: ' + str(TheSystem.MFE.GetOperandValue(ZOSAPI.Editors.MFE.MeritOperandType.CENY, 0, 1, 2, 0, 0, 0, 0, 0)))
5print('Time lapsed: ' + str(time.time()-t))
6
7t = time.time()
8print('Sampling 5: ' + str(TheSystem.MFE.GetOperandValue(ZOSAPI.Editors.MFE.MeritOperandType.CENY, 0, 1, 2, 5, 0, 0, 0, 0)))
9print('Time lapsed: ' + str(time.time()-t))

The console output reads (code run multiple times):

1Sampling 0: 17.450689876377123
2Time lapsed: 0.001974821090698242
3Sampling 0: 17.450678324665706
4Time lapsed: 0.003976583480834961
5
6Sampling 0: 17.450689876377123
7Time lapsed: 0.0019915103912353516
8Sampling 5: 17.450678324665706
9Time lapsed: 0.0029811859130859375
10
11Sampling 0: 17.450689876377123
12Time lapsed: 0.001978635787963867
13Sampling 5: 17.450678324665706
14Time 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