Hi @Jeff.Wilde!

I replied to your previous post.

I had a chat with the product team and they explained that you can’t turn off the “Project Directory” feature from the interface because as Michael said, it may break the links to the right catalogs, etc… But the product team is aware of this and there is some work being done on this feature which is planned to be released later in the year. 

Hey Sandrine, 

I want to caveat my previous statement...”I don’t think OpticStudio should automatically do conflict resolution” but even if all the files are the same the directories are not deleted when unchecking “Is Project Directory”. OpticStudio still keeps the Project Directory folders.  In this scenario where all the external files are the same and the use unchecks the Is Project Directory box, the obvious intention is to

• Keep the ZMX/ZOS and ZDA file in the current location
• Delete all folders originally copied over when initially creating the Project Directory

This checkbox is often checked accidentally (I have not found a reason to use Project Directories yet) and once it’s checked, it can’t be undone.  At a bare minimum, Zemax should implement a SHA Sum Check for all external files between Global and Project Directory and if there is no difference, then delete the Project Directory files.  

Another update should be to simply default to not using Project Directories.  Every time I extract a ZAR, I need to actively uncheck the Project Directories box.  If I forget to do this one time then the file becomes a Project Directory file and it’s difficult to undo.

Until Zemax fully implements a true global solution with file conflict resolution, “fall back” to global files, etc, Zemax should have the option to completely bypass the Project Directory option.

Also, I remember a roadmap where the plan was to search in the following order for files after a Project Directory was created:

• Look for the external file in the Local Folder structure where the ZMX/ZOS file resides
• If the external file can’t be found, then look in the global location (Documents/Zemax location) and load that file
• If both locations don’t have the file, then throw an error.

The current behavior however is:

• Look for the external file in the Local Folder structure where the ZMX/ZOS file resides
• If the external file can’t be found, then look in the global location (Documents/Zemax location), copy that to the Local Folder,  and load the copied local file
• If both locations don’t have the file, then throw an error

This defeats a MAJOR benefit of Project Directories.  Zemax by default overwrites local files (DLLs, AGF, COATING.DAT, CAD Files, etc) when extracting ZARs and this can really mess up other projects.  The concept of a Project Directory, at least in the current form, is to better manage an individual engineer’s workspace so they can keep track of different optical designs easier.  However, in the current form, Project Directories actually make it harder to keep track of different designs, not easier.  

Even before a new File Utility is created by Zemax to help identify & select which files are used for which projects, it would be a big benefit to use the first 3 bullet points of logic when loading external files.  This new logic would solve another recent question to the Forums as well:

• How does DLL find project name or project folder?

I think there are several active, highly contributing people on this forum who have used the Project Directories feature and can give some really good real-world feedback.  If the Product Team could setup an official survey to get feedback, I think Zemax can get a lot of positive feedback as to the future direction of Project Directories and help guide/justify work in this area.  

Hi @Sandrine Auriol:

Thanks for looking into this issue.  Based on your response above, can I assume that even though the Project Directory switch can be turned off in the API, I should *not* do this because the model file could become unstable even though all of the necessary auxiliary files exist in their proper global locations?

I agree with Michael that the current implementation of Project Directories is not preferable over the standard legacy approach.  It’s too bad that this feature, which if better implemented could actually be very useful, got released in it’s current form without user testing and feedback (I think the beta test team may have been disband prior to this feature release).  For example, I have a lot of ZPLM macros (ZPLXX.zpl) and other custom macros that have accumulated over the years, and in my case it would be very nice to split them up into various project directories organized according to customer.  The same goes for coating files, POP beamfiles, tolerance scripts, glass catalogs, etc. 

Hopefully Zemax is open to taking input from its users to help guide an improved future implementation.

In the meantime, I’ve found that if I open the files in an older version of OpticStudio, then I can save and re-open them in the current version w/o the Project Directory feature.

Regards,

Jeff