Unclear sorting of rays in zrd file / raydata base viewer with non-randomized source files

  • 9 February 2024
  • 1 reply

Hello everyone,

I have the following problem (Zemax 22.3):

  • I generated a binary source file (20000 rays - number does not really matter) with a specfic order of rays (sdf file with wavelength and flux)
  • I build a dummy non-sequential system consisting of the source file (randomization turned off) and a dummy surface (complexity and structure of the system does not matter as well)
  • After tracing the rays and looking into the ray database viewer the order of the rays is actually not as defined in the ray file, as I expected (I checked if the order in the ray file is correct with: Python Reading Writing Binary Files (ZRD, ZBF, DAT, SDF) | Zemax Community)
  • While there are correctly ordered sub-batches of rays in the zrd file, the position and size (number of rays) of the batches depends on the settings in the System Explorer → Non-Sequential. Changing e.g. Maximum Intersections per Ray, etc leads to a different order/size of the batches in the ray database viewer. My expectation was that these settings should not have an influence on the order in the zrd file, as the maximum intersection, etc. of the dummy system are below the minimum settings

Since the randomization option of the source file object was turned off, I expected the same order of the rays in the zrd as defined in the source filed, which is obiously not the case. I also did not expect the System Explorer → Non-Sequential options to have an influence on the order of the rays in the zrd file, as the number of intersections/segements in my dummy system is lower than the minimum possible setting.


Is there a way of keeping the ray order of the source file without manually sorting the zrd file?



Best answer by MichaelH 9 February 2024, 16:43

View original

1 reply

Userlevel 6
Badge +2

Hi Christoph,

When OpticStudio runs a non-sequential ray trace, it will batch up rays (I believe 1000 at a time) and trace these batches across multiple threads.  When a thread is done, it is written to the ZRD file directly as-is without “waiting” to see if a previous thread has finished yet.  So, if you have 20,000 rays, this would be approximately 20 batches of rays; each batch should preserve the order of the rays inside the batch but no guarantee about the order of the individual batches.  If you re-run the ray trace, you’ll likely get a different order of the batches.

I believe if you turn the # of Cores in the ray trace control to 1 you’ll preserve the order of the rays but at the cost of speed.