Skip to main content
Solved

Version managment of OpticStudio


Dear all, 

I wanted to start a discussion about version managment of OpticStudio files. Everyone will know this problem of saving changes as a new file (V2, V3_final...). I want to use a git respository to manage the changes of an optical design. 

Does anyone already had experience with this?

Best answer by Photoniker

I started to use git to manage the different versions of the OpticStudio models.

Such a repository should be organized like this:

- check in the *.zmx files into the repository. The *.zmx files are saved as ASCI files and are suitable to document the changes like in programming languages. 

- do not check in the *.zda session files. This should be user depended temp files

- add Zemax Documents files to the repository which must be copied into the working documents files folder

- realease versions of OpticStudio models should be saved as a *.zar Archive file in some folder outside the repository 

View original
Did this topic help you find an answer to your question?

7 replies

Kevin Scales
En-Lightened
Forum|alt.badge.img+1
  • En-Lightened
  • 185 replies
  • May 20, 2020

Thank you for your question. Your idea of using version control/management for OpticStudio is one that’s gotten asked from time to time over the years, but it has not resulted yet in implementation. I cannot say when such an option will be included within the code or as a recommended external program. If you do decide to go on your own and have any experiences you would like to share with us and with the Zemax community, though, please don’t hesitate to share them here.


  • Author
  • Infrared
  • 12 replies
  • Answer
  • June 25, 2020

I started to use git to manage the different versions of the OpticStudio models.

Such a repository should be organized like this:

- check in the *.zmx files into the repository. The *.zmx files are saved as ASCI files and are suitable to document the changes like in programming languages. 

- do not check in the *.zda session files. This should be user depended temp files

- add Zemax Documents files to the repository which must be copied into the working documents files folder

- realease versions of OpticStudio models should be saved as a *.zar Archive file in some folder outside the repository 


Berta.Bernad
Zemax Staff
Forum|alt.badge.img+2
  • Zemax Staff
  • 112 replies
  • June 25, 2020

Thank you for starting this discussion! Along the lines of keeping track of the changes during the design process, I'd just like to share the method used by one of my colleagues


  • Author
  • Infrared
  • 12 replies
  • June 25, 2020

Hi Berta, 

thanks for your answer. The major difference of his method ist. Wenn you use a log book 'TRIP2.txt' you may forget to write there your message. 

When using git you do not need to save several different file. You work on one file containing serveral revision each having a commit message. You can also compare the *.zmx ASCI--file and see line by line the difference of two files. 


Amy Entin
  • Infrared
  • 7 replies
  • January 17, 2022

@Photoniker ,

Thanks for this answer! Would love to try using Git for my Zemax projects. I was wondering if you’re still using it and how you’ve found it for more complicated files (eg non-sequential files with several sources, objects, etc.)?

Thank you!


  • Author
  • Infrared
  • 12 replies
  • January 17, 2022

Hi Amy, 

yes I’m still using Git for my Zemax project. Sources, objects, CAD-files are also copied into the repo. That is not a problem, because there are not changed by each commit in the repo. 

However, I have not idea how to handle the new *.zos format which is a binary format and cannot be managed by Git. 

 


Alberto.Donazzan
Ultraviolet

I’d love to see the Zemax File Comparator tool as a standalone application, or maybe as a plugin of WinMerge (or similar software). With .zos format I guess any custom-developed comparator won’t work any more.
 

But before that, just sticking to the present File Comparator, I find it pretty dumb. It does not compare “lens-wise” but just “surface-wise”, so that, if you have an additional dummy surface somewhere, then everything looks different, when it’s actually not the case. 

I’d also really appreciate some sort of visual comparison between layouts, something much like what you get when overlapping multiple configurations.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings