I’ve just tested the new "Convert to Project Directory" feature with a design file using scripted tolerancing.
- I noticed the browsing dialog box (which appears to let the user select the project folder) does not let you create a new folder by simply inserting a new name. The user is forced to right-clic and create a new folder manually, then select it.
- the new project directory which is created misses some essential files: .MF , .TOP , .tsc
Best answer by Alissa WilczynskiView original
Ah, I see how this works now! It looks like the contents of an uncompressed ZAR file...is that correct. If so, I’ve wanted that for some time so we can use GitHub as a version control system. Has anyone at Zemax tried that yet?
P.S. Can’t help but notice that the tool creates .ZMX files and not the new .ZOS format.
A couple of observations from me:
There seems to be no documentation on this feature. Using it takes you straight to a Save As dialog. Is there any description of the intended use of this feature in the docs?
Once you use it, the feature is greyed out for future use. Why is that?
Once you use it, how does OS know to use the files from the project folder and not from where we have stated in Project Preferences?
Sorry, I’ve just voted for best answer by mistake . Don’t know how to undo! Let’s see if someone from Zemax can help even with this.
Anyway, Thank you
@Mark.Nicholson for your additional observations.
I have removed the best answer.
Hi Alberto & Mark,
You’re right - the project directory tool doesn’t assume that you’re creating a new folder, but instead operates expecting you to select a folder. If you want to save to a brand new folder, you’ll need to add it first, then select it.
Only a subset of the files that can possibly be used in an OpticStudio system are included in the project directory for 21.3, and additional file types will be added in 22.1. The goal is to include the files most commonly used or customized for specific systems/designs. The file types included for 21.3 are:
.DAT, .ZEC, COATING.DAT
.AGF, .BGF, .GGD, .GRD, .IND, .TID, .ZTG, GLC.DAT, GRADIENT_9.DAT, SGRIN.DAT
.IGS, .SAB, .SAT, .STEP, .STL, .STP, .ZAN, .ZEN, .ZOF
Objects/Creo Parametric Files/
The ZAR is still separate from the project directory, both because the project directory doesn’t include all relevant file types but also because the ZAR is still the ideal way to share your system with a colleague. Using a ZAR allows the recipient to unpack the files to either a project directory or to the classic file organization structure.
The project directory and ZAR will both include whichever file format you’ve used to save your file. If you saved your file as ZMX, then the project directory will include the ZMX file. If you then save your file as ZOS, that can also be part of the project directory.
The choice between project directory and what I’ll call the “classic” file organization system is available on a project-by-project basis. By selecting the “Convert to Project Directory” button, you’re telling OpticStudio that whenever it needs a supporting file, it should first look within your project folder. If it can’t find the right file type there, then it will look in the “classic” file folder structure. If it still can’t find the right file type, it will issue an error message.
The choice to use or not use project directory organization is really a binary choice (yes or no). Once you select it in the button ribbon, then OpticStudio copies/creates all the required files in the folder specified and also checks a box within your System Explorer. If you want to effectively “unconvert” from project directory back to classic file org, you would uncheck this box. The project directory would still exist, but OpticStudio would no longer look there for any supporting files.
We will soon have additional Knowledgebase articles that detail the project directory and recommendations for saving and sharing files with colleagues. We’ll add links once those are published.
I think this will be VERY useful. I hope to see additional file types added, like MFs and UDAs. When I save one of these it is always specific to the project, and it’s a nuisance to have to give them complicated unique names and select them from a drop down that includes every one I’ve created in the last 20 years. 😀
I completely agree with you
@David. Also for .tsc tolerancing scripts holds the same observation. I hope we’ll see them added to the Project Directory in the future.
@Alissa Wilczynski for the thorough explanation.
Thanks Alissa, great explanation.
It is not possible to un-check the “Is Project Directory” box once it has be checked by the “Convert to Project Directory” button. I’ve submitted a bug report to support.
I think it’s intended to be a one-way street, but we’ll see what the devs/product people say
Understood but that doesn’t seem to be the impression the user manual gives. “If this checkbox is cleared, OpticStudio will no longer use the files that are saved in the Project Directory.”
Related to the subject, in what cases would the “Convert to Project Directory” always be greyed out even when launching OpticStudio? I have a co-worker in this situation … everything he works on and saves goes to a Project Directory and he can’t undo it.
To go from global to project directory for the first time, OpticStudio simply needs to create new folders where the ZMX/ZOS is saved and then copy the global files (such as coating, scattering, etc) to this new folder structure. If you notice, the folder structure for a Project Directory is the exact same folder structure as for the ZemaxData directory. This one-time transfer will always be 100% accurate and there is no conflict in over-writing an existing file.
Now, if you try to go from a Project Directory back to the global option, all the unique files (coating, scattering, etc) now need to have conflict resolution. What happens if you:
Should OpticStudio over-write the global COATING.DAT file, possibly corrupting another ZMX file using the global COATING.DAT file? Should OpticStudio try to merge the two files? What happens if you add a new coating to both the global and project COATING.DAT file but they have different values? Who wins? The most recent? The global?
This is the problem with document versioning software in general...it’s a multi-billion dollar industry and there is no clear winner on how to implement a solution like this.
I think Zemax is just trying to give users more options to organize their workflow without stepping out of their lane as a physics-based prototyping software platform.
So even if this is a bug for not being able to uncheck Project Directories, if this is fixed then there will be another using saying there is a bug because a file is overwritten or a ZMX/ZOS no longer gives the same results.
With something this complex, a software like OpticStudio will not be able to solve all problems for all customers and we will just have to learn to live with the caveats.
Then please update your documentation to this effect so that it doesn’t imply that the box can be unchecked … “If this checkbox is cleared, OpticStudio will no longer use the files that are saved in the Project Directory.”
Good point. I will ask for a help file update.
The concept behind this relatively new local Project Directory feature seems useful at first, but like
@Patrick.Cronkite, I’m very frustrated that once it’s turned on, there seems to be no way to turn it off. Michael raises potential conflict issues associated with turning this feature off, but I don’t see why it can’t be deactivated so that OpticStudio looks for auxiliary files in the usual global location (\User\Documents\Zemax) -- if they don’t exist, or the file isn’t correct (like an old Coating.dat file), then an error is issued. The local project folders shouldn’t be automatically deleted. They can remain in place (possibly with names modified to indicate inactive) so the user can manually port what is needed back to the global location.
Actually, I would like to be able to store auxiliary files/folders in a Project Directory folder that I can create or select, with a location that stays embedded in the OpticStudio model file. (This is distinctly different than the Project Preferences → Folders setting that is global in nature). That way I can have multiple model files in multiple folders, all of which refer to a specific Project Directory folder location of my choosing with customized auxiliary files.
As it stands now, the Project Directory feature requires every single model file to reside in one folder, and inside this one folder are all of the new Project Directory subfolders. For large projects, this becomes too cluttered -- which is where I find myself now. So, I want to go back to using the global location for auxiliary files, but OpticStudio refuses to let me. Now I have several model files that are all stuck in this state. Even if I delete all of the local Project Directory subfolders (having already ported all necessary auxiliary files to the standard global location), when I open a model file, it automatically re-populates all of the local Project Directory subfolders -- ugh! Sorry Zemax staff, but this is a very poor design. When this feature was first being considered for implementation, I suggested a Path function, much like Matlab uses, but apparently the decision was made internally to go in the current, very inflexible, direction.
So, I guess I’ll ask one more time, is there no way at all to turn off the Project Directory status??
I checked your comments and found out there is a way through the API. I tested it with Matlab Interactive Extension and that works.
I will check with the developers to see if it could be made available via the interface. It can be made available through the interface via a user-extension in the meantime. Let us know if you need any help on this.
I will also pass on your comments to our product team.
My work-around is: store the lens design file as a *.zmx text file and change the line “IWDP 1” to “IWDP 0”. Then reopen the Zemax file.
I hope that such manipulations of the Zemax lens design file will not cause Zemax Staff to disable the feature to store lens designs as text files…
Thanks for the tip -- very easy solution!