Why XAOSIM

When I started my PhD in astronomy (circa 2002), the world of software was of course different than what it is today: python certainly wasn't the norm in the field of astrophysics and the great majority of astronomers were using data reduction scripts using tools like IRAF (which I never used) or the more sophisticated proprietary IDL language (which I unfortunately eventually came to use). People writing models were using Fortran which I practiced a bit during my DEA at the University of Marseille. Coming from an engineering school where I had primarily learned to program in C, it was natural for me to stick to that tool and write software in that language. One of the first things I did as part of a summer internship at Observatoire de Haute Provence was to write a curvature wavefront sensor piece of software from scratch. Not aware of the existence of already existing bricks that would have saved me some time and effort, I wrote my own crude versions of libraries to read/write FITS files and compute several flavors of Fourier Transforms, which is pretty much all of what was needed in order to work in this field. It got the job done and for an internship, it wasn't half bad.

C remained my primary programming language for other internships and later all the work I did during my PhD. Over the course of the 2001 summer as part of another intership, I wrote some software that was simulating the effect of "sun spots" and non-radial pulsations on the radial velocity profiles of stars. I still remember the bewildered faces of my internship review committee at the University when they understood that the results I was showing to them were coming from software I had written. I never made a big deal out of it but there, I understood that the ability to write software was a bit like a superpower giving me an edge that I should try to keep as sharp as possible!

As part of my PhD, I came to spend some time at the Subaru Telescope to work with Olivier Guyon, another avid C programmer a few years senior to me who, had pretty much done the same thing I had on his side… except that he might be getting carried away. What he was developing at the time was what looked like a specialized substitute for IDL: a programming environment with a REPL that was powered by fast C code to manipulate images and FITS files… called Cfits. A lot of the intern students that came to Subaru came to love, hate and dread Cfits, that Olivier still maintains today, although it is now very different than what it was when I first used it.

My first postdoc at Cornell with James Lloyd led me to encounter the IDL programming language. My project was to contribute to the data reduction pipeline initially written by Peter Tuthill and John Monnier for the reduction and interpretation of non redundant masking interferometry data. This "Sydney pipeline" as it is still refered to today was my first truly collaborative software project: I learned to use CVS to share my contributions with other users, which was great. I painfully adapted to the clunky structure and organization of the IDL language… but came to recognize the benefits of a high level language… and appreciate the benefits of well written libraries such as astrolib that, as its name suggests, featured many useful things for astronomy.

Circa 2009-2010, I started investigating the python language: I began writing a simple adaptation of the "Sydney pipeline" in python as an exercise and used that to build up the first kernel-phase data reduction software… at the time, my code probably looked very unpythonic and I was heavily relying on one of those cheatsheets "python for IDL developpers", but it looked cleaner and was easier to read and parse. Understanding the object model of python and how it differs from what I knew of C++ was a major shift in my software practice and I started putting together what is now another important (to me!) python package called XARA. With that skill in hand, I realized that I was a lot faster and a lot more effective developing in python than writing in C or in C++ and decided to make this my primary language. I wrote many pieces of software running the SCExAO instrument in python, from simple command line tools running linear actuators to fairly sophisticated GUIs used for wavefront control.

XAOSIM owes its existence to the work that Olivier Guyon and I did on SCExAO. Our naïve initial design assumed that because it would comfortably sit behind the telescope AO188 adaptive optics system, SCExAO would be able to do wonders with a coronagraph and a tune-up DM moving slowly to compensate for slow drifts. At the time, I think we were still using the XPA messaging system to pipe images acquired by our focal plane IR camera into a DS9 GUI. In the lab, I had observed that this was resulting in memory leakage when running in X11… but discovered that this did not occur when running in a VNC session so that solution worked out for a while for us. Our cameras were noisy, featuring a massive offset but were able to take short exposure, significantly less than a second.

This was an eye-opening and (at least for me!) a very discouraging experience: the use of a fast IR camera behind an AO system revealed that although in average, the AO was doing a great job, short exposure were absolute garbage. There was the real reason why high-contrast imaging from the ground was never as good as what we were hoping for. There was no way we'd be able to do anything sensible that way. This forced our hand and we started looking into ways of implementing fast wavefront control loops as part of our own instrument.

During one of our weathered out observing nights in the control room at the summit, we started boincing ideas about how to efficiently exchange information amongst the many devices (half a dozen cameras, and a deformable mirror) that we had managed to stuff into the SCExAO enclosure, using a kind of universal data format, very much inspired by the FITS file format: a simple header that describes the content of the bulk of the data, the data itself and a bunch of optional keywords. This is all you need really to exchange images from a camera from one process to the other, or to drive a deformable mirror. Because of the R&D approach, that required simultaneous progress on the low-level and the high-level control software, we couldn't afford to design a true real time computer (RTC) and were looking for a solution compatible with a conventional operating system. Having these data available on a ramdisk on a Linux box meant that access should be fast and using memory mapping techniques available both in C and python meant that we could write hybrid software. This is pretty much how we designed the concept of shared memory data structure, which is now a central feature of SCExAO.

This has enabled a very powerful idea: this shared memory data structure has made it possible to multiplex the control of the deformable mirror. We have indeed designed the software so that from the point of view of the end user, it is as if SCExAO was equiped with a large number (possibily infinite) of independent virtual deformable mirrors! This is a major feature that make it possible to run in parallel several wavefront control loops and handle commands from the a turbulence simulator, the pyramid wavefront sensor, the coronagraphic low order wavefront sensor, incoherent reference speckle modulation grid, and several other flavors of focal plane based wavefront sensors including speckle nulling.

XAOSIM is a diffraction simulation package that integrates the original python implementation of the shared memory data structure called shmlib. I say first because a bunch of other people have now written their own versions… these are probably better written than my shmlib, but it is so well integrated to many tools I rely on on a daily basis that I don't really feel like changing the interfaces. Like the rest of XAOSIM this shared memory library keeps being upgraded and updated so it's far from being a dead piece of software.

Example of speckle nulling GUI developed thanks to XAOSIM and currently running on SCExAO: this piece of software interacts with the internal IR focal camera (half-circle display on the left) and one channel of the DM (display on the right, being carved out by a machine gun) to modulate speckles in the selected part of the image.

I initially wrote XAOSIM as a way to emulate SCExAO on my laptop so as to be able to develop wavefront control software on the go. XAOSIM is a simulation environment that integrates a dynamic atmospheric phase screen, a deformable mirror (possibly segmented) and several types of cameras (imaging, coronagraphic and shack-hartman). All of these virtual devices when created, communicate with one another using the exact same shared memory data structure that SCExAO relies on to operate. This turns out to be a very useful feature that has allowed me to develop wavefront control software for SCExAO using its XAOSIM simulated version. Porting this to SCExAO is a trivial operation. I have generalized the design principles to a wide range of setups that I have used to emulate other AO projects.

Needless to say I primarily wrote this software for my own research and for SCExAO: the shared memory library of XAOSIM powers several of the python programs that need to read images from cameras and/or interact with the deformable mirror. But simulating diffraction dominated images in the presence of perturbation and wavefront control is such a fundamental toolkit that students and postdocs working within my extended circle of collaboration have become regular users. A lot of the recently added features were included because a specific student project required it so XAOSIM owes a lot to its relatively small but active community of users!

Here you'll see that I indeed wrote this package for SCExAO: in just three lines of code, including a library import, one creates an instance of SCExAO using one of the premade templates, and starts a live simulation that runs a couple of independent threads: a turbulent phase screen, an IR camera with a H-band filter and a 16.7 mas/pixel plate scale, and a 50x50 actuator DM that one can use to apply corrections and modulations. Each thread creates one or more shared memory data structures to exchange information among each other as well as with the end user.

import xaosim as xs
scexao = xs.instrument("SCExAO", csz=480)
scexao.start(delay=0.1)

You can then use one of the provided external utilities to visualize the content of any of the shared memory data structures, that appear, by default, in the /dev/shm directory:

shmview /dev/shm/scexao_ircam.im.shm &

Will open a GUI window with a live display that shows a somewhat well corrected turbulent image being refreshed 10 times per second (as set by the delay=0.1 argument to the start() function.

Once you are satisfied with what you just saw, you can go back to the python shell and turn off the simulation that will otherwise keep your CPU happily busy for as long as it can:

scexao.stop()   # stops all the threads that were emulating live devices
scexao.close()  # closes the link to shared memory structures and erases them

After which your python session can be cleanly shut down without any process still running in the background.

If that looks like the kind of tool you might want to use for your own experiments, then read along!

Back to index!