Enhanced tolerance data viewer

[Omnistic]

Hi everyone,

I've seen several issues with the Tolerance Data Viewer in the past and more recently I worked on this one. The user requested that the corresponding line number from the TDE is shown next to the operands in the Sensitivity Analysis. I showed the user how it could be done with the ZOSAPI, and even started working on a bar-plot, which I think helps visualizing the sensitivities. I thought it would be nice to crystalize my contribution by somehow adding it to ZOSPy, but I have no idea where to start. I think this would be a new analysis, which enhances the current Tolerance Data Viewer, but there are other viewers that can be improved as well (I'm thinking about the Ray Database Viewer for example). Of course every viewer is unique, but I was wondering if there shouldn't be a sort of structure to manage them all. Then, currently, I've only worked on the Sensitivity Analysis part so it is far from complete. Finally, I don't know what the workflow would be to use this analysis, shall it be independant of the tolerancing. Meaning one should first run a tolerancing, save its data (whether manually or through the ZOSAPI), and then use the analysis? Any help is appreciated, I want to do it myself, but I might need a little bit of help as I'm not too familiar with contributing to such repositories.
Take care,

David

[crnh]

Hi @Omnistic,

Thanks for your post! This looks like a nice addition and we plan to look better into this in a few weeks.
For now, some questions / remarks in order to check if we understand your ideas correctly.

• As OpticStudio does not offer this functionality under the 'Analyze' tab, it should not be an analysis.
• This seems mostly related to tolerancing. Is it necessary / useful to include other functions for tolerancing in ZOSPy as well? In that case, we can consider adding the proposed functionality in a new submodule zospy.tolerancing.
• If you only want to implement the viewer, it is relevant to know we are working on support for the viewers introduced in OpticStudio 24 R1. The Tolerance Data Viewer can then be combined with those viewers in a new submodule, e.g. zospy.viewers.
• As you are working with tables, it seems best to use Pandas DataFrames and not build the table yourselves. Pandas then takes care of the visualization in your notebook / terminal / whatever interface you use. Judging from your code, the output seems to be tab separated, and data in this format can be easily converted to a DataFrame. Unfortunately, I cannot try this myself as I do not have much experience with tolerancing in OpticStudio and it seems I need an example file. Do you want to send us an example OpticStudio file, so we can try your code as well? If so, please send a message to 24o3ptk3@duck.com so you can share the file privately.

[Omnistic]

Hi @crnh,

• Got it.
• I can imagine that in the future people might come up with new functionalities for tolerancing, but I don't know really. a new submodule sounds like a good idea anyway.
• Sure, then maybe I wait until your work with the viewers is done.
• I will look into Pandas, I had heard of this module before but never used it myself. I don't do much tolerancing myself either, when replying to this user I just put a default tolerance data editor on a landscape lens. I will send a better file for future reference (and testing?). What about the bar plot? Is it something that could go into ZOSPy or shall it remains separated because it is a plot?

[crnh]

Hi @Omnistic,

I took a better look at the OpticStudio output and it looks quite a lot like an analysis. As we're planning to build more flexible analysis parsers this year, it could be wise to postpone working on the tolerance data viewer until these new parsers are available. Regarding your points:

• We can think about a suitable submodule later, when this proposal is implemented.
• I prefer to not include the plotting code in ZOSPy, but include it in an example, because the plotting code is fairly basic. Users probably want to customize the layout and style of the plot. Including a well-tested plotting method with sufficient customization options takes some effort and doesn't offer many advantages over having the users writing their own plotting code, in my opinion.
  • This is also consistent with how we currently want to write the system viewer methods: it will return the data in a format ready for plotting, but leave the plotting to the user.

[Omnistic]

Hi @crnh,

Understood, I think it makes a lot of sense indeed. Let's revive this later if there's a need.