It is designed to allow optical engineers to create optical systems procedurally and then to simulate and optimize them. Unlike Zemax, Code V, or other interactive optical design systems OpticSim.jl has limited support for interactivity, primarily in the tools it provides for visualizing optical systems.
A large variety of surface types are supported, and these can be composed into complex 3D objects through the use of constructive solid geometry (CSG). A substantial catalog of optical materials is provided through the GlassCat submodule.
This software provides extensive control over the modelling, simulation and visualization of optical systems. It is especially suited for designs that have a procedural architecture.
This software is still under active development so expect frequent changes.
Thanks for the suggestion. We’ll add the clarification about ray tracing.
OpticSim was created to address problems we had while modeling a complex optical system being developed internally. This system has an architecture that lends itself to procedural specification but making this work with Zemax was difficult.
We ended up with an amalgam of Zemax, Matlab, and Python code, that required several manual steps to convert from one format to another, a tedious and error prone process. Non-sequential scattering simulation was also very slow, taking 10 hours+ per render on a 24 core machine.
The difficulty of working in multiple systems and languages was slowing progress significantly, and was a maintenance nightmare. Hence the desire to do everything in one language and one system.
The goals of the OpticSim project were:
build a modern, well modularized optical ray tracing system that can be easily modified and extended
make it simpler to specify and manipulate complex optical systems that have an architecture that lends itself to procedural construction.
make it possible to distribute tracing on the cloud for very complex models.
do it all with one language and one environment.
Performance was not a primary motivation since we assumed time consuming simulations would be distributed to the cloud. To our surprise the Julia code was fast; we haven’t needed to use cloud processing yet.
We haven’t done extensive benchmarking against proprietary packages so can’t make general statements about performance. For the complex model mentioned above non-sequential ray tracing in OpticSim is about 15x faster than Zemax on a 24 core processor.
Take this with a huge grain of salt. Performance on your optical system could be very different. We’re not making any claims about performance until we see benchmark results on a wider variety of optical systems.
Should also add that the current version only does non-sequential ray tracing.
It would be straightforward to add sequential ray tracing, which would improve performance in cases where the assumptions of sequential tracing are valid.
We didn’t need sequential tracing for our applications but would be happy to advise contributors who might be interested in adding it.
I would be interested to take a shot at sequential raytracing. I’ve written some very limited sequential tracing code for a very specific application, but I’d love a more general solution. I cannot promise too much, since this would be in my spare time, and I am not much of a programmer anyway.
One question: from a first look at the documentation it seems that there is always only one detector surface in the system. How easy would it be too generalize this to an arbitrary number of detectors? My day job is in high power laser applications, and in this field the question where all the light has been lost can be as important as the question how the laser spot looks like in the image plane.
We are working on generalizing the system so there is more than one detector.
As for doing sequential raytracing perhaps you could open an issue on the repo and I’ll follow up there? We’ll get down in the weeds quickly which might not be of interest to most of those on this announcements forum.