The dissemination of astronomical events is slated to grow in importance after the recent Decadal Report from the US National Academy (more details). The top-ranked ground based facility is the LSST, which will survey a lot of the sky every three days, discovering what has changed, and is expected to release thousands of transients every night — asteroids, supernovae, variables, flare stars, active galaxies, and so on. And yet, to extract the science from this bounty there will need to be rapid followup by both small and large telescopes, some organization and infrastructure that is only now being thought through. Of course the majority of the transients are faint (the LSST is an eight-meter telescope!), and so needs an equally large, or larger telescope to get more detail about it. For the rare events that are astrophysically interesting, there should be a fast way to get the worlds big telescopes pointed to it.

It is not just difficult to get follow-up time on big telescopes, but also it is difficult to know which transients are interesting! The telescope will detect sources that are much brighter now than they were in the past, but the explanation is difficult from this sparse data. What is needed is more data! By analogy to normal life, suppose you hear a telephone ringing; you wonder which phone is ringing and who might be calling … but more information is needed, perhaps a follow-up observation (pick up the phone), or external information (you are expecting a call). This is the portfolio that comes with events in Skyalert, the essential co-information that allows decisions to be made.

In addition to understanding the astrophysical nature of the transient, another complication is that different people have different ideas of what is interesting. We need to know about these communities and what kind of event they want: a community that wants bright transients, another that wants asteroids or trans-pluto minor planets, or a community that wants transients near known X-ray sources. What will machines want, such as robotic telescopes, versus what human observers want? Is reliable delivery important, even several days after the observation? What kind of science can be done with a repository of events from multiple sources? And let us not forget the ‘multi-messenger’ astronomy that includes exotic channels such as gravitational waves or ultra-high-energy neutrinos.

So the next couple of years carries the challenge of building a suitable infrastructure for event distribution, something that can handle a wide variety of astronomical transients; something near real-time; something distributed and reliable, with no single point of failure; something that can scale up to large volume of events. One candidate is used all over the world for instant messaging, the XMPP protocol, it has many useful features, but also a little more complexity than the simple alternatives.

Sky surveys are quite responsive to the seasons and to the phase of the moon. As even the least observant person can attest, there are less stars visible at full moon than on a very dark night; and precisely the same is true of any optical observing. So the
phase of the moon means that faint objects can only be observed during part of the month, and that only bright objects (eg Jupiter) can be observed at full moon. In Skyalert, all of the CRTS telescopes shut down for several days around full moon. If you downloaded the CRTS iPhone app during full moon, you might give up on it as useless because nothing comes through for several days. But press on, keep watching!

Another active survey in Skyalert is the MOA (Microlensing Observations in Astrophysics) stream, which looks for brightening of stars due to gravitational microlensing. This method can be used to detect extra-solar planets, probe stellar atmospheres, and other science. The survey needs to observe the densest concentrations of stars, and thus monitors the center of the galaxy, the area of greatest stellar density, which is also known as the galactic bulge. This area is in Sagittarius, and so the survey cannot operate unless Sagittarius is well above the horizon at night: in the northern hemisphere this is May through August, and in the southern hemisphere May through November. So these surveys work only during the “bulge season” for a few months each year.

Another seasonal effect is weather. The CRTS1 and CRTS2 streams are observed from the mountains above Tucson, Arizona. During the summer, violent thunderstorms can happen suddenly, black clouds rolling in fast, then torrential downpour with a lightning storm. A delicate astronomical telescope could be ruined by such a storm: if not by water damage, then the exquisitely light-sensitive camera can be blown out by the brilliance of a lightning flash. Because of these risks, these two streams do not observe from the end of June to early September. Of course another reason may be that it is so hot during the summer that everyone involved is on vacation elsewhere! However, the third of the group, CRTS3, is taken from Australia, and is not affected by the Arizona monsoon season, so that will continue through the next months.

Please take a minute to tell us who you are and how Skyalert can be more responsive to your needs. Thanks!

Click Here to Take the Survey

Skyalert is broader than astronomy, and works with rather general concepts, as described below.

Sensors: Some sensors report events directly, others make continuous data streams. In the latter case, there may be a pattern-matching pipeline, to decide when there is something “interesting” in the data. But in both cases, a sensor produces “observation events”: time-stamped bundle of data that expresses what the sensor is reporting.

Events: We perceive the notion of “event” in several ways: as discussed above, it can be the output of a pattern-matching algorithm on a continuous stream from a sensor. Other types of events signal the change in status of a sensor: online, offline, in lock, etc. There are also follow-up events, where a sensor is directed to point at what another sensor has reported in an observation event.

Action: Events may cause action. Such actions may include fetching from an archive, running a computation, directing a follow-up sensor, or alerting a human. Such actions are taken predicated on a trigger function, that examines all the data associated with the original observation, including archives and follow-ups, and produces a boolean result: to take the associated action or not.

Portfolio: All the data about the event is stored together in a “portfolio”. It is multiple sourced because different sensors, archives, mining software, follow-up sensors, etc are all built by different organizations and report different kinds of data; so it can be difficult to assess the meaning of a portfolio for decisions. We solve this by taking a very simple approach, where everything in the portfolio is a key-value pair, with complex data objects having both a URL pointer as the value, and a semantic URI defining the nature of that complex data. The meanings of the key-value pairs are provided well in advance of the event cascade by those who are providing events. Note that actions may result in new follow-up events being added to the portfolio, which may result in further actions.

Skyalert.org collects many streams of astronomical events, and provides the capabilities described above for real-time intelligent filtering and actions. Microsoft Worldwide Telescope provides display of all recent events, and allows detailed examination of individual events in many wavelengths. Skyalert also allows users to build custom event feeds (Atom), create custom software modules for mining the portfolio, and get custom messaging when interesting events occur. In terms of astronomical transients, we are working closely with the LSST project, expected to produce 100,000 astronomical events per night. We are working with the LIGO/Virgo gravitational wave detectors, as both producers and consumers of events. We have relationships with many event providers, including CRTS, SWIFT, Fermi, GALEX, LOFAR, VERITAS, MOA, and many others.

We are interested in working with people who might be interested in:

• Adapting the above model to other fields outside astronomy,
• Scalable real-time networking for the LSST firehose of events,
• Pushing the envelope with feeds, instant messaging, and distributed repositories.
• Working with Worldwide Telescope to display event histories and correlations.

Many people do not like registering for a website, so this article is about what you can do in Skyalert if you register and log in. Registration allows you to create an Alert. Or many of them. Each Alert is a filter on an event stream, executed whenever a new event appears — essentially a decision about whether the new event is “interesting”. One result of that filter is a “feed” of interesting events that can be read by many internet tools. In Yahoo Pipes, for example, feeds can be combined and selected, used to alert a mobile device, or other kinds of messaging. iGoogle will collect feeds and other gadgets on an attractive “home page”.

An Alert uses data not just from the event itself (first observation), but also from a portfolio of other data perhaps from archives, follow-up observation, comment, or classification. This is all available in order to build the alert, so it can be quite a precise selector. The Alert is written in the following syntax based on Python, for example this uses the MOA stream:

MOA["Paczynski model parameters"]["Ibase"] < 21

Which means that events from the MOA stream are “interesting” if they are brighter than 17th magnitude. The parameter names were chosen by the authors of that particular stream.

Let’s go through the process of building an alert. (First you need to register, return the email, and login). Click here to see the list of your current alerts. At the top, click on “For a New Alert Click Here” and select the event stream that you want, perhaps SWIFT, or CRTS3, or MOA. At this point, you can select secondary data that is necessary for your Alert — perhaps events where a human-written circular has also appeared and been added to the portfolio. Selecting secondary streams reduces the flow of your Alert filter by requiring additional data in the portfolio.

Click on “Continue to next step”. Give your alert a name, so you know which is which, and decide what should happen when the portfolio becomes interesting. To have an email sent, the action type should be “alert_email” and the email address below it. To just get the Atom feed of the events, make the action type blank.

The “trigger expression” is a piece of code that defines when an event is interesting. It uses the data from the portfolio to make a decision, of which more below. But for a first Alert, just put the word True in the trigger expression, meaning that all events are interesting and pass the filter.

Now click the “Save” button. You can also click the button “See past events”, which shows a table of recent events that satisfy your Trigger. If there is nothing in the table, then you may have chosen a stream that does not yet have any events, or your trigger criterion too strict.

Going back to the “My Alerts” page, and you can see your new alert three ways: for editing the alert or deleting it, and also a link to the corresponding Atom feed. This is what you can use in Yahoo Pipes or iGoogle, or other web applications that work with feeds.

Let’s do a more complicated alert example. Suppose a supernova hunter wants likely targets, meaning transients from the CRTS survey that are both bright and close to a galaxy from the SDSS survey, let’s say within 5 arcseconds. We use galaxy proximity as a proxy for likelihood the event is a supernova. From myAlerts click on New Alert, then select CRTS as the primary stream, and when you access the secondary streams, choose SDSS. Click “Continue” and you should see the Primary (CRTS) and Secondary (SDSS). Now we build the Trigger: clicking on the parameter names below will insert the right text into the Trigger Expression, so go ahead and click “First Detection params | magnitude” from CRTS and “nearest_gal | distance” from the SDSS, then go back to the Trigger Expression text. Edit things until it looks like this:

CRTS["First Detection params"]["magnitude"] < 19 and SDSS["nearest_gal"]["distance"] < 5.0

then click “Save”. You can see the feed from this alert, or something like it, at the “System Feeds” page.

You can also see the feed from your own alert: go back to myAlerts and click the relevant “feed” link. That URL is a representation of the feed from your personal definition of what is “interesting”. It can be used in iGoogle, Yahoo, or make you phone ping to say something interesting is happening in the cosmos.

Perhaps I could chat a bit about what are the various streams that Skyalert is slurping and spitting.

The front page, http.skyalert.org, shows a timeline of recent events — it is the dark blue panel with colored dots on it that comes up a few seconds after the main page. If it does not come up, and you continue to see “waiting for event server”, then you should make sure that Javascript is enabled in your browser. The most recent events are to the right, and the scale at the bottom of the chart shows the ages of the events, in a quasi-log plot from an hour to a day to a week to a month.

A prolific provider of events is the Catalina Realtime Transient Survey, which has three event streams called prosaically CRTS, CRTS2, and CRTS3 for the three telescopes, which are (respectively) on Mt Bigelow in the Catalina mountains near Tucson, Arizona, on Mt Lemmon, also in the Catalina Mountains, and at Siding Spring in Australia. These three telescopes operate much of the month, except near full moon, each delivering perhaps a dozen or more transients on a bountiful night. A related stream is the Catalina Sky Survey, called CSS_NEO for short, which operated from the same telescopes and data stream as the CRTS survey. The difference is that CSS_NEO reports the moving objects from the data stream, and CRTS reports stationary objects whose magnitude has increased. The discovery of moving objects (that might be “killer asteroids”) is the primary funding motivation for the survey, and also explains the timing: each event that Skyalert displays has four images, 20 minutes apart, and a fifth, deeper image that combines previous observations. The cadence of 20 minutes is carefully chosen to make clear the drift of an asteroid. CSS_NEO events come with both the observation record (where the asteroid was seen), and also a predicted ephemeris for the next few hours so that rapid followup is possible.

Another prolific stream is MOA: Microlensing Observations in Astrophysics, which runs a 1.8m telescope in the Southern Alps of New Zealand, with Japanese collaborators. It makes observations on dark matter, extra-solar planets and stellar atmospheres using the gravitational microlensing technique.

NASA also contributes several event streams. The SWIFT satellite has been catching Gamma-Ray bursts since 2004, and has now reported its 500th burst. Its discoveries range from a nearby nascent supernova to a blast so far away that it happened when our universe was only 5 percent of its present age. NASA also supplies events from the Fermi observatory, also in orbit, which reports events from the burst monitor instrument (GBM) in the photon energy range 8 keV and 40 MeV. We hope that in the future the other main instrument of Fermi (Large Area Telescope) will also be reported publicly so that Skyalert can report them.

Soon, Skyalert will be reporting another prolific stream, from GALEX, another NASA satellite, in orbit since 2003, surveying the ultraviolet sky. The transients are currently reported at the GALEX transients page, and we are working to convert these to Skyalert format.

The theme of Skyalert is near-real-time reporting of astronomical events, and we have agreements from many such providers that have not yet begun to produce events on a regular basis. And there are, of course, several privately-held astronomical event streams that do not want their events distributed to the public.

When astronomical events are reported, there is often a distinction between Notice and Circular: the former is made by machine, the latter by a human. Skyalert brings together these machine and human versions of the truth.

The CRTS stream is generated automatically: the machine looks for sources whose magnitude has brightened by 2 during four exposures 20 minutes apart. The cutouts are generated, lookups made to the Virtual Observatory for how the source looks in other surveys, if it is a known variable, etc. Later, an assessment is made by CRTS staff of what the event might represent, and that is also published into Skyalert. You can see an example here, (scroll to the bottom) where the 13th magnitude transient is identified as the known cataclysmic variable TT Tau.

The same effect happens with the SWIFT alerts, from NASA’s Gamma-ray observatory in orbit, for example here. Scroll to the bottom to see the SWIFT Circulars that explain the meaning of the automated observations.

When viewing a Skyalert event, there can be several different pieces of data shown. Each has in the left margin the four links Overview, Params, XML, None. By clicking these, you can change the representation of that piece of data. Give it a try!

Welcome to the Skyalert Blog, this is the first entry.

The project has been going for a year, taking astronomical transients and sending them out. There has been a big change in the last few weeks, as we have shifted to Atom feeds for event dissemination. You can see the feeds here, these cover some of the more interesting streams: the bright ones from the CRTS survey, the Supernovae and AGN outbursts if that is your interest, SWIFT and Fermi alerts, and others. In the old scheme, it was the Skyalert server sending out email notification and connecting directly to the Twitter server, and thinking how to make mobile-phone uploads. But now the feeds provide the information, but other (non-Skyalert) services can do the mashup, email notification, Twitter, etc — tools like Yahoo Pipes and Feedburner.

For example here is a feed combining other feeds, they are bright CRTS events, SWIFT GRB detections, and bright asteroids from the CSS_NEO survey.

So we will start backing out the special Skyalert code for email and twitter, and use cloud based tools instead for those. Next on the agenda — how can we get a robotic telescope, or even an Arduino to respond to a new event on a feed.