Wtih this tech talk, I would like to offer some perspective on building a physical modeling framework with Open Source Software. This is something I’ve done for a very long time and found very rewarding.
First, we need to go back to why would you do it? Isn’t Zemax, Comsol or VirtualLab enough? In the context of this talk, I think they are excellent at solving some focused and very targeted problems, while with tools like Matlab or its OSS alternative, Octave, you can address the “big picture” questions. For example, with Zemax you can design an objective. For this you had to add a number of parameters. Some factors, like field size or magnification, were obvious. Others, such as numerical aperture or distortion, may have been harder to pin down. And then are those that rely on educated guesses, eventually finding their way into the merit function. To actually “derive” the numerical aperture, physical modeling can help you to take on the big picture questions which you can use to connect customer requirements to the parameters used for lens design.
But let’s now talk Octave. What are its advantages and drawbacks, specifically then compared to Matlab. One is speed. Matlab is the more mature product, with more resources put into optimizing. If features a mature Just-in-Time compiler while the one which used to be available for Octave was removed due to difficulties of maturing and maintaining it. Here though, it can be worth remembering the three rules of optimization,
For this reason, I don’t think we should be concerned about the speed differences between these tools. Yes, for targeted benchmarks, Matlab will come out on top. Most of the time, in real life problem solving, the difference will not be that dramatic, and where it happens, the interface to compiled binaries is actually very simple for Octave while it is significantly less so with Matlab. One very specific difference is that you have to start the Matlab session as a debugging session. With Octave, you can just “attach” and “detach” a debugger whenever you need it.
Something we don’t talk often enough about is spreading the know-how throughout an organization. Most companies will accept a license cost of 50k or 100k for one or more developers that need a specific tool but quite often, many more people would benefit from knowing how things work. The soft value of OSS is that it can be deployed anywhere and at any time, and there is value in that. For example, programmers may need realistic input to test their code before they can get it from a product that doesn’t even yet exists. A meeting where we can demonstrate how things actually work will contribute to better decisions and align an organization toward the common goal more effectively than trying to convince the attendees through logical arguments and coherent reasoning. Remember, “Convince a man against his will, He is of the same opinion still”.
Ok, enough of that soft-talk. Let’s get down to the nitty-gritty. I won’t talk about how you parallelize your code in Octave (or Matlab), this is covered all over the internet. What I will cover is the experience I have with interfacing C code and write code that is easy to read. In addition, there is also the data type aspect. In Octave, the default type is a double precision float. While this is often a good start, it is often not needed for physical modeling, and if you find yourself needing it, I would consider it an indicator that the numerical methods should be reviewed. In any case, interfacing a dynamically-typed language like Octave with a statically-typed language like C at least needs some consideration before you attempt some production level code.
So, lets dive deeper still. Should you use the mex compiler or a tool like GNU compiler, gcc? Here, I would suggest building your code with the GNU compiler or Clang. The Mex compiler does not support some very useful attributes like “__attribute__((cleanup))” which lets you allocate and forget. We all forget so why not acknowledge that and code in a way that lets you get away with it. Also, there is no “make” or any other build tool for Octave. The small amount of preparation to setup a build environment (like make/Makefile) will pay off.
Let start with the build environment. The make build tool is often good enough for the type of code you may build to interface with Octave,
This piece of Makefile is straight out of one of the examples you will find on our gitlab server (write an email with preferred username to contact to get access).
All mex functions have the same prototype. Put that into a template like the one below, and you will be up and compiling in no time. For straight C code, using enum, as always, makes the code easier to read. In[in_sing_values] is much easier to read than In[0], and enum even saves you typing in the numbers.
But lets make it a little more interesting. How do we handle various types. To tackle this, the mex interface has a function that returns the variable type called mxGetClassID(). However, it’s up to us to still implement the code for each type. For small pieces of code, I personally wouldn’t blink to do copy-and-paste and substitute the type using the editor.
For more complex code, definitely consider using the C pre-processor and some boilerplate. Below is one example,
and then, inside your boilderplate code, use,
whenever you need to call the type-abstracted function.
Finally, define all the variants you need with,
And inside the mex-interface function,
There is no question that copy-and-paste-substitute is faster than adding the boilerplate. There is also no question that the time will come where you will debug one copy of the code, forgetting to change the code for the other types, and debugging that will take much longer than adding the boilerplate.
Open-source software has some big perks when it comes to deployment, and a lot of tools are impressively mature. For example, Octave makes developing physical optics projects a breeze with its easy-to-use plotting and data inspection tools. Plus, it works seamlessly with powerful languages like C or C++, so you can tackle performance bottlenecks or dive into advanced features like parallel programming when you really need to crunch some heavy data.
With OSS, you get flexibility, efficiency, and access to cutting-edge tools—all of which can seriously boost your productivity and help you build better projects..
If you find that this is something that would benefit your organization, please contact us and to find out how Senslogic may be able to support you.
Open Tools for the WaveMe Ecosystem Starting today, we are moving WaveMe templates and all open-source code to a self-hosted…
In this tech-talk, I would like to discuss how (and probably how not to) develop an optical distortion correction. It…
Introduction This tech-talk is about why simple isn't always easy and what the Shack-Hartmann (SH) module in WaveMe must do…
Why choose Senslogic? A very reasonable question indeed. There is no shortage of established companies offering customized services that can…
About This Tech-Talk Spatial light modulators (SLMs) are active optical components that can alter a light beam’s amplitude, phase, or…