I’m excited to announce that I’ll be giving a talk at PyCon 2017, on May 18 in Portland OR. The talk is based on a set of Jupyter Notebooks that I’ve developed over the past two years for use in my quantum mechanics class. As the talk comes together, and as I clean up and document the resources, I plan to write a series of posts describing how I use the libraries (like QuTiP) that make these lessons possible, the process I used to revise these resources, and the things I learned along the way about teaching students python and teaching students with python.
For more on how this figure was created, see my earlier post on publication-ready 3D figures from Matplotlib. Finally, the source for this figure is available as an Ipython notebook in our github repository:
I use numerical fast fourier transforms (i.e., FFTs) a lot in optics research and so far I’ve been doing the hard-hitting numerical work in c (or even Fortran… laugh if you must but it’s fast!). As I get more comfortable in python, and numpy in particular, I’ve decided to begin porting some projects to python. This code will have lots of nice python features that will make analyzing and presenting results much easier. To keep things moving along quickly, I’m using compiled numerical libraries for the FFT. In particular, I have both FFTW and Intel MKL libraries to use. Now to get them into python…
Fortunately, less than two months ago, Henry Gomersall posted his python wrappers for FFTW so I gave pyFFTW a shot. Working primarily on the mac platform wasn’t a major obstacle but there are some steps I had to sort out in order to get good performance from the combination (pyFFTW and FFTW itself). This post describes what ultimately worked, and has some tips that may be useful to others in the same situation.
At first, I was running a 32-bit version of python from the Enthought Python Distribution (EPD). I ran at 32-bits because some of their toolchain is not 64-bit compatible. It turns out I don’t use much of that toolchain at the moment, and there is a new alternative that makes this problem moot. In any case, my first attempt to install pyFFTW resulted in no performance improvement over stock numpy fft libraries. I compiled FFTW using many combinations of compiler flags and never saw more than a 5% speedup over numpy’s fft.
Next I upgraded to 64-bit python (via EPD) and installed macports FFTW libraries. Note, to have the full functionality of pyFFTW, be sure to install all three fftw-3 ports: fftw-3, fftw-3-long, and fftw-3-single. These provide FFT routines for three different precisions, double, long-double, and single, respectively.
With 64-bit python, and macports libraries, I have a fast pyFFTW install. FFTs take about 1/5 the time using pyFFTW compared to using stock numpy fft routines. This makes it all worth it. If you are playing with FFTW on mac, I can at least vouch for the macports FFTW libraries and I definitely recommend Henry’s pyFFTW if you’re using python. These wrappers keep the flexibility of FFTW without being hard to use.
I can’t say for sure if 64-bit python, or the macports FFTW libraries had a bigger impact. My hunch is that 64-bit code helps the most, but it is also likely that I didn’t compile FFTW in a very optimal way when I did it myself. The bottom line is that the macports FFTW install works great, and saves a lot of compile time.
For what it’s worth, I’m working to sort out the relevant compile flag options. The macports libraries were compiled with the following configure options:
--enable-threads --disable-fortran --enable-shared
-fno-common -O3 -fomit-frame-pointer -fstrict-aliasing
If you are interested in compiling your own FFTW libraries on Mac, these should be a good starting point. I have tested these configure options (but not the CFLAGS) with Xcode 4.3 (gcc 4.2) and they are definitely not as fast as the macports libraries. The pyFFTW test suite runs at 11.36 ms compared to 5.56 ms with macports FFTW. Surely the O3 flag, and others are important, but I wanted to try with a stock command line first.
In a future post I’ll compare FFTW compiled with gnu compilers to that compiled with Intel compilers. I don’t expect another 5x speed boost, but it may make a difference in my code where I typically run tens of thousands of FFTs per simulation.
I have been using python more and more in my scientific work. This has been enabled by several excellent resources. The most important resource is the Enthought Python Distribution (EPD). The EPD makes it trivially easy to have a complete python installation that includes many scientific packages. Best of all, the EPD is available for free under an Academic license. All software included in the EPD is open-source so it is straightforward to install an equivalent set of packages; the only difference is convenience. Enthought also offers many tutorials, webinars, and other support resources for scientific python.
Here, I have put together some of my favorite resources, along with a brief presentation that illustrates the power of SciPy/Numpy through several examples based on my own various projects.
I’ve been having some fun with a Sparkfun Serial-enabled LCD screen (LCD-09393, $24.95). This little package will write out whatever you send along a serial data line. So this means you can add an LCD to a project with only three wires: +V, GND, and RX (serial receive). In the real world, I’m hoping to use these LCDs in some lab instruments that we’ll be building in the spring semester. In particular, I’m looking at an arduino-based frequency counter. I also want to explore an arduino-based PID controller for various lab projects (temp. control, etc.).
My first test, however, was just getting the LCD to work. And then, I wanted to make it show my Twitter status. I’ve been using twitter (DrDawes) to post my office status and give students updates as to where I am or when I may be around again. This has been helpful since my research lab is in another building and I tend to be available but it may not look like it since I’m not in the physics building. This way if I want to step over to the lab, I can simply send an update, and save people the trouble of tracking me down. The rub is that not everyone has twitter, and sometimes people just come to my office anyway. That said, my goal is to post a 16×2 LCD screen on my door so that my availability status (formerly written on a whiteboard, or post-it) can be more 21st century.