Opticsim.jl: Optical Simulation Software

- https://fluxml.ai/Flux.jl/stable/

- https://turing.ml/stable/

Later in the year we should see https://mtk.sciml.ai/stable/ maturing somewhat, which is a chunky project unlocking a lot modularity for scientific computing.

I feel like the language is reaching an inflection point with regards to the ecosystem richness.

But only if it is well documented. And that is really the problem with Julia. Besides some video tutorials, which I don't find helpful, you only have the manual which is not that good.

I said this before here but if you look at Rust which has unique characteristics like the borrow checker and is often described as having a steep learning curve: I was never overwhelmed by it or even felt it was difficult because there is much high-quality material to help you: The amazing book, rust by example and a lot of great third party resources like cheats.rs or the "rust in simple language".

The other day I was trying to look for julia books. Most of them were outdated and people advised against buying them (or the publisher pulled them already).

For reference, we (metalenz.com) have a large Julia codebase centered around optical design, simulation, and analysis. The motivation for that is more along the lines of composability and clarity of abstractions (aided by multiple-dispatch). We can differentiate through our physical optics solver code (forward or reverse) for optimization/ML, plug in our designs across a hierarchy of different E&M solvers, run on GPU, and write very efficient code when our profiling identifies a bottleneck. If we just had to perform one thing (physical optics simulations), then our investment wouldn't be as justified.

https://github.com/JuliaOptics/Fourier.jl

It's cheap compared to hiring an optics consultant. ;-)

But this is pretty common for specialized engineering software. My company maintains several seats of mechanical and electrical CAD software. Not surprisingly, the landscape of FOSS tools gets more and more sparse, the further you get away from software development.

A problem in optics is that just having the software won't teach you optics unless you're already trained in an adjacent field such as physics. The people who can do it, can simply demand that the employer pay for the software.

Oddly enough I'm interested in this package, and have bookmarked it. It's not like I need an alternative to Zemax, but that there are some ideas I'd like to explore that would benefit from further automation, but that don't need the breadth of features provided by Zemax. And maybe I'd like to try some things at home.

If you have glass files stored locally on your machine you can add the glass files to a sources file and the next time OpticSim is built it will include your glass files as well.

Looks like a modeling toolkit for lenses, telescopes, etc.

Most real systems of that sort suffer from artefacts like chromatic abberation, diffraction, etc. I wonder if such software can be used for modeling those things too.

Suppose you want to make a telescope with a certain spec for magnification and resolution.

Or, suppose you wish to design a headlight for a car with bright and even illumination over a given angular range.

Or, imagine you need to specify an interferometer for precision displacement measurement at the nanometer level.

For each of these systems, there are first principles equations and approximations that describe ideal and slightly-different-from-ideal behavior, but for anything other than very simple optical systems, these first principles approaches become unwieldy very fast. An optical simulation represents the physics of the design and approximates the output you would measure when you build the system. This allows you to optimize and perturb the design over manufacturing tolerances at the design stage, rather than iterating through these at the manufacturing stage (a rather impractical alternative).

The capability of any simulation approach depends on the phenomenon you need to model, and the degree of abstraction appropriate to that phenomenon.

An “exact” physical representation of an optical system essentially entails solving Maxwell’s equations along the initial and boundary conditions of the optical system. There are times when this is both necessary and practical, but (outside of semiconductor applications) that tends to be rare.

Ray tracing, which you mentioned, is a very popular and useful approximation for imaging and illumination. It’s especially useful when the wave properties of light are either not very relevant or they are very well behaved. Other simulation techniques incorporate more of the wave nature of light: Fourier techniques, field tracing, coupled waves, finite difference time domain, etc. It takes some domain knowledge in the application space to know which to apply.