Superevents are an abstraction to unify gravitational-wave candidates from multiple search pipelines. Each superevent is intended to represent a single astrophysical event.
A superevent consists of one or more event candidates, possibly from different pipelines, that are neighbors in time. At any given time, one event belonging to the superevent is identified as the preferred event. The superevent inherits properties from the preferred event such as time, significance, sky localization, and classification.
The superevent accumulates event candidates from the search pipelines and updates its preferred event as more significant event candidates are reported (see Selection of the Preferred Event). The name of the superevent does not change. The naming scheme is described in the alert contents section. Once a preferred event candidate passes the public alert threshold (see Alert Threshold), it is frozen and a preliminary alert is queued using the data products of this preferred event. New event candidates are still allowed to be added to the superevent as the necessary annotations are completed. Once the preliminary alert is received by the GCN broker, the preferred event is revised after a timeout and a second preliminary notice is issued. Note that the latter is issued even if the preferred event candidate remains unchanged.
Selection of the Preferred Event¶
When multiple online searches report events at the same time, the preferred event is decided by applying the following rules, in order:
A publishable event, meeting the public alert threshold, is given preference over one that does not meet the criteria.
In the case of multiple CBC events, three-interferometer events are preferred over two-interferometer events, and two-interferometer events are preferred over single-interferometer events.
In the case of multiple CBC events with the same number of participating interferometers, the event with the highest SNR is preferred. In the case of multiple Burst events, the event with the lowest FAR is preferred.
See also the preferred event selection flow chart in our software documentation.
A second Preliminary GCN is usually issued automatically after the first one is successfully dispatched to the GCN broker. However, this may not be sent if the superevent is vetoed on grounds of data quality before the alert is sent.
An additional preliminary notice may be issued by human intervention in case of unexpected circumstances to help in time-sensitive follow-up operations.
In case of an event created by a pipeline due to an offline analysis, no preliminary GCN will be sent.