Making Preliminary GRBs Real-Time Astronomical Reports

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.


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.

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].

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.
It is a public domain software, although there is currently no web-site to download the software, but an email can be sent to scastillop@gmail.com 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.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 All report information will be available through web page, email, and sms (not so detailed).

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:  (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(B−V) 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.(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.

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.

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).
(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(B−V), 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.
Rts2 satellite alert (HETE, INTEGRAL, SWIFT, • • • ) Parameters/input data file Parameters of N alerts Alert n RA DEC Date

Figure 7 :
Figure 7: Example of report received for GRB 070704.
Figure 3: Detailed operation of the software.
(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.