Alerts and brokers

Alert stream

The alert packets are individual ascii files containing measurements associated with the detection of a time-variable source in a difference-image.

Alert packet contents are world public and have no proprietary period.

Alert contents

All alert packets contain the following:

• a unique alert identifier
• observation metadata, such as the date, time, and filter
• astrometric and photometric measurements of the difference-image source
• detections in previously-obtained difference images (i.e., the light curve)
• derived variability characterization parameters
• identifiers of nearby static-sky objects from the latest data release
• small image cutouts of the difference and reference images

See the "Additional resources" section below for more details and sample alert packets.

Alert creation

Alert packets are created by the automated processing of every new LSST image with Difference Image Analysis (DIA). First, an archival reference image is subtracted from the new image, creating a difference image. Then, all positive and negative sources in the difference image that are detected with a signal-to-noise ratio of at least 5 prompt the creation of an alert packet.

Every new LSST image produces, on average, ~10,000 alerts within 60 seconds of image acquisition. As the exposure time for most LSST observations is 30 seconds, there are ~1,000 observations per night, and this adds up to ~10 million alerts per night, total.

Alert distribution

Due to the very high data rate of the LSST alert stream, alerts are distributed only to brokers and not to individual users. However, the same data that is distributed via alert packets is also stored in the Prompt Products Database, and is available for query and analysis via the Rubin Science Platform within 24 hours. Difference Image Analysis is also done as a part of the annual Data Release processing.

When will LSST alerts start to flow?

The early science program includes a plan to begin alert production once sufficient LSST reference images based on commissioning data can be created.

Alert brokers

Software systems that ingest and process astronomical alerts from the LSST and other surveys, and serve them to the scientific community.

Typical broker functionality includes:

• filtering alerts based on their measured properties
• cross-match association with archival or external catalogs
• identification and prioritization of objects in need of follow-up observations
• photometric classification based on light-curve analysis
• a web-based user interface for scientific analysis

Alert filter: a set of rules that an alert packet either passes or fails. For example, "if brighter than 21st magnitude, and if discovered less than 6 days ago, and if two previous detections exist, then pass" can be expressed as a set of constraints in a code script. This would be is a very simple filter.

Full-stream brokers

Due to the high bandwidth of the full LSST alert stream, only a limited number of brokers can receive it. The process by which the seven "full-stream" brokers were selected is detailed in "Plans and Policies for LSST Alert Distribution", LDM-612.

• Alerce: Automatic Learning for the Rapid Classification of Events
• AMPEL: Alert Management, Photometry, and Evaluation of Light Curves
• ANTARES: Arizona-NOIRLab Temporal Analysis and Response to Events System
• Babamul: an open-source, lightweight, easily deployable broker
• Fink: scalable, robust infrastructure for user-defined science cases
• Lasair: serving transient alerts to the astronomical community
• Pitt-Google: a scalable, cloud-based alert distribution service

Down-stream brokers

The "down-stream" brokers have science goals that do not require ingestion of the full LSST alert stream, and so they have partnered with one of the full-stream brokers to receive a subset of alerts of interest.

• SNAPS: Solar System Notification Alert Processing System
• POI Variables: Points of Interest Variables

How to choose a broker to use

First, have a specific science goal in mind, for example, to identify and follow-up a certain type of transient or variable.

Also consider whether you need to define and implement your own alert filter (or do your own photometric classifications), or whether you would use broker-provided filters and classifications, or the community filters described below. Some brokers provide the infrastructure for user-defined filters and classifications, but this does take a lot of work to set up.

Then, browse the brokers' documentation and web-based user interfaces. Several brokers are already processing and serving alerts from the Zwicky Transient Facility (ZTF). Create an account with one or more brokers that offer the services you need. Use the broker to try and identify subsets of ZTF alerts that would be relevant for your science goals.

Community filters

Up to 20 community alert filters will be defined, implemented, validated, and maintained by Rubin staff with input from the broad Rubin science community, and with support from the ANTARES broker. These community filters will be designed to serve a variety of common time-domain science goals, and lower the barrier to entry into alert-based science. Everyone will be welcome to use them.

More information to come soon.

Additional resources

• Section 3.5 of the Data Products Definitions Document, LSE-163
• "LSST Alerts: Key Numbers", DMTN-102
• "The Zwicky Transient Facility Alert Distribution System", Patterson et al. (2019)
• ZTF Alert Archive
• Sample alerts provided by Rubin Data Management

Questions?