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