Hey Paul,
Just wanted to comment on the last statement of “maybe there’s a reason Zemax can’t make this change”.
The data structure of the MFE is such that each and every operand has to have the same inputs, namely the first two columns have to be integers and the remaining 6 columns have to be doubles (sometimes Columns 3-8 appear to be integers as well but this is only in the UI, in the code they are treated as doubles). Also, if the column is ignored, then this is treated as either 0 (for the integers) or 0.0 (for the doubles).
In order to extend the MFE for future operands and to ensure files created with older versions will still work with the latest version of OpticStudio, the 2+6 input columns cannot be modified. This is the reason why an operand like FICL (single mode fiber coupling) can only have 8 inputs and not the 19 inputs needed to fully define a SMF coupling calculation.
So it is unlikely that the entire structure of the MFE and operands will change. However, individual operands which do not currently use all 8 input columns (a vast majority of operands only use 6 input columns) could potentially be modified to include a Global column. Also, if the logic of converting from local to global coordinates inside an operand might be considered “too costly” during an optimization run though...even if adding 1us per operand is needed to convert to global, if you have 5 fields, 5 wavelengths, & 20 surfaces, then this adds 0.5 ms/optimization cycle and an optimization run simulations hundreds of thousands of times, so this simple change could drastically increase the optimization time.
That’s a good point michael…. I think. as for it effecting ray trace speed, there should be no reason for that. If G is a (default) negative 1, then the calculation is local and Zemax knows that. If the G value is some positive integer, then Zemax is flagged that it’s global and there should be no difference between REAY with a G value specified and an RAGY.
I don’t understand why inserting another column in the MFE would be a big deal. As for backwards compatibility, it should be fairly easy to handle. Like inserting a surface or something. Just insert the new column in the MFE. Ken once told me that he painted himself into a corner when programming Zemax in a spread sheet type format. He can’t pick up values in a surface larger than the one picking it up, or in a config that’s higher. Like you can’t pick up a value in config 5 from config 2. You can’t pick up a value from surface 20 from surface 4. It’s frustrating. It’s also frustrating to be allowed only one global surface at a time.
But thanks for your reply.
Paul
