My friend and colleague Bill Paxton died on July 23, 2025. In retirement Bill found himself as an accidental astrophysicist and my own path was fortunate enough to have intersected that segment of his life.
During the summer of 2008 I heard about some new stellar evolution software being developed at KITP in Santa Barbara. I installed it and emailed the author with some comments and questions. In response to my message, Bill wrote:
You’re one of the first brave souls to try to use mesa, so it will be a learning process for both of us!
And wonderfully, for the next 13 years, it was. Before I left astrophysics in 2021, collaboration with Bill in some form or another was a near-constant part of my career. We exchanged thousands of emails and spent many hours working together during my visits to KITP.
Bill liked writing software. Bill was good at writing software. Bill was fast at writing software. A big part of working with Bill was simply keeping up with Bill! Someone would tell Bill something hadn’t been done (or sometimes couldn’t be done) and he’d take that as a challenge and then go off and do it. I will consider myself fortunate to maintain a fraction of Bill’s curiosity and drive.
In this photo from 2016, I (left) am wearing one of Bill’s autographed MESA baseball caps, as Lars Bildsten (center) prepares to hand out more, and Bill Paxton (right) solemnly looks on.
Bill shared this video clip in a context now lost to me. But it has remained in my browser bookmarks and I think of him every time I stumble across it.
There is a time for everything, a time to summon and a time to say goodbye.
I took my first fully autonomous Waymo ride in San Francisco! Watching the empty car pull up and then being alone inside was an amazing feeling. The peace and quiet gave me a chance to read a draft of the upcoming MESA instrument paper.
The following important result was part of this recent arXiv posting.
While in graduate school at Berkeley, I was working on modifying the
ZEUS-MP2 code to include an $\alpha$-viscosity treatment in preparation for work evolving white dwarf merger remnants.
I ran many test problems that followed the evolution of the
equilibrium torus solutions considered by Papaloizou and Pringle (1984).
During one such experiment, my analysis scripts produced the following
contour plot of density. The image has been manipulated only by
rotation (such that the equatorial plane is now vertical) and cropping
(to focus attention on the relevant feature).
This figure shows the appearance of a powerful and mysterious otter,
who is perhaps blowing the fiery bubble that will give rise to our
universe. Future work should explore whether spectral methods
are more likely to produce such illuminating results.
As part of testing the MESA stellar evolution
code, we want to provide the
developers with easy access to the output associated with failing
tests. These logs come from the many different machines that MESA is
tested on (ranging from a Raspberry Pi to large scientific computing
clusters). As such, they can be especially useful in the case of
failures that are not easy for an individual developer to reproduce
(for example, because the failure is intermittent or because it only
occurs with a specific operating system or compiler). Even in the
case of easily reproducible failures, this saves a developer the time
needed to re-run the case and trigger the failure themselves.
Our mesa_test testing framework manages the test runs and
then (upon failure) transmits the logs to a remote server that makes
them publicly available.
This MESA logs service is provided using the following
approach, hosted on a Digital Ocean droplet (the same one that
serves this website).
A Flask app (served with Gunicorn and
Nginx) provides a route that accepts JSON POST requests. The
expected JSON contains information about the computer, commit, and
test case along with the base64-encoded logs.
Upon receiving a correctly formatted request (authenticated via a
secret API key), the Flask app writes the logs to disk on a small
Digital Ocean block storage volume. Nginx also serves the contents of
this volume, making the logs available at a standardized path
such that our testing dashboard can easily detect whether
logs exist for a particular failure with an HTTP HEAD request.
Because these files are intended for diagnosing failures, they are
only retained for a limited time, under the assumption their utility
is largely exhausted after issues are fixed. A systemd timer
prunes log files older than 60 days.
