Any normal person will find building CASA to be an enormous challenge, but fortunately I have a ton of experience in this area and although things are incredibly tedious, they’ve been fairly tractable.

Excluding one huge pitfall that I fell into.

CASA requires a software package called ccmtools. If you Google it, you find a stale SourceForge page for the project. Do not go there. If you read down the Google results, you find Building CCMTools as required by CASA. Do not go there. These resources reference an older version of ccmtools which uses the worst build system I have ever seen and doesn’t even work anyway. I found a bit of gruesome fascination in the intersection of idiotic design, worthless documentation, and grossly incompatible versions, but that was all below a layer of bottomless, unfathomable rage. Don’t go there.

Instead, go to Compiling casapy from source in Ubuntu and follow the tip: there’s now a CASA fork of ccmtools which builds in a much saner (though still somewhat weird) way. For the love of all that is good, use it. I’m going to give it some more links so that hopefully Google reorders its results. Look, ccmtools for CASA! If you want to compile ccmtools, use the NRAO version of ccmtools!

As I mentioned, the rest of the CASA build process is still a huge pain, and would be impossible for the average person, which is too bad, but (so far?)  this has been by far the worst part.

Finally, to the guy who wrote Confix: please do not ever write code again.

For now I’ve thought through the implementation using arcsecond units. Say we have a 2047×2047 image with a pixel scale of 10 arcsec that’s uniform across the image. If I want σ to measure the ATA primary beam, with a FWHM of 3.5°/GHz, I get σ = 5350.7 arcsec/GHz. To generate a model-type image, we need to work in Jy/pixel, so A must be scaled by the arcsec²/pixel conversion ratio, 100 in this case.

Implementing this in maths is straightforward. You use the xrange and yrange keywords to implement the Gaussian expression, ranging them from -10230 to +10230 in the example here.

23 pages, 13 figures, 4 tables. Accepted for publication in ApJ. For a brief video explaining the main results of this paper, see this http URL

Indeed, if you follow the link, you can see a nice 5-minute video of Linda explaining the gist of the work, a sort of video abstract.

I like to think that my reading comprehension skills are pretty OK but I often scan abstracts on interesting-sounding but unfamiliar topics only to later realize that I’ve absorbed absolutely nothing from them. I think the video alternative is great for this situation, for the same reason that we’ve got lectures as well as textbooks: there’s something about watching a person talk out an idea that’s evidently a lot easier for the brain to follow, even if reading is more efficient.

It’s also nice to put a human face on the work. Even for those topics that I know more about, where the written abstract doesn’t go in one ear (eye?) and out the other, I think it’d be fun to see the author’s body language and maybe glean a bit about their approach to the topic. Hopefully Linda’s paper will be the start of a trend!

Residuals from point-source imaging

Using real ATA observations as a template, I generated some perfect fake data of a single point source — no noise, calibration errors, etc. I’m interested in wide-field imaging so I put the source at 0.63 deg from phase center. I then imaged the data using the casarest lwimager fork of the CASA imager with various options.

The top-left panel shows the imaging residuals using traditional grid-and-FFT and 200 iterations of Högbom (1974) clean. The S/N is just 1001 — for ideal data with no noise!

The top-right panel turns on the w-projection algorithm with 128 planes. The S/N jumps to 2987. I’m too lazy to measure it, but the speed penalty is nontrivial. Annoyingly, a bunch of time is spent in startup calculating convolution kernels that are constant from one imaging run to another in most cases. In the imaging that I do, a lot of time could be saved by caching those kernels on disk.

The bottom-left panel turns on the “wide-field” Högbom clean which subtracts the modeled CLEAN components from the visibilities. This also adds a significant time penalty. The S/N increases to 8713.

Finally, and most interestingly to me, in the bottom-right panel I’ve moved the source slightly to land it precisely in the center of the nearest image pixel. The S/N jumps to 34542. This effect is investigated in Cotton & Uson (2008).

Not shown: using Cotton-Schwab clean with w-projection gives results nearly identical to those of the wide-field Högbom clean. Wide-field Högbom should theoretically give more accurate results since it uses the full dirty beam in the image domain. In a quick test, CS clean is about 30% faster than wide-field Högbom.

I recently had to get my Nexus One phone repaired, which involved discovering 1) that to do so requires getting the phone’s data wiped and 2) you need a rooted phone to actually back up all of your data. It was too late to be able to back up my data, but as long as my phone came back wiped, I figured I’d make it so I was able to back things up thoroughly in the future. This is what I learned.

Rooting your phone is a pain in the ass. It took me a long time to figure out this recipe. Instructions online are usually some combination of confusing, outdated, inaccurate, or inappropriate. Most instructions reference XDA Developers Forum threads which are all of the above except more so, difficult to browse, and often filled with useless chatter. (I can see why they do the things they do, but there are a lot of drawbacks too.) Most of the rooting instructions are for Windows or Macs. The phone rooters using Linux are, in general, clearly not very familiar with the OS.

Rooting your phone voids your warranty and wipes your user data. Of course, if you still have a Nexus One, your warranty is probably long gone anyway. In some versions of Android, there are ways to gain root without losing your data, but my impression was that these are more difficult and rely on exploits that have been closed in Android 2.3.6. (By the way, Android 2.3.6 is in the “Gingerbread” series; as always, Wikipedia has a good table matching Android codenames and versions.)

That being said, here’s the recipe:

1. Preparatory work
1. Turn on data syncing on your phone in Settings → Privacy → “Back up my data”. I have no idea how long it takes for these data to get synced, so if the setting wasn’t on before, do this well in advance of actually rooting your phone.
2. Install backup software on your phone and use it. These back up various pieces of phone data to your SD card, which can then be transferred to your computer over USB. MyBackup Pro (non-free) seems to be the consensus choice. The whole point of this exercise is that without root you can’t back up everything, but you can back up a lot of important stuff like SMSes and call logs. MyBackup Pro wants you to create some online account but you can skip that part. (The hands-down favorite for general backup is Titanium Backup, but it requires root access, which we don’t have yet.)
3. Back up your phone’s SD card onto your computer using the USB cable. Free up at least 500 MB on the card to make room for backups. (The backup tool won’t run if you have less than this amount free, so it’s not like you can get away with less if you don’t have much installed.) These backups will include the phone data backups you just made inside rerware/ on the SD card (if you used MyBackup Pro).
4. Install the Android SDK. Once the tarball has been unpacked, you need to run tools/android to get a GUI that will let you install many of the components actually needed to do stuff with the phone. Be sure to install the components for the correct version of Android API. Version 2.3.3/API 10 worked for me. You can skip all of the vendor-specific packages (some of which take a long time to download). In the end, the programs platform-tools/adb and platform-tools/fastboot should be available.
5. Download a “recovery image,” which is a tool that lets you boot into an alternate OS that lets you monkey around with your phone. These all seem to be posted on XDA Developers. They have a Nexus One Recovery Images wiki page that allegedly collects such images. “Amon_Ra’s Recovery” version 2.2.1 worked for me: the file’s called recovery-RA-passion-v2.2.1.img and I got it off this forum thread. Just to be clear, many of the following steps assume that you’re running this recovery image or a very similar version thereof.
6. Download a “superuser utility,” which is a combination of Android software (“APK”) and some low-level OS hooks that almost all applications build on to do rooty things. There seem to be a ton of variants. Almost everybody links to the version mentioned on this XDA thread, but the version described there is incredibly out of date. If you trace the downloads, they lead to this listing page, which has more recent versions. The file called Superuser-3.0.7-efghi-signed.zip worked for me. (It was at this point that I realized that not only are Android OS versions named after desserts, but those names proceed in alphabetical order.)
7. Set up a udev file allowing the fastboot program to identify your phone. This seems a little silly but does appear to be necessary. I created a file named /etc/udev/rules.d/99-android.rulescontaining these lines:

   SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666", OWNER="peter"
   SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666", OWNER="peter"

   The OWNER parameter should be substituted with your username. The syntax for these rules is apparently deprecated but whatever.

2. Unlocking the bootloader
1. Ensure that your SD card is backed up and you have 500 MB of free space on it. Prepare to lose all of your data.
2. Power off your phone. Disconnect it from the USB cable if it’s plugged in. (I haven’t verified that you need to do this, but other people’s instructions seem to suggest this.)
3. Boot it into the “fastboot” screen by holding down the trackball while pressing the power button. You should quickly get a little semi-textual menu screen.
4. Plug your phone into your computer with the USB. In the Android SDK, run platform-tools/fastboot oem unlock. If this complains about not being able to find your phone, your udev rule may not be functional.
5. A screen will pop up on your phone asking you if you Really Want To Do This. You do. Unless you don’t.
6. Magic will happen and your phone will boot up. You’ll see a little open lock icon at the bottom of the splash screen indicating that the bootloader is unlocked.
7. Reenter your Google account information, Wi-Fi connection password, and other basic stuff.
3. Booting into the recovery image
1. Get back to the fastboot menu: power off, disconnect USB, boot with trackball held, reconnect USB.
2. Run platform-tools/fastboot flash recovery /path/to/recovery-RA-passion-v2.2.1.img. This should succeed without errors.
3. In the fastboot menu, choose Bootloader.
4. In the bootloader menu, choose Recovery.
5. You should boot up into the special recovery mode. NB: I originally thought that after I flashed in the special recovery image (step 3B) I could boot into this special mode whenever I wanted. In my experience, it only works if you boot into recovery mode immediately after flashing the image. Otherwise I get a hard lock that requires popping out the battery to fix.
4. Monkeying around in recovery mode
1. Choose the “Nandroid backup/restore” menu option. Back up everything that seems reasonable. Since the bootloader unlock has just wiped your data, this won’t back up anything personal, but it’ll back up your phone OS in case you break things later.
2. Go back to the main menu (volume down key) and turn on “USB-MS”. (The USB cable should still be plugged in from the fastboot flash steps.) This will activate your phone as a USB filesystem.
3. Copy your nandroid backup off the SD card (nandroid/ and potentially .android_secure/).
4. Copy your superuser utility onto the SD card.
5. Unmount the phone on your computer and turn off USB-MS on your phone.
6. In the main recovery menu, choose “Flash zip from sdcard”, and choose your superuser utility. It should print out some messages about what it’s doing. You’re now rooted.
7. In the main menu, reboot into the regular OS.
5. Demonstration of rootiness
1. Besides back up your data, one thing you can do while rooted is remove built-in applications. To get started, turn on “USB Debugging” in the Settings → Applications → Development menu on your phone, and plug in the USB cable.
2. In the Android SDK, run platform-tools/adb shell.
3. This is a tiny little busybox shell running on your phone. You can ls and see the contents of your phone’s builtin storage.
4. And you should be able to run su to get root access. Do so.
5. Remount the /system partition in read-write mode: mount -o remount,rw /dev/block/mtdblock3 /system.
6. cd /system/app
7. Running pm list packages -f will give you a list of installed packages and their corresponding APK files, which are found in this directory. To remove a package, first manually delete its APK file, then run pm uninstall [ident], where [ident] is the Java-style name of the package such as com.facebook.katana.
8. Close shell, disconnect USB, disable USB debugging, etc.
6. Cleanup
1. Your phone should now be booted into your regular, barely-initialized Android OS. Reinstall your backup program and restore backed-up data. If using MyBackup Pro, I found that I should not restore my calendar — all of my calendar events got duplicated. I also got messages about massive deletion of my contacts, and I’m pretty sure I should have chosen not to restore those either. At some point all of my Twitter “contacts” also got merged into my Google contact list, which was really annoying.
2. Begin the painstaking process of re-inputting all of your settings. There are a lot more than you thought.
3. Remove the udev rules file you created.
4. If you so desire, clean up some of the backups and things off your SD card.
5. Finally — the main point of all of this — after you’ve had a while to get all of your settings back, run a root-powered full backup of your phone data, and copy that backup off the SD card. Once you have root, consensus seems to be that Titanium Backup is the gold standard.

Here are some of the resources I used when piecing together all of this information:

• XDA Developers HTC Nexus One Guides & Tutorials and links therein
• XDA Developers RA-passion-v2.2.1 forum thread
• XDA Developers Superuser 2.3.6.1 forum thread
• XDA Developers HOWTO Root Nexus One 2.2.1 FRG83D without OEM unlock
• XDA Developers Remove built-in apps from ROM

"\e[5C": forward-word
"\e[5D": backward-word
"\e[;5C": forward-word
"\e[;5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
Meta-.: yank-last-arg
Meta-_: yank-last-arg

With a bonus explicit binding of Alt-period, which is also sometimes missing. In my explorations I discovered that for SSHing into OS X / Darwin computers, the third pair is the one that’s relevant.

For a large PNG file, the best approach using standard tools that I’ve discovered is to use the NetPBM programs:

pngtopnm figure.png |pnmtops -equalpixels -scale 0.24 -psfilter \
   -flate -noturn -ascii85 -nocenter - >figure.eps

Annoyingly all of these options seem to be necessary to give useful output. The scale factor is the number of inches per 72 pixels; 0.24 gives you about 300 DPI.

The pnmtops documentation says that the -flate option (which turns on compression and can be a huge deal for large images) sometimes produces busted output. There’s also an -rle option that will be less efficient (especially for bitmaps that don’t contain long stretches of single colors). The documentation also references a program called bmeps that is claimed to do a better job of this kind of conversion. The same seems to be said of sam2p, but one of the benefits of the above command is that the NetPBM tools are installed on most Linux machines.

When all of these options are working, I can generate a good EPS that’s only 15% larger (on-disk) than the original PNG, which is pretty cool.

This is just a preview! The real image is a PDF.

Look at how nice and text-selectable the labels are. Appreciate the lovely, colorblind-person-friendly colorization. Ponder the honoring of the image mask. Marvel at the lack of resampling of the underlying image data!

The only deficiencies that come to my mind are the excessively large margins and the lack of a synthesized beam size indicator. I had to wrestle with some unpleasant implementation details to get it all to work though. Like this. Time to call it a day.

\catcode`\|=\active
\protected\def|#1|{\textsf{#1}}

This example sets up the pipe symbol as the magic delimiter and uses the \textsf command to render pipe-enclosed text in a sans-serif font. Note that this will break vertical lines in table format specifications (e.g.), although pipes do seem to be the standard choice for the magic character. (Primary credit to StackExchange.)

If you want to do this to render the enclosed characters in “verbatim” format, the shortvrb style file seems to take care of things.

According to this StackExchange answer, the above definition falls down in some corner cases (“will not work if you want verbatim text mixed with your emphasized text”) but they don’t sound like cases I care about.

Journals probably won’t be happy if you have this kind of stuff in your LaTeX files but I haven’t tried submitting anything containing commands like these.

As far as I can tell, there’s no GUI way to do it.

It appears as if you should be able to remove connections with the command-line interface program nmcli with something like nmcli con delete id "Auto NetworkName" but that doesn’t seem to work for me. (Nor does it result in an error message.)

However, if I go to /etc/sysconfig/network-scripts and blow away the files corresponding the connection that I want to remove (sudo rm -f *NetworkName), the connection appears to get deleted. It’s at least no longer reported in nmcli con list.

Units

Radio astronomical images typically come in two unit systems: Jy/pixel and Jy/beam. For various questions one usually wants to convert to Jy/arcsec² or Jy/sr. Jy/pixel is not trivially equivalent to Jy/arcsec², because the pixel size can change as a function of position in many map projections.

There must be something profound about why maps come in Jy/bm and models come in Jy/pixel, but I don’t see it right now.

Source fluxes are best measured as total fluxes which come in units of plain Jy. This should be obvious! Flux is conserved! In the general case peak fluxes are always dependent on the image properties.

The important exception, however, is unresolved sources which by their nature have a peak flux equal to their total flux no matter what unit system you’re using. Total flux of 1 Jy, peak flux of 1 Jy/px spread over 1 pixel, or peak flux of 1 Jy/bm spread out over 1 beam.

Resolved sources will have a peak flux that depends on the particular image units and projection, because the total flux will be spread out over a number of pixels that depends on the image particulars. In a Jy/px image, you need to figure out how many pixels the source subtends, and mutatis mutandis for Jy/bm. Generically, pkflux = totflux * arcsec2perpix / arcsec2insource. If you have a 2D Gaussian source where the axes are FWHMs in arcsec, arcsec2insource = 2 pi major minor / (8 ln 2).

I think the best way to work with Jy/bm is to go through Jy/px: the beam volume in pixels can be derived from the beam parameters and the pixel volume: pixperbm = arcsec2perbm / arcsec2perpix. For various operation I feel like this quantity will cancel out, though. Once again, due to the position-dependent pixel volume in most maps, this parameter is not constant across the map.

2D Gaussian Parametrizations

There are a few ways to parametrize a 2D Gaussian. I’ll omit centering and overall scaling in the following equations for simplicity.

Tersest. The simplest expression in terms of symbols is:

This parametrization is computationally efficient but not intuitive. One particular danger to note is that the parameters behave a bit oddly, and there are domain limitations that make it awkward for numerical optimizers (which are likely to tweak the parameters outside of their domains): A and C must be negative, and, if I’m doing my algebra right, you must have B² < 4AC.

Mathematical Major/Minor/PA. We often want to express the shape of the 2D Gaussian as a major axis σ1, minor axis σ2, and position angle θ. Here σ1 ≥ σ2 > 0 and θ is the rotation between the major axis and +x (with +θ being towards +y). Because of the symmetry of the shape, there’s a 180° degeneracy in θ.

We find , , and .

Inverting, we find , , and . During a roundtrip, θ may flip by 180° depending on the numerics, but as mentioned above this doesn’t change anything.

Astronomical Major/Minor/PA. This is the same as the above, except that by the definition of PA, the x axis is declination and the y axis is right ascension. Be careful to write .

Numerically-friendly. If you’re fitting for Gaussian parameters, it’s very helpful to numerical stability to have nice continuous behavior over all of your parameters. The B parameters above seem to be problematic, so here’s a parametrization that is pretty cheap to compute and behaves nicely: , , and . It shouldn’t be hard to see that and .

Here, the optimizer may end up with either of the σ values being the larger. If σ2 > σ1, you can exchange them and add (or subtract) π/2 to θ.

Wikipedia. The Wikipedia page on Gaussian Functions uses:

Here the condition on the parameters is that the matrix [a b \ b c] be positive definite, or that (or, equivalently I think, that a and c be positive and b² < ac).

Wikipedia gives a conversion formula to this system from major/minor/PA, but there are two caveats: the Wikipedia system names σ{1,2} as σ{x,y} somewhat misleadingly, and inverts θ to be a clockwise rotation from +x to -y. Avoid those equations since the ones I give above are clearer.

Gaussian Convolutions

Resolved sources are often modeled as 2D Gaussians. These are convolved with the 2D Gaussian of your synthesized beam, so one often wants to compute this convolution or deconvolution analytically. The file src/subs/gaupar.for in MIRIAD has routines for going both directions, and they are not trivial. The deconvolution case needs special handling for sources that are close to (or smaller than!) point sources. The existing heuristics seem only so-so. See mmm/pwilliams/ms/mssfextract for a Python deconvolution implementation.

To manage flux through such a deconvolution, work in total flux units. Nothing changes! The peak flux is scaled in two ways: once, to convert from Jy/bm to Jy/px (assuming this is what you’re doing), which involves the beam volume and the pixel volume; and once to convert the source area, which involves the original volume and the deconvolved volume.

Gaussian Coordinate Transformations

When you have a Gaussian model for a source, this usally needs to be rendered into actual pixels or something.

Doing this purely geometrically is difficult. For instance, in a given map projection, the RA/Dec axes may not be precisely aligned with the X/Y pixel axes. If you want to draw a Gaussian source as an ellipse, you need to rotate it a little bit. If the source is very large, these effects change over the source extent and things get scary. It’s better to calculate the RA/Dec of each pixel and brute-force your way through many of these issues.

To do this brute forcing, you need to find the  value of the parameter that goes in the exponential. You can think of this as computing a distance in from the origin in the transformed space where the Gaussian is a circle. You un-translate, then un-rotate, then un-scale:

def gaussdist (x0, y0, maj, min, pa, x, y):
  # x0, y0: Gaussian center
  # maj, min: major/minor axes
  # pa: position angle, from +x toward +y

  dx, dy = x - x0, y - y0
  c, s = N.cos (pa), N.sin (pa)
  a = c * dx + s * dy
  b = -s * dx + c * dy
  d2 = (a / maj)**2 + (b / min)**2

  # d2: "distance" from Gaussian
  return d2

The astronomical “East from North” PA convention means that you can replace X with declination and Y with right ascension. This formulation can be turned into the one in the Wikipedia article on Gaussian Fuction but is a lot simpler to think about.

A: Converting Jy/pixel to Jy/arcsec²

To do this you need to calculate the size of a pixel at the position of the source you’re considering. Code to do this is in mmm/pwilliams/ms/msimgen. It looks something like this:

def pixelvolume (pixel2world, pixelcoords):
   delta = 1e-5
   w1 = pixel2world (pixelcoords)
   pixelcoords[X] += delta
   pixelcoords[Y] += delta
   w2 = pixel2world (pixelcoords)
   dra = w2[RA] - w1[RA]
   ddec = w2[DEC] - w2[DEC]
   return (dra**2 + ddec**2) / (2 * delta**2)

B: Error Ellipses From Covariant Variables

This is almost entirely unrelated to everything else here, except that it involves 2D Gaussians. Given two correlated variables, what are the parameters of the ellipse that describes a confidence region?

def ellpar (x, y, sx, sy, cxy, cl):
  # x: expectation value of x variable
  # y: expectation value of y variable
  # sx: std dev (not variance) of x var
  # sy: std dev (not variance) of y var
  # cxy: covariance (not corr. coeff.) of x and y
  # cl: desired confidence limit (0 < cl < 1)

  from numpy import arctan2, log, sqrt
  th = arctan2 (2 * cxy, sx**2 - sy**2)
  rcl2 = -2 * log (1 - cl)
  tmp1 = sqrt ((sx**2 - sy**2)**2 + 4*cxy**2))
  tmp2 = sx2**2 + sy**2
  maj = sqrt (0.5 * rcl2 * (tmp2 + tmp1)
  min = sqrt (0.5 * rcl2 * (tmp2 - tmp1)

  # x: same as input
  # y: same as input
  # maj, min: ellipse major minor axes as
  #   sigma values, not FWHMs
  # th: position angle, rotating from +x to +y
  return x, y, maj, min, th

This is derived by transforming X and Y to have a mean of 0 and stddev of 1, then considering the probability distribution of r = x²+y², which follows P(r) = r exp (-r²/2), and has CDF(r) = 1 – exp (-r²/2), allowing the r for a given confidence limit to be calculated.

I looked into merging the SMA version of MIRIAD into mainline CVS. It’s a little scary, but I at least got things to compile. My fixes here. The merge itself is also involved because SMA MIRIAD was branched off of an old version. I don’t know if this will ever get merged since there is a lot of sketchy code in there.

I tried to convert MIRIAD to use FC instead of F77 but it turns out to basically be a massive undertaking. As far as I can tell there’s no way to convince Automake to treat .f or .for files as Fortran 90, not Fortran 77.  (Search for .f90 in /usr/bin/automake, e.g.)

There’s a potential win here because the .for files can be compiled directly by gfortran without needing preprocessing by ratty, at least in the cases I’ve tried. It’d be very nice to skip the ratty circumlocutions.

Also note that wcslib and linpack come with ‘.f’ files. If there’s a trick to get automake to think of ‘.for’ files as Fortran 90, if it can’t also be applied to ‘.f’ files, we’ll still need to use F77 to build those libraries. (The same consideration applies to pgplot too, but it has its own configure script.)

Lots of astronomers write articles for submission to The Astrophysical Journal (“ApJ”) using LaTeX for manuscript preparation and the companion BibTeX for automated bibliography processing. One uses a “style file” to tell BibTeX how to format the bibliography according to ApJ specifications. The American Astronomical Society and NASA Astrophysics Data Systems provide such a style file, currently found here, but it has a few shortcomings:

• References to ArXiV preprints don’t have their identifiers displayed.
• Entries with DOI information don’t use this to link to the referenced articles.
• Some BibTeX entries end their page numbers with a plus sign, and these get propagated into the bibliography and look bad.

(OK, the second two problems are pretty much cosmetic. The first one is significant, though.) Various people have fixed some of these problems, but there’s no canonical source of the ApJ style file, so things get out of sync. (For instance, AAS and NASA ADS currently post differing versions of the style file.)

Well, you can see where this is going. I’ve created a hacked version of the style file called yahapj.bst — “Yet Another (h)ApJ BibTeX Style”. It fixes the above problems, and I’ve attempted to solve the splintering issue by managing revisions on GitHub, here: github.com/pkgw/yahapj. The key benefit is that if people share their changes by cloning the Git repository and making commits, it will always be possible to compare the lineages of different versions of the file and merge them safely. Overkill? Perhaps. But it’s the correct solution.

To summarize, why should you use yahapj?

• Attractive, ApJ-compliant bibliographies with embedded links to digital articles and preprints whenever possible.
• It’s easy to check that you’re using the latest, greatest version, and as easy to hack the file as you can get. (Which isn’t super-easy given BibTeX’s bizarre style language, but that’s another issue.)

I’ve even got a screenshot!

The blue parts are links in the PDF file. If you’re about to say something about journal abbreviations, I know, and it’s beyond the control of yahapj.

There are some holes because it turns out that some of our fields were only observed during the first season of observing, when we took data at a longer wavelength that turned out to be very difficult to work with.

Mozilla says it’s dropped Prism in favor of a project called Chromeless. Unfortunately Chromeless seems to have very different goals, and it appears to have no support at all for saying, “Please make an SSB for this webpage now.” The development of Chromeless has also been very slow recently. Meanwhile, Prism isn’t entirely compatible with Firefox 3 and above, which has been bad news for my SSB-loving self.

I’ve looked into this a bit, and it turns out that with recent versions of Firefox, the capabilities of the old Prism can be emulated. I’ve done this on Linux, but similar approaches ought to be workable on other OSes. The limitations that I know of are:

• It’s a hassle to set up a new SSB.
• External links open in the SSB UI, not your default Firefox UI.
• (This one is fixed in Firefox 10! It makes a big difference since you don’t have to keep a spare “regular” Firefox window lying around at all times.) If you open an SSB UI without a default Firefox UI existing, attempts to create new Firefox windows will create windows in your SSB UI.
• If you try to launch an SSB twice, you’ll get a complaint about Firefox being running but unresponsive.
• The icons for running applications aren’t differentiated.

That being said, here are the instructions for replacing Mozilla Prism on a Linux system.

• In a terminal, run firefox -ProfileManager -no-remote.
• Create a new profile.
• Give it a name related to the website you want to make an SSB for. Mozilla recommends that profile names be all-lowercase and not contain spaces. My example will be “gdocs”; for multiple SSBs, just replace “gdocs” with a different name in everything that follows.
• Start up the browser using this profile.
• Navigate to the main page for your site.
• In the Preferences screen, set the Home Page to the current page. If the URL contains bits that look superfluous, edit them out. (You can test the homepage setting by hitting Alt-Home to see if the bits really were superfluous.)
• In the Tabs section of the Preferences screen, turn off “Always show the tab bar” and “Open new windows in a new tab instead”.
• (Extra credit — these bits will give your SSB launcher the icon of your chosen website.) Hit Control-I to get the Site Information window. Choose the Media section, find the image that corresponds to the website’s bookmark icon — this is usually the first image and is usually called favico.ico. Use the “Save As…” button to save it somewhere.
• In the View → Toolbars submenu, disable as many of the toolbars as you want. If you disable the menu bar, it can be recovered by hitting Alt-f. (This feature is only available in newer Firefoxes; it’s definitely present in update 7.)
• (Extra credit part II.) Convert the downloaded site icon to a PNG named ~/.local/share/icons/ssb-gdocs.png. The aptly-named command-line tool convert is fine for this.
• Create a file called ~/.local/share/applications/ssb-gdocs.desktop. Fill it with the contents shown below.
• Repeat the above steps for as many SSBs as you’d like to create. When done, exit all Firefox instances, SSBs and default profile alike. Run firefox -ProfileManager. Select your default profile, and start up Firefox. This step is necessary to tell Firefox that you want it to start up using your default profile by default.
• On Fedora systems, a launcher for your SSB will appear in the Other section of your Applications menu. You can drag this launcher onto your desktop or the panel if you want.

Here are the template contents of the desktop file:

[Desktop Entry]
Name=GDocs
Type=Application
Comment=Google Documents
Exec=firefox -P gdocs -no-remote
Icon=ssb-gdocs.png

If you haven’t been doing the extra credit, use Icon=redhat-web-browser.png on Fedora machines.

This maps out how much information one of the ATA antennas contributed to the sampling of the sky during one of my observations. Each track comes from its pairing with another antenna and moves elliptically as the Earth rotates. The space that’s being mapped is the “visibility” plane, the 2D Fourier transform of the sky.

Below are some zoomed-in images, with the cross representing the catalog position of DR 21. Here’s it without w-projection:

DR 21 without w-projection

And here it is with w-projection:

DR 21 with w-projection

I believe that there are still issues to resolve regarding the hour angle dependence, but it’s nice to see the algorithm work so well for these particular sources.

Figure 1 below demonstrates the effect. Using a dataset of many observations of Cyg X-3, I made four images, each from different HA subsets of the data: one at HA ≅ -5.5, one at HA ≅ -2, one at HA ≅ +2, and one at HA ≅ +5.5. The animation cycles back and forth through the four images. If you follow the source at the very top left of the map, you can see it dance back and forth along a parabolic arc. (It drops below the lower cutoff in the third image.) When it is at its leftmost, the image comes from observations of HA ≅ -5.5; when it is at its rightmost, it comes from HA ≅ +5.5. Obviously, the position of the source should not vary with HA.

Figure 1. Point sources wander as a function of HA, with the effect becoming more significant as distance from phase center increases.

The circle denotes the half-power point of the ATA PB at the observing frequency, 3.1 GHz. The other boxes give reference points for other sources; note that the source at phase center, Cyg X-3, does not move appreciably. The plus signs denote approximate fiducial positions of the two distant sources, which are DR 21 and DR 22. There are clearly other aspects of the imaging that are varying; these are likely due to the differing UV coverage of the different observations, and the fact that I have only a few observations at very low HAs, while I have many at moderate-to-high HAs.

Figure 2 shows how the HA variations manifest themselves with regards to the extended structure in the field. The extended structure is brought out by integrating over wider ranges of HA; Figure 2 blinks between data at HA < -3 and HA > +3. The overall effect looks like a translation, though again, the size of the effect increases with distance from phase center. An important point of this figure is that the effect is discernible even well within the first PB null, so it’s not something that only affects a few sources far away from phase center. Additionally, while it’s the case that I’m not using w-projection or faceting, and this might affect the very far-out sources, it shouldn’t be significant for the emission within the half-power point.

Figure 2. Effect of HA variations on extended structure, made visible by integrating over larger HA intervals.

The parallactic angle swings from -50° to +50°, through -180°, as the HA advances from -6 to +6. Figure 3 visualizes this.

Figure 3. Parallactic angle as a function of HA. Colors are irrelevant.

When it comes to point sources at more than twice the half-power point, I don’t worry too much about unusual imaging artifacts. But this effect seems to be significant much closer to the phase center as well. You could definitely imagine workarounds: for instance, if I group my data by HA, image the groups, and average the deconvolved images together, I get better results than imaging all of the data at once.

But it would be nice to actually understand and fix the underlying issue. One explanation is that there’s a phase gradient across the mean ATA PB; as the PB rotates on the sky, the position errors on sources away from the phase center vary. You could imagine such a phase gradient arising from some sag in the arm supporting the secondary, since ATA antennas use an offset-Gregorian architecture. This explanation has the advantage of potentially being a nice testcase for using MeqTrees with ATA data. Another possibility that has been suggested to me is that our antenna positions are not quite right and so our UV coordinates get inaccurate at extreme HAs.

LaTeX Error: Command \url already defined.

My document used the hyperref package, and disabling this did make the problem go away. But I could compile the document on another machine without problems.

It turned out that the culprit was the latex2html package. The hyperref package requires a package called url.sty, which normally has some special hooks that are invoked when hyperref (and perhaps pdflatex) are active. However, latex2html comes with an old version of url.sty that doesn’t have these hooks, and on my machine LaTeX prefers the version that comes with latexhtml (in the tex/latex/html/ subdirectory of the texmf tree) to the usual version (in tex/latex/ltxmisc/).

Uninstalling latex2html solved the problem. Of course, now I don’t have latex2html, but I don’t need it at the moment.

The NM SystemSettings page and settings specification document are useful references, but don’t pull the full answer together. You want to create a file in /etc/NetworkManager/system-connections/, named whatever you like. It should be owner root:root and mode 600. The contents should look like:

[connection]
id=Argh
uuid=11111111-1111-1111-1111-111111111111
type=802-11-wireless
timestamp=0

[802-11-wireless]
ssid=SEE BELOW
mode=infrastructure
security=802-11-wireless-security

[802-11-wireless-security]
key-mgmt=wpa-psk
psk=YOUR-NETWORKS-PASSWORD-IN-PLAINTEXT

[ipv4]
method=auto

Obviously this only works for WPA/PSK mode, but I think that’s by far the most common for encrypted WiFi networks these days.

The SSID is specified as a byte string. If your SSID is expressible in ASCII you can generate this with a Python snippet like: ';'.join(str(ord(c)) for c in 'SSID')+';'. For instance, the network ‘Sample’ is expressed as “83;97;109;112;108;101;“. No quotation marks are used in the config file.

NetworkManager appears to monitor the system-connections directory, and may initially reject your file if it doesn’t have the restrictive permissions it wants. Editing the file after the permissions have been changed causes that to be reloaded. The command “nmcli con up id Argh” should activate the connection.

If GNOME 3 thinks your desktop doesn’t support 3D acceleration, it will use a “fallback mode” that avoids it. This sounded like what I needed, since Linux lockups on desktops are almost always associated with 3D graphics drivers. Unfortunately, the only documented way to turn on fallback mode is through the graphical interface, which I couldn’t get to.

The best method that I could discover to fix this is as follows:

1. Boot up the machine in single-user mode, by pressing keys during bootup, then editing the GRUB kernel arguments to add a “1″ at the end of the kernel commend line. (The “1″ can be thought of as implying “single-user mode”.)
2. Run: rpm --nodeps -e gnome-shell
3. Exit the root maintenance-mode shell.
4. Log in as your regular graphical user. You should be brought into fallback mode.
5. Forcing fallback mode permanently via the GUI: user menu → System Settings → System Info → Graphics → Force Fallback Mode: on.

Why the “–nodeps”? Because the gnome-panel package, which is needed to use the fallback mode, requires gnome-shell, the new GNOME 3 UI, “to band aid upgrades”, according to the RPM changelog.

You might think that there would be a text-mode way to change the setting. And it seems that there should be. The org.gnome.desktop.session.session-name GSetting needs to changed from “gnome” to “gnome-fallback”. From my read of the docs, it should be possible to do this by running the command:

gsettings set org.gnome.desktop.session session-name \'gnome-fallback\'

(The escaped single quotes are necessary.) When I tried this from a text login, it didn’t give any indication of failure, but didn’t do anything. This page suggests that the command should be run with the environment variable GSETTINGS_BACKEND=dconf, but that didn’t change anything for me. My extrapolation was that the following command should also have done the trick:

dconf write /org/gnome/desktop/session/session-name \'gnome-fallback\'

but this gave a DBus error involving the inability to connect to an X11 server. It would surprise me if DConf required an X11 connection, but perhaps it does.

Sometime recently the publishers of Annual Reviews revamped their website and clearly put some effort into doing a better job — for example, Morales & Wyithe 2010. The design is more attractive. The figures and references float, so you can go between them and the text more easily. Internal and external links are more pervasive, and content is offered in multiple formats, including figures as PowerPoint slides for the truly lazy talk-preparer. There are definitely quibbles one could offer, but the overall experience is much nicer than anything else that I’ve seen. A similar amount of effort has been put into the overall website, linking together all of the journals. It’s really nice to see.