Can someone help on this? Someone from the Zemax team maybe. Thank you

Hi @Alberto.Donazzan,

Apologies for our delayed response to your question. The reason that you see a listing for more cores than are actually available on your machine is that the field is more of a request than it is a setting. If you choose a number of cores that is larger than your actual machine’s capabilities, the Windows operating system will receive the request but would only ever give the maximum number of cores it has available.

The second part of your question is a little more challenging to answer. OpticStudio is always subject to the resources that Windows makes available to it. As I mentioned before, the “# of Cores” is a request, and Windows will unlikely ever give OpticStudio access to all the cores it has available, since it needs to reserve some for itself or other applications. The number of actual cores that get provided to OpticStudio is dictated by memory considerations and what other threads are already running.

Now, if you have two separate instances of OpticStudio running, and the first to run requests 6 cores, it will likely be allocated those 6 cores. This again depends on what else is happening on your system. Then, if you start the second optimization with 2 cores, it will only request up to 2 cores, but there is no guarantee that Windows will provide the total resources requested (especially if you reach the total number of cores). By controlling the relative cores and the instance that launches first, you could try to exert some amount of priority over the two optimizations.

Another important note to remember: the number of threads to be requested is given by the number of variables in your system. The multi-threaded calculations only consider the rate of change of the Merit Function for each variable, and the MF value computation itself is not multi-threaded. For any variable, we can introduce a perturbation and see how the MF value changes, to determine slope in the solution space for use in the optimization cycle. These derivatives are threaded for each variable; therefore, the overall threads are limited by the variable count.

I hope this explanation is helpful.

Best,
Ethan

Hi Ethan,

thank you a lot for the in-depth explanation.

Unfortunately, if I got it right, it is not that simple, if not impossible, to actually tell the system how to precisely split its computational power between multiple ZOS instances. I guess I can make some attempts by carefully monitoring the OS running resources and the number of optimization variables, but this is not straightforward at all, neither it can be done on a daily basis.

I think it would be better to cope with this by addressing a single machine to each ZOS instance (whenever possible).

Finally, I would suggest to somehow add your precious insight to the ZOS Help file!