Análisis multivariado

Before an alert can be distributed it must be vetted by a human, in order to avoid erroneous alerts going out and wasting valuable observing time on some of the worlds best observing facilities. Hence the data streams are monitored 24/7 by experts at each detector site control room, so when an alert is triggered they check the data for any obvious anomalies or disturbances at the time of detection and reject any that do. As pointed out in Figure 3.1 the target latency for this procedure was 10-20 min; however, in reality during O2 this latency was frequently exceeded.

Events which pass this vetting process are finally distributed to the partner EM observatories for follow-up imaging. This is done using the GCN (Gamma-ray Coordination Network) Network, which is a public alert system hosted by NASA and part of the broader VOEvent system (run by the International Virtual Observatory Alliance) (Allan et al., 2016). An illustration of this distribution network is shown in Figure 3.5 where the “author” in this case would be LIGO-Virgo collaboration, the “broker” is what mediates the system which in this case is on a NASA server, and the “subscriber” would be the PIRATE user.

This GCN alert system was designed, and is still used, as a public alert system to enable everyone from professional to amateur astronomers to receive the follow- up alerts of gamma-ray bursts or supernovae. However, because LIGO alerts were private during O1 & O2; anyone wishing to listen in to them had to sign the Mem- orandum of Understanding (MoU) with the LVC before they could receive these private alerts.

The main type of GCN alerts are called GCN Notices, these are machine readable alerts that contain key information regarding the time and characteristics of a grav- itational wave candidate. In addition to these there are also GCN Circulars which are human written bulletins delivered by e-mail directly to the EM observers, these are then used as a way of communicating follow-up observations and any potential

Figure 3.5: Illustration of the GCN alert network, part of the VOEvent network for astronomers. Credit: International Virtual Observatory Alliance (Allan et al., 2016)

counterpart discovery among EM partners.

There are two main methods by which GCN Notices are currently distributed to users: internet sockets and e-mail. The socket method involves maintaining a connection between two computers over the same network so alerts can be received, these alerts are then delivered as XML files that contain all the necessary informa- tion about an event. The email method allows observing sites without automated instruments to also receive the GCN Notices, albeit with a slightly longer delay time. These can be configured to be more human-readable or simply deliver a car- bon copy of the XML file sent out via the sockets method. Both of these methods are described on the GCN website2.

GCN Notices

As described above, a GCN Notice is a machine readable alert that contains key information regarding the time and position of a gravitational wave candidate, in

addition to this they also include a URL link to a copy of the relevant sky localisation map (Skymap). An example of what one of these GCN notices looks like is shown below in Figure 3.6; this particular alert was sent via e-mail so it appears more human-readable; however, it contains all the exact same data as the XML files distributed over the socket method.

Figure 3.6: Example of a GCN-Notice “Initial” alert produced by the LIGO-Virgo consortium (Singer, 2015).

The structure of these notices start off with identification information such as: date, time, type of alert and alert ID. Then there is also the LIGO observation data such as: trigger type, search pipeline, false alarm rate (FAR), chirp mass and maximum distance. In addition to this there are links to the associated Skymap and event web-page, these are important for the follow-up observations as without a Skymap the EM partners cannot react to the alert.

Firstly there are four different types of GCN Notices that can be distributed to EM partners, this is shown in (Figure 3.6) as the “NOTICE TYPE”, these are: “Test”, “Preliminary”, “Initial” and “Update”. The first one is self-explanatory but the other three form part of the real world alerts that LIGO produce when they have detected a candidate gravitational wave. A “Preliminary” alert is issued as soon as possible with a latency of a few minutes after the trigger verification, it contains just

basic information of the time and significance of the event, but crucially there is no Skymap attached. The aim of this is to give astronomers as much warning as possible to stop any current observations and prepare the telescope to start observations of an incoming Skymap. The “Initial” alert is sent with a latency of several minutes, this is due to the time needed for a Skymap to be generated by the detection pipelines, but this is still fast enough for the vast majority of observatories that participate in the EM follow-up of these events. Lastly, an “Update” alert is issued if offline analysis pipelines have computed a more accurate sky localisation map than the original alert. Typically these are sent several hours or even days after the initial event. Conversely, a retraction alert can also be issued if offline analysis shows that the statistical significance of the event is lower than first predicted (Barthelmy, 2015).

In addition to the four types of alert just mentioned, there are also two different types of event that an alert can be assigned. These are labelled as “GROUP TYPE” in the GCN Notices and they can be one of two events, either a Compact Binary Coalescence (CBC) or a Burst event. Including this group type in alerts allows astronomers to filter out the alerts they don’t want to receive; for example, if they are only interested in CBC alerts then the burst alerts can be filtered out.

Lastly, a new addition to the GCN Notices for O2 was the inclusion of a pa- rameter that indicated the probability that one or more of the CBC objects was a neutron star, labelled as “PROB NS”, with a range of 0-1 (Singer, 2016). This further empowers astronomers with the ability to filter out unwanted binary black hole (BBH) mergers, and only focus on receiving alerts where at least one of the ob- jects, if not both, are a neutron star. The reasons for this were discussed in Chapter 1, but essentially there aren’t predicted to be any EM counterparts to these BBH mergers, and given their frequency they could soon consume a lot of the observing time designated to follow-up telescopes, if they aren’t filtered out.

Skymaps The most important component of these alerts is the URL link to the Skymap, because this is the key piece of information that directs astronomers as to where they should perform their follow-up observations. As mentioned previously, this rapid sky localisation map (Skymap) is produced with a latency of a few minutes once a gravitational wave has been detected and the link to this is provided in the “Initial” GCN notice under the title “SKYMAP URL”. These Skymaps are 2D projection of the entire sky (see Figure 3.4) mapped in the HEALpix (Hierarchical Equal Area isoLatitude Pixelation of a sphere) format (see Figure 3.7), this type of map was chosen for statistical reasons because the entire sphere of the sky needs to be represented with pixels of equal size but not necessarily identical shape (G´orski et al., 2005). The resolution of the Skymap varies, as the HEALPix design is a hierarchical map with resolution increasing where the probability increases. Starting out from an initial 3072 pixels, the pixels containing the top 25% probability is subdivided into four smaller pixels, and this process is repeated up to the 8th order. The number of total pixels used to generate the Skymap varies but it cannot exceed 5x106_{, and the}

number of pixels with distinct non-zero values is approximately 1% of these. More details on this adaptive sampling are given in Singer and Price (2016).

These Skymaps can be either machine read or viewed through a HEALpix viewer in a browser, an example of the latter is shown in Figure 3.4. This particular Skymap was produced in relation to the first ever detected gravitational wave (GW150914), and what it shows is a multi-layer visualisation common to all Skymaps viewed on the LIGO website. In the background there is an all-sky projection to help illustrate the position of the target area and on top of this is a layer that consists of nine contour plots that each encircle an area on the sky with a probability density ranging from 10-90%. However in the machine readable version of these there is no need for any visualisation layers so it simply sends out a copy of the raw probability data for all the pixels.

Figure 3.7: A HEALpix grid displaying the pixels of equal area on a sphere (G´orski et al., 2005).