IDL syntax highlighting in VIM

I've edited my idlang.vim to auto-identify files that start with a semicolon.

Add Line 19:
syn match idlangStatement "^\s*;\s"

Line 61/2 (allow spaces before ;):
syn match idlangComment "\s*[\;].*$" contains=idlangTodo


AG

Mercurial - behave like SVN?

I'm trying to use hooks to make mercurial behave like svn when committing. I like the idea that I can commit changes to my cloned repo while I'm away from the internet, but I never want that behavior when I do have internet access. Therefore, I want to attempt to pull before updating and attempt to push after committing. Every time. I have been consistently very unhappy with the hg merge command.


[hooks]
precommit = hg pull; hg up
postcommit= hg push
post-pull = hg up


However, this doesn't work. precommit freezes with the error
waiting for lock on working directory of [dir] held by [procnum]

and pre-commit results in other errors:

running hook pre-commit: hg pull; hg up
pulling from [source]
searching for changes
no changes found
running hook post-pull: hg up
abort: outstanding uncommitted merges
warning: post-pull hook exited with status 255
abort: outstanding uncommitted merges
warning: pre-commit hook exited with status 255


AG

Repositories for observers

I should have posted these a while ago....
casaradio is a subversion repository for folks at The Center for Astrophysics and Space Astronomy at CU Boulder to post radio astronomy related codes. So far, emphasizes single dish (GBT, Arecibo), but will include EVLA, CARMA, and ALMA eventually.
aposoftware is a similar page, but is a mercurial repository and is meant to include instrument-specific software for the Apache Point Observatory 3.5m telescope. Right now includes a TUI script or two and the TSPEC and DIS IRAF-twodspec pipelines.

I'd be remiss to leave out the BGPS pipeline even though it's mentioned on the previous post.

Also, agpy is my personal code repository.

BGPS data paper published

Metalinking! The BGPS paper finally made it onto astro-ph today. It will be published in ApJS before the year's end.

Links to all of the published BGPS papers at the Bolocam Data Team website

And just because I want more linking, here they all are again:
The Bolocam Galactic Plane Survey I. Survey Description and Data Reduction arXiv
The Bolocam Galactic Plane Survey II. Catalog of the Image Data arXiv
The Bolocam Galactic Plane Survey III. Characterizing Physical Properties of Massive Star-Forming Regions in the Gemini OB1 Molecular Cloud arXiv
The Bolocam Galactic Plane Survey IV: λ = 1.1 and 0.35 mm Dust Continuum Emission in the Galactic Center Region

The same set of links is reproduced at the pipeline googlecode page.

Next Generation Astronomy

A brief commentary on a recent article Next Generation Astronomy :

I'm probably one of the folks who will be working on making that future happen, in the sense of being the intermediary between the end-user and the instrumentalist. Scientists are still needed to build instruments, but those who build the instruments don't necessarily have the time or expertise to build the software pipelines that generate high-quality data.

At the same time, the STARLINK folks do a much better job than I do, and I already spend about half of my time comparing different archival data sets... so I think his crystal ball is overall very accurate.

Converting a CLASS-created .fits file to a real (FITS-compliant) FITS file

This post is to remind me, the next time I go looking, how the hell to convert from a GILDAS CLASS fits spectrum (created by fits write blah.fits /mode spectrum) to a FITS-compliant spectrum.

First, remember the FITS-WCS spectral definitions: http://www.aanda.org/index.php?option=com_article&access=bibcode&Itemid=129&bibcode=2006A%2526A...446..747GFUL


And the peculiar CLASS definitions: http://iram.fr/IRAMFR/GILDAS/doc/html/class-html/node84.html

Key points:
CLASS stores the CDELT parameter as DELTAV in m/s instead of km/s and the velocity offset of the spectral frame in VELO-LSR also in m/s.

Things to set:
CTYPE = VRAD
SPECSYS = SOURCE
SSYSSRC = LSRK
VELOSYS = frame velocity (VELO-LSR or CRVAL1)

This information is subject to change...

Observing @ GBT: Signs of good & bad data

So far, all of the observations for the H₂CO densitometry project have been performed at the Green Bank Telescope. During a 10-day long observing trip here, I've learned a lot about diagnosing bad data.

This first image shows TSYS vs Airmass for good data. The high outliers are just sources with continuum in them - the continuum is the source of the extra signal, not atmosphere.  The receiver temperature is a nice 20.6 K, and you get about 5 K extra per airmass, suggesting a zenith optical depth of 0.018 assuming a round atmospheric temperature of 300K.

In the same style plot, there is a set of observations with low system temperatures: that stuff is good. There is also a set with clearly rising system temperatures, even at constant elevation. These data are bad. During this observation, the "blowers" that are meant to keep dew off of the receivers failed. Dew buildup on the receiver covers lead to higher optical depths and therefore system temperatures.

Finally, this data set was totally useless. Ku-band is not particularly sensitive to water in the atmosphere... but it's still not a good idea to observe during a rain storm.  Note that the fitted receiver temperature TREC is nonsensical.