Las preferencias reproductivas: análisis descriptivo

The PIRATE alert pipeline (see Appendix A) is written in Python (Rossum, 1995) and is based upon the LIGO-Virgo EM follow-up tutorial script written by Leo Singer3,4(Singer, 2015). This is itself based upon an older version written by Singer that processed generic GCN alerts, but since the LIGO-Virgo alerts weren’t public, the process to receive them was more specialised. This tutorial script was aimed at LIGO-Virgo EM follow-up partners to enable them to receive, filter and process gravitational wave candidate alerts. The author made use of all these functions and added extra functions to communicate with the PIRATE telescope scheduler; thus creating one all-encompassing pipeline.

The final version of the script requires several additional python packages to run, these include: pygcn (to connect to the GCN network)(Singer, 2018), requests (enable HTTP downloads in Python)(Reitz, 2011), healpy (to process HEALPix images)(G´orski et al., 2005), astropy (for several observing tools)(Astropy Collab- oration et al., 2013), numpy (Van Der Walt et al., 2011) and matplotlib (for plotting tools)(Hunter, 2007), subprocess (to run Bash scripts from Python) and math (for mathematical functions). The code itself can be separated into it’s three main tasks, these are: connecting to the GCN Network, processing incoming alerts and passing observing requests on to PIRATE.

3.2.1

Connecting to the GCN Network

The LIGO-Virgo gravitational wave candidate alerts are distributed via the GCN Network (as described in subsection 3.1.3), therefore to be able to receive these it is

3

http://nbviewer.jupyter.org/github/lpsinger/ligo-virgo-emfollowup-tutorial/ blob/master/ligo-virgo-emfollowup-tutorial.ipynb

4_{A more up to date tutorial has now been published to prepare for public alerts during O3, this}

necessary to connect to the network. To do this requires a new site configuration5

which was only initially accessible to groups that signed the MoU with the LVC. In addition to this the pipeline also requires a “robot password” to be able to receive confidential files from GraceDB once an alert has been received. This is a crucial step that must be renewed every 12 months when the robot password expires and a new one should be generated. To use this with the script a new “.netrc” file has to be created on the host PC which contains all the credentials required to access the GCN Network.

Connecting to the network requires just one line of code to run, this is the very last line of Appendix A which starts with the function “gcn.listen”. There are three arguments sent with this function and these include: the IP address of the host GCN server to connect to6, the designated port number for private LVC alerts (in this case 8096) and lastly the “handler” argument tells the code what function should be run once an alert is received, and in this case it is the “process gcn” function, which will be described in the next subsection.

Once the code is set running it should automatically connect to the designated server and listen out for incoming alerts; if it has failed to connect an error message will be displayed saying the connection timed out. The output should remain silent until an alert is received, but once one arrives it will be processed and the alert properties will be displayed in the terminal. The code will continue to run and listen for other alerts until it is terminated by the user.

3.2.2

Processing GCN Alerts

The next stage of the pipeline involves processing the alert after it has been re- ceived; to do this there are multiple functions within the script. Starting with

5

https://gcn.gsfc.nasa.gov/lvc\textunderscoreconfig\textunderscorebuilder.html

“process gcn”, this function saves the alert as an XML file on the host PC, using the GraceDB ID as the filename, and also prints a copy of the alert to the terminal. This step is done for all alerts, regardless of type; however, in the following lines of code the user has the ability to swap between processing test events or real events. This is useful for testing purposes as there are automated test alerts sent from the same servers every 4-5hrs. These lines can be suppressed or included in the code, depending on the needs of the user; but if no filtering is applied, all alerts will be passed on to the next stage of the pipeline.

The filtering of events by type, e.g. “CBC” or “Burst” events was removed from the original tutorial script because the author was interested in following up all types of alert but these can be re-included at any point. All parameters in the XML file are filterable so there’s also the possibility to introduce a filter for the new ‘PROB NS” parameter mentioned in subsection 3.1.3, this would enable the script to filter out all alerts except CBC alerts containing at least one neutron star.

The next step in this function is to call another function in the script called “get skymap”, this enables the pipeline to locate and download the relevant skymap corresponding to each alert. It uses a “root.find” command to look up the URL of the skymap in the XML file created earlier, and then uses the “requests” package to send a HTTP request for the skymap. Once the script has obtained a copy of the skymap it then saves it as a .fits file and passes it back to “process gcn”. From there the skymap is sent in HEALPix form to another function within the script called “tabletest”.

The aim of this function is to filter out unwanted pixels from the skymap and convert the observable ones into RA & Dec observing fields. To do this it begins by inspecting the metadata for the skymap, and assigning each pixel of the skymap a unique RA & Dec value. This is then collated in a table with the following four headers: Pixel Number, Probability, RA & Dec. Next the pixels below -40◦ Decli-

nation are removed as they are below the observing limit of the PIRATE telescope in Tenerife. Subsequent steps remove all pixels below a certain probability thresh- old set by the user and re-sort them by descending probability, in this instance the threshold is set at 6.67%; meaning only the top 6.67% of pixels in the skymap are kept. Then the script saves a CSV copy of this table before proceeding any further to enable users to check which and how many pixels are trying to be observed.

Following on from this is a process to convert the pixels into observing fields, this is made more complicated by the fact that the resolution of the pixels is higher than the FoV of PIRATE. To get around this a new array of “observed” pixels is created from the previous table by only including pixels that are at least 42arcmin away from another pixel in either RA or Dec. This results in a table of observing tiles that shouldn’t overlap by more than a few arcminutes with any adjoining pixels, maximising the coverage of the skymap. The script again saves a CSV copy of this output before passing it on to another function called “OSO API Uploader” which uploads them immediately to the telescope’s schedule. Ideally the script would also filter pixels based on their observability at the current epoch; but this task was performed by the OSO scheduler anyway (see subsection 3.3.2).

Figure 3.8: An example of the JSON file uploaded to the OSO Scheduler by the follow-up pipeline, containing all the input fields for the telescope.

The final stage of the pipeline involves uploading observations from the script to the telescope via the OSO scheduler. The is done by generating a unique ID and priority for each observing tile, this ensures that no two fields are identical. For each observing tile a unique observing request can be generated in the form of a JSON file (see Figure 3.8); containing all the necessary observing information such as: exposure time, filters, repeats etc. Each individual JSON file can then be uploaded via URL to the OSO Scheduler API using the correct hyperlink and hashkey. The script is programmed to return text to the terminal so the user knows if the observing requests have been successfully uploaded to the scheduler. Lastly, one more command is required by the OSO scheduler to prompt it to request a new schedule, this is called a “Clear Queue” command, and it is required to force the telescope to request a new schedule, containing the new observing requests.