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.
I have literally no skin in the game here, but here's another interesting group that totally bailed on a similar project because I guess they hated Julia so much. Good to see something else crop up.
Ah, that's too bad, but I can't really blame them. Going from a fully-featured Python codebase they already had in https://github.com/brandondube/prysm and translating into Julia would need to be motivated by much more than speed - after all the limiting factor here is FFT and heavy computations like cis, so I'm pleasantly surprised they reported gains from their simple port compared to numpy. It's also much easier to go from a C/C++ computational code to Julia than it is from a Python one, because the mental performance models are more similar.
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.
Interesting! This really speaks to me. In my opinion your language can have the most foreign concepts or unusual ways how you should optimize code.
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).
I think people often underestimate (or just plain don't know about) the degree to which a multiple-dispatch-based programming language like Julia effectively implies its whole own dispatch-oriented programming paradigm, with both some amazing advantages (composability [1], and an IMO excellent balance of speed and interactivity when combined with JAOT compilation), but also some entirely new pitfalls to watch out for (particularly, type-instability [2,3]). Meanwhile, some habits and code patterns that may be seen as "best practices" in Python, Matlab can be detrimental and lead to excess allocations in Julia [4], so it may almost be easier to switch to Julia (and get good performance from day 1) if you are coming from a language like C where you are used to thinking about allocations, in-place methods, and loops being fast.
Things are definitely stabilizing a bit post-1.0, but it's still a young language, so it'll take a while for documentation to fully catch up; in the meanwhile, the best option in my experience has been to lurk the various chat forums (slack/zulip/etc. [5]) and pick up best-practices from the folks on the cutting edge by osmosis.
As an avid Rust and Julia user, I often use Rust even when it's harder because I know I'll never get stuck. And when it finally compiles I'll be rewarded by ludicrous speed.
Hell, even C has decent man pages for the standard library.
Although in Julia's defense (or is it?), they've changed the language a lot over the versions from 0.4 to 1.5, so maybe it's hard to keep docs up to date.
The language has been pretty stable (no breaking changes) since 1.0. The bigger issue is that unlike many of the other newer programming languages (Go, Rust, Swift etc) Julia doesn't have a fortune 500 company sponsoring it, so there aren't any people who's job is documentation. It's all open-source. Hopefully this is fixable through Google Summer of Docs and/or the community sponsoring people to work on this.
Judging by the number of contributors, only 2 people are contributing to that project. It could be that other teams don't have their work open-sourced.
We use OpticSim in my group to simulate complex optical systems that we are designing. We're the only group I know of at Microsoft Research Redmond doing optical research.
This is interesting zemax costs ~$5k, if you want up to date material and part catalogues that's a yearly fee. I wonder if MS also keeps those catalogues up to date. This seems to largely be the selling arguments of the commercial offerings.
I'm a long time Zemax user. The subscription is just a cost of doing business for my employer.
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.
OpticSim automatically downloads publicly available glass catalogs when you first build the package. The current list is Nikon, Schott, Sumita, Ohara, and Hoya.
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.
We do optical simulation to understand the behavior of optical systems, along input and output parameters that matter to the goals of the system.
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.
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.
OpticSim can model all forms of geometric aberration including chromatic aberration. We are considering adding some ability to handle diffraction but it is not the highest priority now.
See also:
- https://diffeq.sciml.ai/stable/
- https://juliadynamics.github.io/DynamicalSystems.jl/latest/
- https://clima.github.io/OceananigansDocumentation/stable/
etc