Changeset 6102 for trunk/MagicSoft/GRB-Proposal

Timestamp:

01/28/05 18:17:18 (20 years ago)

Author:

galante

Message:

*** empty log message ***

File:

• trunk/MagicSoft/GRB-Proposal/Monitor.tex (modified) (1 diff)

trunk/MagicSoft/GRB-Proposal/Monitor.tex

@@ -1 @@
-\section{The GRB monitor at La Palma}
+\section{The Burst Alarm System at La Palma}
 
-\subsection{The socket connection to GCN}
-\subsection{The GRB webpage}
-\subsection{The accoustic alert}
-\subsection{The interface to the Central Control}
-\subsection{Emails to the GRB-mailing list}
+{\bf Current status:}
+
+\par
+
+The Burst Alarm System is installed and working since last summer
+in La Palma. The duty of the Burst Alarm System
+is to perform a full-time survey of the GCN (Gamma-Ray Bursts
+Coordinates Network) alerts. Different satellite experiments perform GRB monitoring
+in their wide FOV and send immediately the coordinates of the GRBs to the GCN network.
+The network send the alerts to registered users and allows other satellites as well as
+ground based observatories to observe the GRBs and their afterglows at different wavelenghts.
+The Burst Alarm System is composed by a main program -
+the core of the system - which acts in two ways: on the
+one hand it manages the monitoring of the GCN, on the other it manages
+the communication with the Central Control (CC). Then it also manages
+three communication channels to notice the shifters
+about a alert situation. The program is called {\it gspot} (Gamma
+Sources POinting Trigger). It is a C based daemon running 24
+hours a day onto the {\it www} machine, our external server, in a
+{\it stand alone} mode. It do not need to be operated and is
+fully automatically able to manage network diconnections
+within the external net and/or the internal one.
 
 
-\ldots {\bf NICOLA } \ldots
+\subsection{The connection to GCN}
+
+The connection to GCN is performed by {\it gspot} through a
+TCP/IP connection within a computer at Goddard Space Flight
+Center (GSFC). This computer distributes the informations it is recieving from the satellite
+experiments through the normal internet socket connection. The {\it gspot} onto our
+side acts as a server while the client, running at the GSFC,
+manages the communication of the data concerning the GRBs
+and concerning the status of the connnection. \\
+
+The format of the data distributed through GCN differ between the individual satellites
+and the kind of package. There are three satellites participating in the GRB survey:
+HETE-2, INTEGRAL and SWIFT. All are sending alerts which include the
+UTC, coordinates (not always), error on coordinates
+(not always) and intensity (photon counts) of the burst.
+The first notice from HETE-2 and INTEGRAL usually do not include the coordinates.
+In only few cases coordinates are distibuted delayed in more refined notices.\\
+
+In case of an alert {\it gspot} stores the informations and enters into
+an {\bf Alarm State}. The duration of the alert state depends on the following parameters:
+
+\begin{itemize}
+\item {\bf darkness of the sky}, determined from the distance of the sun
+to the astronomical horizon of 108$^\circ$ zenith;
+\item {\bf position of GRB}, the GRB equatorial
+coordinates are transformed into local horizontal coordinates and comparised whether the
+GRB zenith angle is smaller than 70$^\circ$; in the case that moon is
+shining in the sky, we propose to reduce this zenith limith to 60$^\circ$;
+\item {\bf position of moon}, checking whether the angular
+distance from the GRB to the moon is at least 30$^\circ$.
+\end{itemize}
+
+If one or more of these conditions failed then {\it gspot}
+enters into a {\bf Yellow Alarm State}. It means that the GRB is not observable
+at the moment. Currently the program do not calculate if and when the GRB will
+become observable at La Palma.
+If all conditions mentioned above are satisfied,
+{\it gspot} enters into a {\bf Red Alarm State}, which means that
+the GRB is considered to be observable at the current time.\\
+
+In both cases (in RED and YELLOW alarm state) {\it gspot} assamble the communication
+with the CC and sends the GRB equatorial coordinates (RA/DEC J2000).
+For the communication to CC the format defined in \cite{CONTROL} is used. In the same time
+the shifters and the GRB-MAGIC group is contacted in different ways described in the next sessions.
+
+\subsection{The interface to the Central Control}
+
+An interface of {\it gspot} sends all the relevant informations about it's status to {\it arehucas}.
+In the case of {\bf NO Alarm State} the standard packages, containing the main global status
+of the two subsystems, are continuosly excanged between CC and {\it gspot}.
+In the alert case {\it gspot} starts to send to CC special alert packages,
+containg major informations of the GRB and on the ''colour'' of the alert.
+The exchange of the alert packages continues untill the following steps occur:
+
+\begin{itemize}
+\item {\it gspot} get from {\it arehucas} the confirmation
+that it recived the alert notice; {\it arehucas} must send the alert back in order to
+to perform a crosscheck of the relevant data;
+\item the alarm state expire after {\bf 5 hours}.
+\end{itemize}
+
+At the moment {\it arehucas} informs the shift crew about the alern and undergo
+further steps only in case of red alerts. In this case a pop-up window
+appears with all the alert information recived by the burst monitor.
+The operator has to confirm the notice by closing the pop-up window.
+He can decide to stop the current scheduled observation and to point the GRB.
+A new button in the CC will be displayed and allows to point the the telescope to
+the GRB coordinates by pushing it.
+
+\subsection{GRB archive and emails to the GRB-mailing list}
+
+In case of an alert, even if it did not contain the necessary coordinates, the
+informations are translated into ''human language'' and stored into ASCII files.
+In the same time an e-mail is send to the MAGIC GRB-mailing list.
+
+\subsection{The GRB web page}
+
+The status of the GRB Alert System and relevant informations from the last
+alert are displayed on a seperate web page. The page is hosted on the web server in La Palma.
+The address is the following:\\
+
+\qquad \qquad http://www.magic.iac.es/site/grbm/\\
+
+The web page automatically updates itself every 10 seconds. In this way
+the status of the Burst Alarm System can be checked from everywere.
+
+\subsection{The acoustic alert}
+
+A further CC-indipendent acoustic alarm called {\it phava} 
+(~PHonetic Alarm for Valued Alerts~) will be installed
+in La Palma very soon. It will provide a loud acoustic signal
+even if {\it arehucas} is switched off, so that people in the counting house
+will be noticed about the alert situation. The signal will be on as long as
+{\it gspot} stays in alarm state, and in any case for a minimum of 1 minute.
+This device will keep also a display where to fast check the status
+of the system and of the alert.
+
+\subsection{Alerts recived untill now}
+
+Since July, 15th 2004 {\it gspot} has been working stable.
+It recived from HETE-2 and INTEGRAL about 100 alerts, most of them without coordinates.
+More precisely only 20 of them contained GRB's coordinates. Time delays
+were in most cases very large - in the order of of several minutes or even
+tens of minutes. In the beginning the Burst Monitor contained some bugs so that we can not
+rely on the alerts untill November last year. Since the bugs were fixed we got only one red alert.
+This alert came from INTEGRAL with a delay of 71 seconds, it happened
+on December 19th at 1:44 am and the GRB zenith angle was $\sim 60^\circ$. Pitty that the weather
+conditions were very bad durnig this night.
+
+
+\subsection{Tasks to be arranged}
+
+The Burst Alarm System is currently able to provide the minimum
+features needed to point and to observe a GRB. Anyway several
+things must be defined in order to improve our efficiency
+to point and observe GRBs.
+
+\begin{itemize}
+\item {\bf Yellow Alarm strategy}
+First of all the strategy to follow in case of a yellow
+alarm, i.e. in case of a not observable GRB, is not defined yet.
+In such a case the CC does not undertake any steps,
+except confirming the alarm notice to the Burst Monitor. We do not
+calculate if and when the GRB will become observable.
+It would make sense to check if during the period of 5 hours we could point to the burst.
+Then the Alarm System would change to {\bf Red Alarm State} 
+at that time and allow the observation.
+
+\item {\bf sequence of alerts}
+Another procedure that needs to be defined is how to deal with new alerts
+that are distributed during the time that {\it gspot} stands
+in alarm state. The status of the system now is that {\it gspot}
+locks its alert status untill it exits
+the alarm state. This feature was implemented in order not to
+loose GRB informations due to nasty events. 
+Such situation can appear ONLY when the CC is switched off so
+that it cannot recive the alert. Indeed such situation can
+occour when more than one alert happens in the late afternoon or
+in the 5 hours before the beginning of the night-shift.
+In such a case we propose
+to implement into {\it gspot} a list in which every
+item is a GRB's alert that expires after: 
+
+\begin{itemize}
+\item having been noticed to the CC;
+\item the canonical 5 hours.
+\end{itemize}
+
+If more than one alert is present in the list then the program
+gives a mark to the GRB based on the total time of observability
+within the canonical 5 hours, on the intensity of the
+burst itself and on the time to wait to get the GRB observable.
+Such a mark should reflect our estimation in the chances that
+we have to observe that GRB.
+The GRB with the highest mark will be noticed to the Central Control.
+
+\end{itemize}