Changeset 6123 for trunk/MagicSoft

Timestamp:

01/30/05 10:44:32 (20 years ago)

Author:

gaug

Message:

*** empty log message ***

File:

• trunk/MagicSoft/GRB-Proposal/Monitor.tex (modified) (2 diffs)

trunk/MagicSoft/GRB-Proposal/Monitor.tex

@@ -86 +86 @@
 \end{itemize}
 
-At the moment {\it arehucas} informs the shift crew about the alert and undergo
+At the moment {\it arehucas} informs the shift crew about the alert and takes
 further steps only in case of red alerts. In this case a pop-up window
 appears with all the alert information received 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
+A new button in the CC will be displayed and allows to point 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.
+In case of an alert -- even if it did not contain the necessary coordinates -- the
+information is  translated into ''human language'' and stored in ASCII files.
+At the same time an e-mail is sent 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 separate web page. The page is hosted on the web server in La Palma.
+The status of the GRB Alert System and relevant informations about the lastest
+alerts are displayed on a separate web page. The page is hosted at 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 everywhere.
+The web page updates itself automatically every 10 seconds. In this way
+the status of the Burst Alarm System can be checked from outside.
 
 \subsection{The acoustic alert}
@@ -119 +119 @@
 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.
+This device will keep also a display to check the status of the system and the alert.
 
 \subsection{Alerts received until now}
 
-Since July, 15th 2004 {\it gspot} has been working stable.
-It received 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 until 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$. It is a pity that the weather
+Since July, 15th 2004 {\it gspot} has been working stably at La Palma.
+It received about 100 alerts from HETE-2 and INTEGRAL, out of which 
+only 20 contained GRB's coordinates. Time delays
+were of very the order of of several minutes or even
+tens of minutes in most cases. The Burst Monitor can be considered bug-free since 
+November 2004. Since all bugs were fixed we received only one red alert from INTEGRAL on December 19th at 1:44 am 
+with a delay of 71 seconds. The GRB had a zenith angle of $\sim 60^\circ$. It is a pity that the weather
 conditions were very bad during this night.
 
-
-\subsection{Tasks to be arranged}
+\subsection{Procedure to be defined}
 
 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
+features needed to point and to observe a GRB. However, several
+procedures 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.
+The strategy to follow a {\bf Yellow Alarm} 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} 
+Then, the Alarm System would change to the {\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}
+\item {\bf Sequence of alerts}
+How to deal with new alerts that are distributed during the time 
+that {\it gspot} is in alarm state. Currently, {\it gspot}
 locks its alert status until 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 receive the alert. Indeed such situation can
-occur when more than one alert happens in the late afternoon or
-in the 5 hours before the beginning of the night-shift.
+the alarm state. 
+This feature was implemented in order not to
+loose any GRB information. 
+Such a situation can occur when the CC is switched off and thus 
+cannot receive the alert and if 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: 
+to implement a list of the available GRB alerts into {\it gspot} in which every
+item expires after: 
 
 \begin{itemize}
-\item having been noticed to the CC;
+\item having been noticed by 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.
+If more than one alert is present in the list, the program
+gives a marker to the prioritary GRB -- a decision based on the 
+total time of observability within the canonical 5 hours, 
+on the intensity of the burst and on the time until the GRB becomes observable.
+Such a marker should reflect our estimation of the chances to observe the GRB.
+The GRB with the highest marker will be noticed to the Central Control.
 
 \end{itemize}