Abstract
We present a standalone software tool which makes reports for analysis and evaluation of GRBs. Recently, analysis and evaluation of GRBs were done without help of semiautomated tools or routines; so the time elapsed from the detection until getting all the information produced (DSS-2 data: Digitized Sky Surveys, elevation diagrams in each observatory, etc.) could be 30 minutes. The software presented allows to reduce the time elapsed to 30 seconds, getting an email, web, and sms reports.
1. Introduction
Gamma ray bursts (GRBs) were first reported by Klebesadel et al. [1] as they studied data acquired by the VELA spacecraft [2]. GRBs are the most luminous events known in the Universe. They are flashes of gamma rays, coming from seemingly random places on the sky and at random times, that last from milliseconds to many minutes. They are often followed by afterglow emission at longer wavelengths (X-ray, UV, optical, IR, and radio).
The longest GRBs are followed by an X-ray afterglow emission. GRB events take place in random sky coordinates, and their prediction are not possible. The majority of observed GRBs appear to be due to supernova explosion (longer GRBs) and binary systems collapse (shorter GRBs). GRBs can only be detected from space because the Earth’s atmosphere absorbs gamma rays and therefore we cannot observe them from the ground, although afterglow emission is possible to be observed.
2. Recent GRB Follow-up Systems
Following the BeppoSAX [3] and the High-Energy Transient Explorer 2 (HETE-2) [4] results in the field, other space observatories like Chandra [5] and XMM-Newton [6] are pinpointing the X-ray afterglow emission that follow the gamma-ray events. Recently, the International Gamma Ray Astrophysics Laboratory (INTEGRAL, from ESA) [7], The Fermi Gamma-ray Space Telescope (FERMI) [8], and Swift, (a NASA Midex Mission) [9] are increasing the number of GRB detections to about 100/yr.
The GRB afterglow emission can only be observed for few days; so, the time elapsed from GRB detection until its observation must be minimized. Once a GRB has been detected by one of the satellites mentioned above, rapidly analysis and evaluation of the alert info and external conditions need to be done. This helps to determine whether any reasonable followup effort is feasible, which helps making “Target of Opportunity” (ToO) proposals. Observations are scheduled if a transient event covered by the proposal occurs during the scheduling cycle. Analysis and evaluation of GRB were initially made by hand (observatories, instrumentation, elevation diagrams, Sun and Moon position in each observatory, etc.). This makes the time elapsed between the reception of the GRB alert and the production of this “followup” output as large as 30 minutes. However, it is possible to make them semiautomated with new technologies, taking not more than 30 seconds, which helps starting to obtain images, in several occasions, 3 minutes after the burst commenced [10].
Similar to Rapid Response Analysis of GRB Optical Afterglows [11], this work has been directed towards optimizing ToO techniques. Semi-automated programs and routines have been developed to facilitate faster and more efficient GRB follow-up. They are used in conjunction with other real time, online, automatic data analysis system: BOOTES [12].
3. Realtime Astronomical Report Software
One of the key issues in GRB followup observations is response time. The rapid fading of the GRB optical afterglow can make it fade below visibility within hours, which sets heavy demands on quick response times of any followup observations.
In order for the GRB ToO run to be successful, a number of conditions must be met. Here are listed some of the common problems that must be considered or solved during a run:
(i) visibility: whether the GRB field is observable at the telescopes, distance to Sun/Moon, and so forth;(ii) telescope availability: it must be determined which telescopes are actually available for ToO activation: night reserved for technical time, outside the time of the approved ToO programme, and so forth;(iii) size of error-field: the size of error-field can be dramatically different from one burst localization to the next, making it necessary to consider carefully;(iv) extinction: the position on the sky of the GRB-field with respect to the plane of the Milky Way is very important for evaluating the chances of a successful follow-up;(v) to provide the observer with charts of the GRB-field, to ensure that the position observed is the correct one.An application which makes GRBs reports has been developed at the Instituto de Astrofísica de Andalucía [13]. It streamlines and automates some of the previous procedures involved in GRB ToO operations. This application provides fast and detailed information on a given GRB on basis of a satellite localization alert. It helps to form a reliable basis for quick decision making regarding whether a ToO activation should be performed.
This application supports the ToO research projects BOOTES-1 [14], BOOTES-2 [15], and BOOTES-IR [16].
It is a public domain software, although there is currently no web-site to download the software, but an email can be sent to [email protected] to get the source/application, detailed instruction for installing, deploying and running, and any kind of support.
The details of software specification, design, and implementation are given next.
3.1. Specification
Functionality and requirements of software are listed.
(1) Input Data
(i)Type of alert: identified by a number(ii) Right ascension and declination of GRB(iii) GRB alert start time(iv) Error Box(v) GRB Id (grb trigger).
Input data are provided by another software: rts2 [17], which receives alerts from satellites through sockets [18] and makes the input data which are storaged into a relational database.
(2) Output Data
(i)Report title according to alert type:
INTEGRAL_WAKEUP, SWIFT_XRT_POSITION,
INTEGRAL_OFFLINE, FERMI_GMB_GND_POS,
SWIFT_BAT_GRB_POSITION, FERMI_LAT_GRB_POS_UPD.
SWIFT_FOM_OBSERVE,
(ii) Report time(iii) Time elapsed from GRB detection to report generation(iv) GRB galactic coordinates(v) Value from Lambert-projection maps: E(BV), Au, Ab, Av, Ar, Ai, Aj, Ah, Ak(vi) Moon and Sun right ascension and declination; Sun-GRB and Moon-GRB distance, Moon phase(vii) Observatories with approved Spanish ToO programme, telescopes, instrumentation, and so forth(viii) GRB altitude-azimuth diagrams in each observatory(ix)FITS and JPEG images of ESO Online Digitized Sky Survey using the Digitized Sky Survey (2n version, dss-2 [19]) (red, ir, blue) tool.
All report information will be available through web page, email, and sms (not so detailed).
3.2. Design and Implementation
This application is running in GNU/Linux 2.6.16.9 i686. In a basic diagram, general working of software is shown (Figure 1): when a grb is detected, this application is executed by rts2 (which provides the input data) and outputs three types of reports.
The system is composed of several modules. Some of them can run simultaneously; others need data to be received from other modules.
The most relevant modules of the system are the following:
(i)Make Title Report: Given type of GRB, it reports title of grb;(ii)Galactic Coordinates: it reports galactic coordinates from grb equatorial coordinates;(iii)Distance Sun-Moon to GRB: given equatorial coordinates of Sun and Moon, computes distance from GRB to Sun and Moon;(iv)Moon, Sun RA, and DEC: Computes equatorial coordinates of Sun and Moon;(v)elevation graph in observatories: computes, for each observatory of the database (with known latitude and longitude), grb elevation graphs;(vi)moon phase: given date and time, it reports Moon phase;(vii)list observatories, instrumentation, and so forth: Given a date and time, it reports, for every telescope of each observatory, who is the observer, instrument mounted, approved ToO programme, and so forth;(viii)dss-2: given equatorial coordinates and field of view, it returns digital sky image of that area;(ix)report time: it returns date and time when report has just been created;(x)dust_getval: it computes E(BV) extinction value;(xi)database observatories, instrumentation, and so forth: it is not a module, just a database which provides data to other modules;(xii)time elapsed GRBdetection-report generation: time elapsed from detection of grb to creation of this report.Execution order of modules is shown in Figure 2. An arrow indicates dependency between two modules: it leaves the module that provides the data and ends in the module which uses them. A module with no arrows mean that it does not need data and neither provides them to others.
Next, a more detailed working of above diagram is shown in Figure 3. It gives additional information of each module: technology used is reported within brackets, graphs paths of inputs and outputs, and so forth. Each module takes input data from left and generates output data to right. Input data of the application are on the left side of the diagram, and reports produced are on the right one.
Database storages all observers/researchers, instrumentation, telescopes, observatories, and country time observation in different tables and interrelationships between them in “Schedule timetable.” These data determine which telescopes are actually available for ToO activation for the coming night.
The most important entity is “Schedule timetable,” which establishes spatial and time entity relations between data storaged in the other tables. So, when a GRB is detected, the application will query the database and make a detailed report for all telescopes of each observatory: observer, instrument mounted, ToO programme, and so forth. Figure 4 shows simplified entity relationship model:
Below, there is a list of libraries and software required by this tool, with brief description of the actions performed by each one of them.
(i)rts2, Remote Telescope System, is an integrated open source package for remote observatory control under the Linux operating system. It runs the software presented in this work and provides input data (see Section 3.1). The software presented is not provided with rts2.(ii)Perl [20]: it is a high-level, general-purpose, interpreted , dynamic programming language. Perl borrows features from other programming languages including C, sh, awk, and sed. It is intended to be practical and support programming paradigms. Quick startup, powerful features, and true flexibility are some reasons for choosing this programming language to implement the system. The main module (and almost all the system, 80%) is written in perl, and also secondary or auxiliary functions (extract arguments from shell outputs, make base or main report, elevation diagrams, etc.).(iii) Astro: MoonPhase [21]: returns information about the phase of the Moon at a given time.(iv)Libnova for C,C++ [22]: general purpose, double precision, celestial mechanics, astrometry, and astrodynamics library. In this work it is used to calculate distance from grb to Sun and Moon, Sun position, Moon position, Moon phase, Horizontal and Equatorial Coordinates of objects (grb, Sun, Moon), and so forth.(v)dss-2 (sky digitized survey): the ESO/ST-ECF digitized sky survey (dss) application is a remote client program that extracts random sky section from the DSS image server installed at ESO, which covers the entire sky. The extracted images are delivered in standard FITS format and contain all header keywords needed to visualize proper celestial coordinates for any pixel position. This remote client application enables the creation of batch jobs to be integrated into other application software. So, once rts2 provides equatorial coordinates and size of error of the grb, the software presented executes this remote client to get images from dss which help to identify the grb in the sky.(vi)dust_getval [23]: given galactic longitude and latitude, it returns the reddening value E(BV).3.3. Output Report Format
Output report is divided into five sections (see Figure 5):
3.4. Example of Output Data
Some examples of report generated email and sms alerts are presented for GRB 070704 (see Figures 6 and 7). Report generated web page is close similar to email with different paragraph formats, and so web example is not included in this section.
(a)
(b)
An sms message issued for GRB 070704 will be received from phone number “SX233755s661703_20:08, 04/07”, with the following encoding:
SX: simplified GRB title. The simplified GRB titles are INTEGRAL_WAKEUP IO; INTEGRAL_OFFLINE IF; SWIFT_BAT_GRB_POSITION SB; SWIFT_XRT_POSITION SX; SWIFT_FOM_OBSERVE SF; FERMI_GBM_GND_POS FG; FERMI_LAT_GRB_POS_UPD FL.233755: right ascension in hours, minutes, and seconds.661703: declination in degrees, minutes, and seconds.20:08: UT GRB time.04/07: GRB Date (it is supposed to be the present year).4. Conclusions
Due to the transient and inherent unpredictable nature of gamma-ray bursts, it is of singular importance to minimize ToO response and ToO preparation times in advance of an alert. At the same time it is necessary to have easy access to all relevant information in order to rapidly devise the most efficient observation strategy in the limited time available.
A successful ToO system has been developed, which allows to achieve this through automation of the time-critical processes: Alert, Information retrieval, and ToO preparation and activation.
The automated system has effected in a much improved response time. It decreases the minimum delay from alert to ToO-activation. This system also reduces the significant overhead time required for evaluating the ToO-feasibility for each alert, freeds up a lot of resources formerly used to consider, and rejects unsuitable alerts for follow-up.
It allows rapid GRB alert response and follow-up, with minimum delay from alert to ToO-activation, accessing to all relevant information and rejecting unsuitable alerts.
Acknowledgments
The authors thank J. Gorosabel, Jelínek, P. Kubánek, and A. de Ugarte Postigo for fruitful discussions. This work was supported by the Spanish Ministry of Science and Technology’s projects AYA 2004-01515 and AYA 2007-63677.