Rings


I've seen many comments on this beautiful picture from Cassini, but I think the best has been Emily Lakdawalla's. What caught my attention in particular was where she started talking about the density of Saturn's rings: the inner edge of the B ring is so dense the ring particles are more or less touching, so that an astronaut could climb from one to the next. Now isn't that a cool mental image?

Full post

Plasma and TVs


When I think of television, I picture the grungy old 70s trash-rescue we had at home when I was a kid (complete with pinkish fringes from an ill-advised magnet demonstration). But it seems TV technology has advanced significantly: DVB, HDTV, LCD screens, plasma screens... there is an interesting link between the last of these and some of the brightest "stars" in the sky.

A plasma screen is a large array of cells full of low-pressure gas, with electrodes on either side, and phosphors coating the inside of the front. To turn on a pixel, you apply a voltage across that cell, ionizing the gas. The flowing current accelerates the ions, which crash into the phosphors, which then light up. (A similar process occurs in the old CRT TV I grew up with, except there it was electrons hitting the phosphors, and they were focused into a beam that sept across all the pixels.)

What interests me, though, is that some of the early plasma screens had memory: you could put an image up on them, and then simply supply a holding voltage, and the image would stay indefinitely. By contrast, CRTs (normally) need the image constantly refreshed. Not a problem for computers, of course, but memory is extremely tricky to build. This is why you shouldn't leave a VCR on pause for too long: in order to keep the picture on screen, the head needs to keep spinning against the same piece of tape, constantly rereading the same picture.

Aside for younger readers: that box under an old TV that looks like a toaster on its side is a VCR. It records video on a spool of magnetic tape. Under no circumstances should you put bread in it.

These early plasma screens were on/off - no shades of gray, each pixel was either on or off. The way the memory worked was this: a high voltage will strip electrons off their atoms and turn a gas into a plasma. But once the electrons are loose, the plasma is very conductive, and a quite modest voltage will keep a current flowing, which keeps the plasma ionized. But if you shut off the voltage, the electrons will recombine with their atoms and you get a non-conductive gas - across which you can apply exactly the same modest voltage and get no current. So the information about the brightness of the pixel is stored in the ionization state of the gas.

What does this have to do with astronomy? Well, there are a number of kinds of "nova", astronomical events that make what looks like a new star appear in the sky. The one I'm going to talk about is a "dwarf nova". This is actually two stars orbiting very close to one another. One is a white dwarf, incredibly small and dense, and the stars are so close together that the matter on the surface of the bigger (less-dense) star actually "overflows" and falls on the white dwarf. Since the white dwarf is so small, it has a very deep gravity well and this process releases a tremendous amount of energy.

It turns out it's hard for matter to actually fall onto a white dwarf (or a neutron star or black hole). In spite of the strong gravity, the matter can't just fall in because of conservation of angular momentum: as the matter moves inward, if it keeps its angular momentum it must go around more quickly, which tends to move it outward. In order for matter to fall in, it must get rid of its angular momentum somehow.

It turns out that if the gas falling in isn't ionized, then there's no way to get rid of that angular momentum quickly enough to make the bright novas we see. But if you ionize the gas, well, there's still considerable debate about exactly what happens, but since the plasma is conductive, you open the door to all kinds of magnetic effects. In particular, magnetic fields can connect adjacent regions of the inflowing material, providing enough viscosity to transport lots of angular momentum outward.

In some systems, it looks like this is what's going on: you have a disk of infalling material, it's ionized, and so the material flows steadily and rapidly down onto the surface of the star, producing a reasonably steady, bright, source. (I recently heard John Thorstensen describe this as "a flat, gravity-powered star", which I think is a very nice way to think of it.) But what happens when the companion cannot keep up with the amount of matter that the disk is gobbling up?

Well, here we return to the plasma TVs: what you get is a system with two states. In one state (most of the time), gas is overflowing into the disk, but the disk isn't ionized, so not much gas can fall in onto the white dwarf, and the system is dim. But as this continues, the density of the disk increases, and eventually the trickle releases enough energy to ionize some of the disk. This ionized material then starts falling in rapidly, releasing more energy, so that the whole disk is soon ionized. Now the system becomes very bright, with the ionized matter pouring down onto the white dwarf, and we see a "nova". But since the companion can't supply much gas, soon the disk will empty out, cool off, and stop being ionized.

So: a two-state system, stable (for a while) in either ionized or non-ionized states. When ionized it's bright; when the ionization shuts off it's dim. Just like a plasma TV? Well, maybe not. For one thing plasma TVs don't emit nearly as many X-rays.

Full post

Definitions


The "demotion" of Pluto received a lot of press. After all, we all learned in school that there were nine planets, and it seems bizarre to have one of them cast out of the heavens. But in fact this is not the first time this redefinition has happened, and for similar reasons.

Classically, the Greeks thought there were seven planets: the Sun, the Moon, Mercury, Venus, Mars, Jupiter, and Saturn. Copernicus' heliocentrism dethroned the Sun and Moon but made the Earth into a planet, bringing the tally to six (the satellites of Jupiter were occasionally called "planets" but for the most part people settled on "satellites"). The discovery of Uranus brought it to seven, and in 1801 Ceres was found, in just the place Bode's rule predicted another planet. So eight planets it was.

Unfortunately, shortly thereafter, Pallas, Juno, and Vesta turned up, in just the same region. The idea that there could be four planets sharing pretty much the same orbit bothered people, but they still seemed like planets. So eleven it was, and stayed that way for a while. Neptune's discovery in 1846 added one to the total but didn't pose a problem.

But around 1850, a whole series of new bodies turned up, and it became clear that Ceres, Pallas, Juno, and Vesta were just the largest in a very large family of similar bodies. So they were demoted from planet status and called "minor planets" or "asteroids".

From there on you know the story: in 1930, Pluto was discovered and assumed to be large enough to perturb the orbit of Neptune, and so was labelled a planet. As time went on it became clear that Pluto was really rather small, but it was the discovery that there are many more trans-Neptunian objects just like Pluto that posed a problem with that classification. So the new category of "dwarf planet" was created, and Pluto was put in it, along with Ceres and a few recently-discovered trans-Neptunian objects.

Some people view this as a demotion of Pluto. I view it as an elevation of Ceres, and a reminder to look at the asteroids as interesting objects. After all, all those smaller bodies in the Solar System give us lots of information on its formation and early composition; the Murchison meteorite was full of fascinating organic compounds, shedding light on the origin of life on Earth. If you like to imagine a future for humans in space, the shallow gravity wells of asteroids mean they're relatively easy to visit and extract minerals from.

Full post

Curve fitting, part 2: Quality control the dumb way


When you're fitting a curve to data, it's important to know not just which curve fits the data most closely, but also how well the data constrains the curve, and how good a fit the curve actually is. This is plainly impossible if you don't know how good your data is, and estimating the uncertainties on experimental data is often very difficult, but I'm going to assume for the moment that you have done that. The problem now is to understand the statistics of the fitting process. For the moment, I'm going to continue using the simple linear least-squares example I introduced in part 1.

In part 1, we found the parameters that minimized the sum of squares of differences between the data and our model. Now let's ask how close we can expect those parameters to be to the true parameters. There are statistics to do this quickly and conveniently, but for the moment I'm going to use the "everything looks like a nail" approach of direct simulation: I'll generate, say, 1000 fake data sets, and I'll fit a model to each one, and I'll record the parameters. Then I'll look at the distribution of these fitted parameters. (A brief aside: if you don't care about the details, just read right past these blocks of code. The text should be reasonably clear without them.)

def fit_many_parameters(model, parameters, fit_function, n):
result = np.zeros((n,len(parameters)))
for i in range(n):
fake_data = model.generate(parameters)
result[i] = fit_function(model, fake_data)

return result


Since in general we don't have access to the true model that generated our real data, I'm going to do this starting from our best-fit model. This is making the assumption that the errors in our fitting procedure are the same around the best-fit model are the same as the errors around the true model. Since we are doing linear fitting, this is exactly true, but in general it is only approximately true. But the degree to which it can be wrong is basically the degree to which your best-fit function differs from the true one, so it shouldn't be a problem unless you have a horrible fit. In this case you'll have to be more clever.

def plot_many_parameters(model, true_parameters):
data = model.generate(true_parameters)

fit_parameters = fit_linear_least_squares(model, data)

varied_parameters = fit_many_parameters(model, fit_parameters,
fit_linear_least_squares, 200)

plt.figure()
plt.plot(varied_parameters[:,0], varied_parameters[:,1],
".", label="simulated")

plt.errorbar([fit_parameters[0]],[fit_parameters[1]],
xerr=np.std(varied_parameters[:,0]),
yerr=np.std(varied_parameters[:,1]),
fmt="+", label="fit")
plt.plot([true_parameters[0]],[true_parameters[1]],"^", label="true")

plt.legend(loc="best")

def demo_least_squares_uncertainties():
true_parameters = np.array([2.,-1.])
n = 10
uncertainty = 0.1
model = SinCosModel(n,uncertainty)
plot_many_parameters(model, true_parameters, n, uncertainty)
plt.title("Fitted parameters to a sin/cos model")
plt.savefig("monte-carlo-errors-1.png")


The result:


You get a cloud of values, with the true value not in the center, but not too far out. It's tempting (and not totally unreasonable) to simply write down the standard deviations of each parameter as the uncertainties. But we were lucky. Let's try writing the model a little differently and running it again:

class CovariantSinusoidModel(SinCosModel):

def predicted_values(self, parameters):
a, b = parameters
xs = np.arange(self.n)/float(self.n)
return a*np.sin(2*np.pi*xs) + b*np.sin(2*np.pi*xs+0.1)

def demo_least_squares_uncertainties_covariant():
true_parameters = np.array([2.,-1.])
n = 10
uncertainty = 0.1
model = CovariantSinusoidModel(n,uncertainty)
plot_many_parameters(model, true_parameters)
plt.title("Fitted parameters to a covariant model")
plt.savefig("monte-carlo-errors-2.png")



Now the "cloud" of values is long and skinny and not aligned with either axis. Either parameter can vary by a lot, but if one is too high the other is almost certain to be too low - simply using standard deviations just doesn't describe this distribution well at all. The right answer is to write down a "correlation matrix" that describes not just the spread in each parameter but how much they're correlated with each other.

Describing these errors using standard deviations and a correlation matrix like this has the advantage that if you ignore the correlation matrix, you get a pessimistic estimate of the errors: You throw away the knowledge that the real answer lies on that nice little diagonal and you get a much larger error circle, but at least the real answer will still be in your error circle. Errors too big: weaker claims. Errors too small: serious embarrassment when someone finds the real answer isn't what you claimed.

It's worth pointing out that in this case, our parameters describe exactly the same set of solutions as the first did: any sinusoid can be expressed as a linear combination of our two sinusoids. The problem is just that our parameters don't describe the space very well. So when possible, it's better still to reparameterize in a way that removes as much of the correlation as possible. This particular example is contrived, but if you were fitting, say, a straight line to your data, you'd have two parameters, slope and vertical offset. If you choose the vertical offset measured at some arbitrary zero, you will probably have some huge covariance like we see here. You can reduce it drastically by measuring the offset at the middle of your data set. If you can, this is a better solution than just living with the covariance.



Now what about quality-of-fit? Our basic approach is going to be simulation again (to be improved soon, I promise). We'll devise some measure of goodness of fit, then we'll generate another batch of fake data sets, and we'll ask how many of them are a better fit than ours. After all, there's noise in there, so we wouldn't expect a perfect fit. But if our data is more different from the model than a thousand randomly-generated data sets, either we were really unlucky or our model is wrong.

The goodness-of-fit number we're going to use is called the chi-squared, and it's the sum of (ith data value - ith predicted value)**2/(ith uncertainty)**2.

def chi2(data, predicted, uncertainties):
return np.sqrt(np.sum(((data-predicted)/uncertainties)**2,axis=-1))


So first let's do this for data coming from the right kind of model:

def plot_quality_of_fit(model, parameters, data, n_samples=1000):

data_chi2 = chi2(data,
model.predicted_values(parameters),
model.uncertainties(parameters))

chi2_values = np.zeros(n_samples)
for i in range(n_samples):
chi2_values[i] = chi2(model.generate(parameters),
model.predicted_values(parameters),
model.uncertainties(parameters))

chi2_values.sort()

n_less = np.searchsorted(chi2_values, data_chi2)

plt.figure()
# make a "stair-step" plot
chi2_r = np.repeat(chi2_values,2)
y2 = np.hstack([0.0,
np.repeat(np.arange(1, n_samples)/float(n_samples),2),
1.0])
plt.plot(chi2_r, y2)

plt.axvline(data_chi2, color='red')
plt.axhline(n_less/float(n_samples), color='red')
plt.text(1,0,
("a fraction %g of the samples are this bad" %
(1-n_less/float(n_samples))),
horizontalalignment="right",
verticalalignment="bottom",
transform = plt.gca().transAxes)
plt.xlabel("$\chi^2$")
plt.ylabel("Fraction of samples less than given $\chi^2$")


def demo_goodness_of_good_fit():
true_parameters = np.array([2.,-1.])
n = 10
uncertainty = 0.1

model = SinCosModel(n,uncertainty)

data = model.generate(true_parameters)

fit_parameters = fit_linear_least_squares(model, data)

plot_quality_of_fit(model, fit_parameters, data)
plt.title("Goodness of fit for a correct model")
plt.savefig("monte-carlo-good-fit.png")



Now let's make a really different model, and use it to generate our original data set, but fit the same sinusoidal model to it:

def demo_goodness_of_bad_fit():
n = 10
uncertainty = 0.1
xs = np.arange(n)/float(n)

model = SinCosModel(n,uncertainty)

data = np.random.normal(scale=uncertainty,size=n)
data[n//2] += 1.

fit_parameters = fit_linear_least_squares(model, data)

plt.figure()
plt.errorbar(xs, data, uncertainty, label="data", fmt="+")
plt.plot(xs,model.predicted_values(fit_parameters), label="fitted value")
plt.xlim(0,1)
plt.title("Fitting the wrong model")
plt.legend(loc="best")
plt.savefig("wrong-model.png")

plot_quality_of_fit(model, fit_parameters, data, n_samples=10000)
plt.title("Goodness of fit for an incorrect model")
plt.savefig("monte-carlo-bad-fit.png")

This produces the fit seen at the top of the article:

And sure enough it's a bad fit:


This business of simulation is very simple, but it has important limitations. One is visible in this last plot: our model is such a bad fit not one random example was as bad as the real data set. So we have no way to judge the significance more closely than "less than about one in ten thousand". Often we'd like to know whether it's a one-in-a-million - after all, maybe we searched through a million possibilities to find it - or one in 10^40. Without running really outrageous numbers of simulations, we can't find this information without doing some analytical work. Fortunately in this case the statistics are pretty simple, and I'll talk about them next time.

Full post

Spring!

crocus.jpg
Finally the snow is gone, we're getting some sunny if cool weather, and there are a few green plants starting.

I had a nice afternoon at the Gardens. Not much has sprouted yet, but the buds were opening on some of the trees.
buds.jpg

The alpine garden, naturally enough, usually has a few plants showing early. The colors on this succulent made me wonder how these survive the winter - I presume the red is like the red in leaves, left behind when the plant stops replenishing its chlorophyll. But does the body of the succulent freeze and then recover?
alpine.jpg


Full post

Curve fitting, part 1: linear least-squares


Fitting a curve to data is a basic operation for many scientists. Usually it's a simple process, just use your favorite software to draw the best-fit line and forget it. But when you start having many points, large uncertainties, complicated curves, or (often) all three, it becomes more difficult. If you want to be able to say something statistical about the results, then you have to think carefully about the techniques you use. This post will just set up a simple curve fitting scenario and solve it using simple techniques. In future posts in this series I plan to add difficulties to the scenario and elaborations to the techniques, ultimately trying out some tools I've only read about.


I will set up and solve the problem in a literate programming style. The tools I use will be python, numpy, scipy, and matplotlib, but I hope that the code will be reasonably intelligible even if you're not familiar with the tools I'm using.
import numpy as np
import pylab as plt

First I will set up an object to represent the model. That is, it should be able to take a set of model parameters, and generate predicted average values for each data bin. It should also be able to generate "fake" data sets, which we will use to demonstrate our fitting (and, later, to analyze the quality).

The model I am using will be a linear combination of sine and cosine terms, and the measurements will be n equally-spaced measurements with equal uncertainty. (This particular model could be fit much more efficiently using a Fast Fourier Transform.)
class SinCosModel:

def __init__(self, n, uncertainty=1.):
self.initial_guess = np.array([1.,0.])
self.n = n
self.uncertainty = uncertainty

def predicted_values(self, parameters):
a, b = parameters
xs = np.arange(self.n)/float(self.n)
return a*np.sin(2*np.pi*xs) + b*np.cos(2*np.pi*xs)

def uncertainties(self, parameters):
return self.uncertainty*np.ones(self.n)

def generate(self, parameters):
return (self.predicted_values(parameters) +
np.random.normal(scale=self.uncertainty,size=self.n))

Now the fitting. Here I cheat: numpy provides a linear least-squares fitting procedure. It takes a linear system of the form Ax, b and adjusts the vector x to minimize the sum of squares of the values (Ax-b).
def fit_linear_least_squares(model, data):
n_params = len(model.initial_guess)
n_data = len(data)
assert len(model.predicted_values(model.initial_guess))==n_data

This is where the assumption of linearity is built in: I build the matrix A by evaluating the model at vectors like [1,0] and [0,1].
    coefficient_matrix = np.zeros((n_data,n_params))
for i in range(n_params):
params = np.zeros(n_params)
params[i] = 1
coefficient_matrix[:,i] = model.predicted_values(params)

Given that matrix, I use numpy to fit for the parameters. Numpy computes the least-squares fit using the singular value decomposition, a powerful technique in numerical linear algebra. This routine provides some control over the quality of the fit; in particular, the vector 's' contains information about the "singular values" of the linear fit. These will allow one to notice if roundoff error becomes a problem, which should only be the case if we have chosen parameters that have nearly the same effect ("degenerate"). In any case this does not tell us about the statistics of our fit, which is generally more of a concern (but which I will defer until the next article). So for our purposes the only value that's important is 'x', the vector of fitted parameters.
    x, residues, rank, s = np.linalg.lstsq(coefficient_matrix, data)

return x

Now a quick function to demo the curve fitting: it uses the model to generate a 'random' fake data set, fits a curve to it, and plots the true curve, the data, and the fitted curve.
def demo_linear_least_squares():
true_parameters = np.array([2.,-1.])
n = 10
uncertainty = 0.1

model = SinCosModel(n,uncertainty)

xs = np.arange(n)/float(n)
data = model.generate(true_parameters)

fit_parameters = fit_linear_least_squares(model, data)


plt.figure()
plt.errorbar(xs, data, uncertainty, label="data", fmt="+")
plt.plot(xs,model.predicted_values(true_parameters), label="true value")
plt.plot(xs,model.predicted_values(fit_parameters), label="fitted value")
plt.xlim(0,1)
plt.title("Simple linear least-squares fitting")
plt.legend(loc="best")
plt.savefig("linear-least-squares-1.png")

Finally, some code so that if you put all this in a file and run the file (e.g. as 'python curvefit.py') it will run the demo function and plot it to screen. The 'np.random.seed(0)' seeds the pseudorandom number generator so that the program generates the same output every time.
if __name__=='__main__':
np.random.seed(0)
demo_linear_least_squares()
plt.show()

This code produces the image seen at the top of this post: the fit is pretty good; any misfit is really forced by the data. But for real scientific data, we would want some quality checks: we would want uncertainties on the fitted values, and we would want some sort of measure of how well the curve fit the data. I'll talk about how to get these next time.

Full post

Best final sentence of an abstract ever

The edge of locality: visualizing a black hole from the inside

Abstract: We illustrate and discuss the view seen by an observer inside the horizon of a Schwarzschild black hole. The view as the observer approaches the central singularity is of particular interest because, according to ideas arising from "observer complementarity," points in opposite directions along the observer's past lightcone are at "the edge of locality," where standard flat-space quantum-field-theory commutation rules may be at the brink of failure. Near the singularity, the observer's view is aberrated by the diverging tidal force into a horizontal plane. The view in the horizontal plane is highly blueshifted, but all directions other than horizontal appear highly redshifted. We argue that the affine distance provides a canonical measure of distance along a light ray from emitter to observer. Since the affine distance is not directly measurable by the observer, we also consider perceptual distances, and argue that the trinocular distance (binocular distance is inadequate) provides an estimate of affine distance that would allow tree-leaping apes to survive in highly curved spacetime.

Boldface mine.

Full post

Remote observing


Professional astronomers don't really look through telescopes any more. Even leaving aside all the observations that look at frequencies invisible to the human eye, with the advent of photographic plates it became possible to see much fainter stars with the same telescope by taking a minutes- or hours-long exposure than by actually looking through it. (To the right you see the Leviathan of Parsonstown, the last giant telescope built in the pre-photographic era.) CCDs, more sensitive and more consistent, have now replaced photographic plates. So most observations are just long exposures that go onto disk for later processing. That raises the question: do you actually need to be at the telescope during your observation?

In many cases, at least in radio astronomy, we don't go to the telescope at all. For some telescopes, like the VLA, when you are allocated time, you simply send them an observing script - "look at my target for five minutes, then the calibration source for two, then back to my source, then..." - and the operators run it and send you an email when your data's available. For others, for example the GBT and Arecibo, you have to babysit the observation remotely.

For this sort of telescope, about half an hour before the observation starts, you open up a VNC session on one of the computers at the telescope, and you give the operator a call. (At Arecibo the automated attendant gives you a cheery message "Este es el observatorio de Arecibo!")

The operators at these telescopes are generally non-astronomers, locals put in charge of the telescope. They are responsible for safety, both of people and of the telescope. At the GBT, on the control room balcony they have a pair of high-powered Navy surplus binoculars so the operator can take a good look at the telescope, make sure nobody's nearby and there's nothing wrong with it. Their biggest concern is weather: imagine the effect of a sturdy gust of wind on a 100-meter dish. So it's their job to handle "wind stows", tipping the telescope up until the dish is horizontal ("birdbath position") to reduce the wind load, and other weather concerns (one observation I had scheduled, the operator had to take the telescope out of wind stow every so often to dump the snow out of it - as you might imagine, I didn't get to actually observe that day).

The other job of operators is to control access to the telescope. Normally telescope time is allocated by the telescope access committee, but it's the operator who actually hands over control of the telescope pointing to the astronomers who have time. Normally this is perfectly routine, though sometimes someone will finish early (perhaps because their source set) or ask for a few extra minutes (perhaps to re-do a calibration scan). But it also happens that the schedule gets changed at the last minute. For example, at Arecibo they have a megawatt radar transmitter they use for atmospheric and planetary studies. This runs on its own generator, and when something breaks, they can't use the time and suddenly a slot opens up in the schedule. Usually the operator calls somebody they know wants time, or offers the time to whoever has the time block before or after. In any case, it's the operator who hands you control of the telescope when your time starts.

These big telescopes are very complicated machines, and so they each have a collection of software used to control them. This handles pointing and tracking, receiver and signal path selection, gain adjustment and balancing, and in most cases, control of the recording instrument. So normally, you command the telescope to point to your source, you set up and balance the receivers (usually using a standard script) and you hit "start observation" and the telescope starts taking data.

This system is necessarily all sui generis hardware and software, cobbled together and more-or-less tested. It normally works exceedingly well, but problems do crop up. So it's good, when possible, to come up with some way of monitoring the data that's coming in. If you're looking at a known pulsar, the usual answer is to fold a short piece of the data at the pulsar period and see if you can see the profile. If that comes out okay, things are probably fine.



For pulsar astronomy, though, hardware has been improving rapidly. We now have new backends - recording instruments - that can do much better timing than was possible even a few years ago. These systems are complicated experimental software running on clusters of computers, and they have their quirks; among others, they're not integrated with the standard observing software. So for these systems, you have to open up another desktop, run a handful of arcane unix commands, and hope nothing goes wrong you don't know how to fix (see above screenshot for what it looks like when things are working fine). But the data that comes out is beautiful: we can measure pulse shape and arrival time with microsecond accuracy.

So remote observing basically amounts to logging in to a VNC session on a computer at the telescope, using telescope control software to get the system pointed and calibrated, and then starting up the observing system. Is this losing something compared to actually going to the telescope and observing? Yes and no. Control-wise, if you're sitting in the control room, you log into exactly the same VNC session and use exactly the same software. And if you're observing for an hour and a half every three weeks, it saves an awful lot of travelling for anyone who doesn't live at the telescope. But if you're at the telescope you can talk to the operators face-to-face, and there are astronomers and telescope experts on-site you can discuss things with in person. It's also probably easier for the operator to reach you if something comes up (like a free block of time).

Full post

What are pulsars?

Pulsars are rapidly-rotating stellar remnants that we see as pulsing radio or X-ray sources.

That is, once a star has burned all its fuel, there is no longer heat available from fusion to keep its tremendous mass from collapsing inward due to gravity. (Usually there is a supernova that burns up the last of the fuel, and that can blow off some or all of the star's matter. I'm going to ignore that for the moment and look at what happens to what's left.) If there's not too much gas left, as it cools and contracts, eventually it will be supported by the reluctance of electrons to be in the same place at the same time. If the remnant is more massive than that, the electrons can't support it and the star collapses further, until it is supported by the reluctance of neutrons to be in the same place at the same time. If the remnant is even more massive, nothing can support it, and it collapses into a black hole.

Pulsars are the middle case: stellar remnants crushed into a giant ball of (mostly) neutrons. When you crush a star this much, since it keeps most of its angular momentum, it begins rotating rapidly (pulsars are observed to rotate with periods from about 1.4 milliseconds to about 8.5 seconds).

This crushing (and possibly some other processes) also raises the magnetic field density up to about 10^12 Gauss. This is one of those astronomical numbers that's so large it's hard to make sense of; it's a hundred million times stronger - more dense - than the modern "supermagnets"; the energy density of the magnetic field is so high that using E=mc^2 it has a mass density about that of lead - with no matter at all in it.

Not every neutron star is a pulsar, though; we call them pulsars only when we see pulsating radiation coming from them. This "radiation" can be radio waves (which is how the first pulsars were found), coming from some poorly-understood process that's maybe a little like the Earth's aurora. Like the Earth's aurora, there is plasma - loose electrons and ions (and actually, in pulsars, a lot of positrons) - and it is channelled along field lines. Near the magnetic poles this plasma is densest and most active, and it emits directional radio waves (as the Earth's aurora does on a vastly weaker scale). These beams of radio waves sweep around the sky as the pulsar rotates, and when they pass the Earth, we see a pulse of radio waves.

The radiation can also be higher-frequency radiation: many pulsars emit X-rays, either from a hot surface or from the magnetosphere (the region of strong magnetic field above the surface), and the new Fermi satellite is finding that many pulsars actually emit gamma rays (even higher-frequency photons). A few pulsars even emit detectable optical pulsations, though sadly I don't know of any that are both bright enough to see through a modest telescope and slow enough to visibly blink.

Pulsars are interesting to astronomers for any number of reasons, but one of the most valuable is that they serve as clocks: since their pulses come from rotation, the pulses come in very regularly. To make the pulses drift or wander, the way my wristwatch does, some process would need to apply a tremendous torque to a very massive body. Not many processes are available to do this, and observationally, pulsars spin with astonishing regularity. The only reason we are able to distinguish any deviations from regularity (a topic for another post) is because we are exceedingly good at measuring time.

Having these clocks has proved extremely valuable: when a pulsar and another star are orbiting each other, we can measure the orbit extremely accuately. Hulse and Taylor won a Nobel prize for measuring the loss of orbital energy in one such system due to gravitational waves; a more recent project aims to observe gravitational waves from elsewhere in the universe by correlating pulse arrival times from many pulsars. Pulsar timing allows us to measure very accurate positions, distances, and proper motions to some pulsars. So the study of pulsars has been extremely fruitful - even though, forty years after their discovery, we still don't really understand how they produce the emission that we see.

Full post