Good morning,

I am attaching the example files Sanjay put together for the talk last week. There are four files in total:

1. Lamp reflector asphere: This file works well for LightningTrace because it uses an IES source. In this file, the Visual Optimizer has been set up to allow for dynamic feedback on the impact of system parameters on the overall results. 



2. Beam Shaper: This file works well for LightningTrace because it uses a source in which we can neglect the near-field spatial distribution. In this file, the Merit Function has been set up to conduct full parametric optimization.



3. Two Color Mixing: This file works well for LightningTrace because, like the Beam Shaper, it uses a source in which the near-field spatial distribution can be ignored. As above, this file has also been set up with the Visual Optimizer. Using the Visual Optimizer with LightningTrace is ideal as the results will populate much quicker for that tool than for a full ray trace of the same system. 



4. Freeform optimization: This file does not work well with LightningTrace; that is, the results for LightningTrace are very different from the results of the full Ray Trace. 

In addition to the files above, there are several discussion points that we would like to summarize here. In this post, we will be discussing LightningTrace-specific questions. Some of the other topics will be covered in the next post. Please feel free to respond with your questions or comments!

Can I use LightningTrace to more quickly analyze a system that has been converted from Sequential Mode to Non-Sequential Mode? If so, would I be able to obtain a reasonable PSF using this approach?

LightningTrace is well-suited to tracing a sequential model that has been converted to Non-Sequential Mode, assuming that you are comfortable continuing to characterize the sources as point sources (i.e. neglecting the near-field spatial distribution of the sources). This would be a perfect tool for modeling systems that are awkward to represent in Sequential Mode, such as those with complex 3D geometries. However, LightningTrace does not currently support coherent ray tracing, so cannot be used to generate a PSF. This restriction could be lifted in future versions of the algorithm.

Will LightningTrace work with ray files (DAT files)? What about other source file types (IESNA, etc)? Are there any sources that will not work?

LightningTrace with work with ray files. The sources that are not supported with LightningTrace are listed in the Help file, they are the Source Diffractive, Source DLL, Source Imported, Source Object, and Source Ray types.

What are the limitations of LightningTrace on the source we can use and on the optics we can model?

The limits are the types of sources (all but those 5 listed above are supported), and that we cannot support collimated sources or sources in which spatial distribution is important. Since LightningTrace doesn’t account for dispersive effects, the optics which cannot be used are diffractive optics (e.g. the Diffraction Grating), otherwise all other objects are supported.

Regarding perfectly collimated sources - what do you suggest is the best approach here if I need to use this source type?

You can make a source that has a very small amount of divergence in it, to the point that the divergence shouldn’t meaningfully affect the results. For example, with the Source Ellipse you can set the Source Distance to 1E6 or larger, which means that the divergence would be tiny but non-negligible. 

Currently, LightningTrace does not acccount for ray splitting. In the talk, this was considered to be a 'soft-limitation' or, in other words, a limitation that could potentially be worked-around. As such, would it be possible to expand the functionatlity to allow for a single splitting path? This would be useful for ghost analysis, for example. 

The idea for allowing a single split per ray is interesting. We will look into the LightningTrace architecture to see whether or not the tool could support this. It would be an ideal compromise between the full ray trace and the current LightningTrace technology, if available. 

LightningTrace does not account for scattering. Is there another method to efficiently model this?

Right now, LightningTrace does not account for scattering because the tool wouldn’t be able to interpolate data between the triad of rays that go through a single triangle in the source mesh, because those 3 rays could take very different paths through the system once they scatter from the surface. This could possibly be modified to consider surfaces that are small-angle scattering surfaces, but will not be implemented in the near-term. 

For now, Importance Sampling and the Scatter To list allows for some efficiency gains. We have a tutorial on this tool here: 'How to use importance sampling to model scattering efficiently.' Zemax is actively researching other methods to improve ray-tracing performance for systems involving scattering.

During a ray trace, edge effects could alter the order of the surfaces a ray strikes. How does LightningTrace handle this?

If the order of surfaces that are traced changes for all rays then there is no issue, LightningTrace will handle this just fine. If the order of surfaces changes for 1 or 2 of the 3 rays in a triad that is launched from the source mesh, we can detect this using the Path Analysis tool in OpticStudio, and then sub-divide the mesh to resolve. The Edge Sampling control allows the user to define the importance of such effects, with higher sampling providing more control for sub-division.

How well-suited is LightningTrace for micro-lens arrays?

The feature works well with micro-lens arrays, so long as the assumptions behind LightningTrace hold (i.e. sources can all be approximated as points).

How well will LightningTrace work with freeform lens design?

This was one of the main intended use cases for LightningTrace! This allows users to have fast feedback on the design, which can otherwise be challenging depending on how the freeform is modeled. Rather than using full parametric optimization – which is also supported by LightningTrace – you can use LightningTrace and the Visual Optimizer to get dynamic feedback on system performance and sensitivity to the freeform design.

Finally, near the end of the talk, we had a discussion on some non-LightningTrace-related subjects. They are posted below:

When working in Non-Sequential Mode, how do we know how many analysis rays are 'enough'?

In Non-Sequential Mode, we capture information using pixelated detectors. The signal-to-noise ration (S/N) on any pixel is the square root of the number of rays landing on that pixel (assuming Poisson statistics governs the ray trace). So, you should determine what S/N you are looking for across your detector and will need to set the number of rays accordingly. Unfortunately, this can only be done once an initial ray trace has been completed, so you will need to do one ray trace first to get the baseline S/N. At Zemax we are investigating methods to automate this process.

With LightingTrace, it is generally fast enough to change the Ray Sampling and Edge Sampling values to determine their impact on the results. The default values of 16x generally work well for most systems.

Could OpticStudio utilize the GPU to speed up calculations?

OpticStudio is currently utilizing GPUs on the computer for system rendering and data visualization. However, the current architecture of OpticStudio is not well suited to conduct ray-tracing on a GPU. We are investigating whether this could be changed in the future, but are also investigating into other solutions for accelerating ray-trace performance, beyond LightningTrace.

How can we pause ray traces to batch a long ray trace?

The best way to achieve this right now would be to use the ZOS-API to run incremental ray traces. We have several examples of running a Non-Sequential Ray Trace through the API within the folder {Zemax}\ZOS-API Sample Code. 

Why is my detector blank when I use LightningTrace, but shows an output with a regular ray trace?

To read the results from LightningTrace, the detectors used must either be the terminal detector in the system, or set as ABSORB:

If these constraints aren't met, the detector will show no signal after LightningTrace has been run.