There have already been a few mentions of how we can use VOEvents to automatically trigger observations of interesting transients. I’m going to talk about a project we’ve been working on to actually put in place a prototype system that does exactly that. First I’ll talk a little bit about the radio telescope we’ve been using, AMI, and the transients we’ve been triggering on. Then I’ll tell you how we made it work. And finally I’ll show you some early results and talk about what we’ll do next.
This is the radio telescope we’ve been using. AMI is an aperture synthesis array located in Cambridge. There is a large and a small array. Originally designed to map out the Sunyaaev-Zeldovitch effect, the observation wavelength is centred at 15GHz, but the bandwidth is actually 4.5GHz, split into six channels. Point source sensitivity is about half a milliJansky at the five sigma level, weather permitting. They’ve been looking for new usage pattern.
The SWIFT burst alert telescope provides transient targets which are a good match to AMI’s capabilities. The localization area roughly matches the AMI primary beam, and we get about one target per week in the Northern hemisphere. As of about 2 months ago, GCN have been publishing their alerts in VOEvent format, which ties in nicely with our system. Crucially, we think we can produce some interesting results following up GRBs with AMI.
For an overview of GRB science I shall refer you to Alexander’s earlier talk. As a quick reminder, we’re looking for phenomena such as the reverse shock, which may be radio bright soon after the prompt emission.
Some of you may have seen this plot before, it’s reproduced from a paper by Chandra and Frail that came out in February. The paper is a catalogue of radio observations of GRBs. This is a histogram of when the radio observations were taken, relative to the initial gamma ray burst. As you can see, most are taken about between about one and three weeks, when the forward shock afterglow usually peaks in the radio, depending on the redshift of the system and your wavelength of observation. We observe a radio afterglow for about one third of long-duration GRBs.
Zooming in, we see that only a handful of radio followup observations have been made in the first 2 hours following prompt emission. So clearly there’s an unexplored region of parameter space here. I should note this is slightly misleading — there was in fact a project very similar to ours using the Ryle telescope in the mid 90’s. A handful of triggers from the Compton Gamma ray observatory were observed with the Cambridge low frequency synthesis telescope, within minutes. However the non-detection limits were tens of Janskys, and the relatively poor localization from the Compton Observatory meant that only serendipitously matched
Firstly I should mention the systems we rely upon, those of the Gamma-Ray co-ordinates network and the response system built for AMI by David, but I won’t go into detail on these in this talk.
There have been a couple of software packages developed recently, which may be generally useful to those of you interested in transient alerts. For those of you who aren’t familiar with the jargon, VOEvents are simply packets of data in XML format which provide information on transients in a machine readable form. If you want to receive astronomical alerts in real time, you need to connect to the VOEvent network. Comet allows you to do just that. It’s a python based package, written by John Swinbank, completely open source, and we’ve been using it reliably for few months now.
NEW SOFTWARE Pysovo — alert triggering utilities Extends easily to multiple triggers and multiple telescopes. Alert logic defined globally or per observatory Ephemeris calculations Trigger via email, VOEvent, SSH Notifications system
When you receive some new information on an astronomical transient, you need a method to automatically determine whether or not to trigger a followup observation. Then if you do want to followup, you need to actually the make the observation request. Pysovo is a python package to help you do just that.
Most of our observations are actually on target in about 5 minutes of the prompt emission, which is way ahead of previous observations. This breaks down as follows
There’s a delay of 13 to 30 seconds after the prompt emission, while the initial location is calculated from the coded mask data, on-board SWIFT. This is then downlinked to NASA, and about 2 seconds later it’s broadcast via GCN in VOEvent format.
It’s then picked up by our machine in Southampton running Comet, and passed to Pysovo. If the source is above a declination of -10 degrees, we fire off an email to AMI requesting an observation as soon as possible. The total time from NASA broadcasting the notice to AMI beginning slew is about 5 seconds. We then have a 4 minute wait to ensure that the 30 ton dishes have time to reach their new angle. It should be possible to improve on this when the ToO is serendipitously close to the present pointing.
oxfordtkp
bkeepers
denniskardys
productmarketing
brettharned
marcelosomers
dougneiner
garrettdimon
honnibal
malarkey
chrislema
speakerdeck
