#DevOptical Part 0: Introduction

Welcome to the #DevOptical series of posts where I will try to summarize my vision of optical systems design and how I intend to modernize it. The name “#DevOptical” was not chosen randomly as the methodology developed here is strongly inspired by was the IT world has been doing recently with the [∞] DevOps philosophy.

I have been working for almost six years now in a company specialized in high-end optical systems development and have contributed to the design and manufacturing of several instruments, including projects developed for the European Space Agency to fly in the International Space Station. I have been able to see what worked well and what was slowing down the development processes. I even had the occasion to attend ESA’s [∞] SOIDT one-week-training in the luxurious Sardinia northern region where I met other professional optical designers from across Europa including all the major players in the optical business (Airbus, OHB, Thales Aliena Space, TNO and others). These were all brilliant people but they were basically facing the same limitations than I was when designing their systems.

But first of all, what is an optical system? Well, it is about anything that is composed of optical components to achieve a goal. It can be a simple camera lens or a more complex assembly of different sub-systems that fit nicely together. An example of such is a dispersion-type spectroscope which consists of three sub-systems: (1) a collimation system (usually a single lens with a slit), (2) a dispersion system (a prism or a grating), and, (3) an imaging lens with a camera or CCD array. Although these sub-systems might look independent at first sight, it is important to design them such that they later work together. I briefly explained the concept of pupil matching [»] here which is a typical example on how sub-system interacts with each other.

There are also three ways to think about an optical system, complex or not: (1) at the general architecture & specification level, (2) at the optical element level, and, (3) at the mechanical assembly level. For instance, when building the [∞] OpenRAMAN spectroscope, I first made an overall sketch of the system to determine all the important quantities (grating angles, focal length, slit size etc.), then I determined which optical design was able to give the expected resolution based on this architecture and, finally, I checked how the optical elements would be mounted together. An illustration of the output of all three steps is given in Figure 1.

In the industry, these correspond to three very different jobs. The architecture is handled by a system engineer whose responsibility is to sketch the system and transform the project requirements into technical specifications. A system sketch is often composed of idealized optical elements such as thin paraxial lenses (a type of lens that has no aberrations and which are only described by their focal lengths). Based on the system sketch and the list of specifications, the optical engineer will replace the thin lenses by real ones. Most of the time, he will have to split one thin paraxial lens into a series of real lenses to accommodate [»] optical aberrations. Finally, from the generated optical assembly, the mechanical engineer will determine the best way to hold the lenses and implement the various degree of freedom required for either alignment or operations (e.g. focus ring, scanning mirror etc.). He also has the responsibility to respect a positioning tolerance budget allocated in the technical specifications because positioning errors will deteriorate the system performances such as its resolution.

Described like that, it looks like a chain that operates top-down like a cascade of events. If you have read my former essay on [»] amateur project lifecycles you already know that waterfall-like models such as this only applies when you have a perfect mastering of what you are doing. As soon as you innovate, the waterfall model breaks down and you have to iterate through several designs. For instance, the optical design might generate a tolerance budget that is too tight for the mechanical engineer to cope with, or the system engineer might be asking for too much degrees of freedom on a single element which results in an overly-complicated system at the end. This is an important aspect to keep in mind as we progress in the #DevOptical series.

You might be wondering what kind of tools all these people are using to get their job done. You might be surprised by the answer!

The mechanical design is done is software like SolidWorks or equivalent. These are already well known and there is probably little to say about them. I like SolidWorks but a lifetime license cost about 3,500 EUR or more which can be difficult for amateur but is still ok when you start your business. FreeCAD is unfortunately not a suitable replacement, at least as long as their assembly/mate engine is not operational.

The system engineer best tool is… Microsoft Excel! Since most of the job consists of deriving formula and following specifications, I do spend a lot of my time on Excel. Matlab is of some help too and a blackboard is also essential to set up your ideas. There is however and to my knowledge, no specific tools for that part of the job. For instance, I have one Excel spreadsheet to design grating-based spectrometers that I made when working on OpenRAMAN and I re-used it several time later for my daytime job.

The optical design is done in raytracing software like ZEMAX OpticsStudio, CodeV or OSLO. The market is clearly dominated by the two formers and OSLO is still included in this list because they have a free educational version which still attract some people although it is extremely limited in what it can do. I have no experience with CodeV but I know relatively well OpticsStudio. Interestingly, since 2020 you would pay a single fee for a lifetime license of about 5,000 EUR for the Standard version and 10,000 EUR for the Pro version. Starting 2021 they changed to an annual fee model of about 2,800 EUR/yr for the standard product and 5,000 EUR/yr for the full product (as quoted from the official website [∞] here). I however heard rumours at the office that starting 2022 the price of the licenses will double!

You might be thinking that for this kind of price tags it must be really good software and that the standard version might already be enough for your business. Well, still according to the official website, the standard version is only good enough to optimize “simple lenses” with “basic raytracing” and if you want to do more complex things like camera lenses and telescopes you need the pro version. Also, I have always found OpticsStudio to be very cumbersome to use. Do you remember when I said that optical engineers were replacing thin lenses by real ones? There is absolutely no feature in OpticsStudio to do that for you automatically. You can optimize lens but you have to work on both surfaces separately and create merit functions to both optimize aberrations and keep the focal length to the desired value. The Merit Function editor is by the way everything but user friendly so you typically loose hours doing something that should just take a mouse click.

This is probably the largest thing I want to address in the #DevOptical series: how to easily transform a system sketch into a pre-baked set of lenses. As an illustration, Figure 2 shows a telecentric long working distance objective design that was automatically generated by an algorithm that first started by sketching the system with thin lenses and replacing them with real lenses after. The program even detected some potential aberrations and started splitting one lens into two to lower the spherical aberration as explained [»] here. The system is not optimized yet but it is already very close to a working solution. It also took a fraction of a second to generate this design from just a few user inputs (field of view, numerical aperture, working distance and effective focal length).

You might ask how the program came up knowing how it should organize the thin lenses to make a 100 mm focal-length telecentric 300 mm working distance objective? In fact, I told him how to via what I call a template. Templates are system designs that were already solved by humans (me) and have a mathematical representation of all the required quantities. The template knows it requires X thin lenses and based on your inputs it uses its formulas to compute the focal lengths and spacing of the elements. Template enforce re-usage of former knowledge and help gaining time. They also are a key part of the #DevOptical series. Projecting ourselves into the future, you would have templates for everything: microscopy objective, telephoto lenses, spectroscope, fiber probe etc. Just plug-in some specifications and you’d have a starting design within a fraction of a second.

But why stopping there? Let us be crazy and think modular! Imagine you have a template for a spectroscope. Based on your inputs, it will suggest a grating groove frequency, angles, a slit, and two thin lenses for collimation and imaging as I mentioned earlier here. In the previous example I said the program replaced the thin lenses by one or more lenses but we could even think wider and replace the thin lens by a template itself. The program would automatically adjust all settings to match every subsystem together.

And if you believe I’m crazy you are far from having heard all the ideas I would like to put in #DevOptical! For instance, I would also like to automate mechanical design as well. The mechanical design job is not very different from the optical designer one and if I can automate the latter there is no reason not to automate the former.

Automation is probably the word to remember here and the philosophy is taken directly from the DevOps world of IT. Let an algorithm do as much as it can so that you have more free time to allocate on the more delicate tasks. The idea of #DevOptical is not to replace softwares like OpticsStudio or SolidWorks but only to pre-bake solutions for these software: pre-generate sketches from previous knowledge, pre-assemble STEP files for the mounting of objectives, pre-fill the merit function tables etc. There is really a gap there to be filled in current softwares.

The consequence of the DevOps IT approach is that it tends to merge the various jobs by allowing programmers to do a bit of everything. There will always be a need for code security audits, management of database and server etc. but instead of having full teams doing that all day you could have much less specialized people since most of the tasks would be automated. I think the same will become true when applying the #DevOptical philosophy. You will always need optical engineers, system engineers and mechanical engineers but they will have their time best spend on where they really add value.

And since not everyone necessarily thing in terms of business operations (myself first with this website), I’m also leaving plenty of room for amateurs and university labs in this #DevOptical series. I would like that any individual with limited experience in optics be able to build from scratch a full optical system using catalogs of stock parts and optimization algorithm to take the best combination of off-the-shelves lenses for the application. So the software will not implement all the nifty features of raytracing software or mechanical design software but will implement at least the major features such that you don’t absolutely need them if you can’t afford them.

This is going to be an exciting journey and I will share my progress with you step by step on this website, so be sure to stay tuned in for updates! I will first focus my efforts on describing all the important features and test them separately. Then, when everything will be clear enough in my head, I will release a full software that does all the things I have been talking about.

I would like to give a big thanks to James, Daniel, Naif, Lilith, Cam and Samuel who have supported this post through [∞] Patreon. I also take the occasion to invite you to donate through Patreon, even as little as $1. I cannot stress it more, you can really help me to post more content and make more experiments!