Index: /trunk/MagicSoft/GRB-Proposal/Introduction.tex =================================================================== --- /trunk/MagicSoft/GRB-Proposal/Introduction.tex (revision 6119) +++ /trunk/MagicSoft/GRB-Proposal/Introduction.tex (revision 6120) @@ -7,11 +7,11 @@ the objective to turn the telescope to the burst position within 10-30\,sec. in order to have a fair chance to detect a burst when the emission is still ongoing. -During the comissioning phase it could be proven that that goal was reached. +During the commissioning phase it could be proven that that goal was reached. The telescope is able to turn 180 degrees in azimuth within 20\,sec. and 80 degrees in zenith within 10\,sec.\\ Very high energy (VHE) GRB observations have the potential to constrain the current GRB models -on both the prompt and extendend phases of GRB emission~\cite{HARTMANN,MANNHEIM,SALOMON}. -Models based on both internal and external shocks predicts VHE fluence comperable to, +on both the prompt and extended phases of GRB emission~\cite{HARTMANN,MANNHEIM,SALOMON}. +Models based on both internal and external shocks predicts VHE fluence comparable to, or in certain situations stronger than, the keV-MeV radiation, with duration ranging from shorter than the keV-MeV burst to extended TeV afterglows~\cite{DERMER, PILLA, ZHANG1}. @@ -24,8 +24,8 @@ in the burst environment~\cite{MESZAROS93,CHIANG,PILLA,ZHANG2}. Long-term HE $\gamma$ emission from accelerated protons in the forward-shock has been predicted in~\cite{LI}. -This model predicts GeV inverse compton emission even one day after the burst. +This model predicts GeV inverse Compton emission even one day after the burst. Even considering pure electron-synchrotron radiation predicts measurable GeV emission for a significant fraction of GRBs~\cite{ZHANG2}.\\ -GeV emission in GRBs is particulary sensitive to the Lorentz factor and the photon density of the emitting material - +GeV emission in GRBs is particularly sensitive to the Lorentz factor and the photon density of the emitting material - and thus to the distance of the radiating shock from the source - due to the $\gamma~\gamma \rightarrow$ \textit{e$^+$~e$^-$} absorption in the emission region. Direct comparison of the prompt GRB flux at $\sim$ 10\,GeV and $\sim$ 100\,keV @@ -37,10 +37,10 @@ each indicating some excess over background but without stringent evidence. The only significant detection was performed by EGRET which detected seven GRBs emitting high energy (HE) -photons in the 100\,MeV to 18\,dGeV range~\cite{EGRET}. The data shows no evidence of a HE rollover +photons in the 100\,MeV to 18\,dGeV range~\cite{EGRET}. The data shows no evidence of a HE roll-over in the GRB spectrum~\cite{DINGUS}. Recent results indicate that the spectrum of some GRBs contains a very hard, luminous, long-duration component~\cite{GONZALES}. There have been results suggesting gamma rays beyond the GeV range from the TIBET air shower array in coincidence with BATSE bursts~\cite{AMENOMORI}, rapid follow-up observations by the -Whipple Air Cerenkov Telescope~\cite{CONNAUGHTON1}, and coincident and monitoring studies by HEGRA-AIROBICC~\cite{PADILLA}, +Whipple Air Cherenkov Telescope~\cite{CONNAUGHTON1}, and coincident and monitoring studies by HEGRA-AIROBICC~\cite{PADILLA}, Whipple~\cite{CONNAUGHTON2} and the Milagro prototype Milagrito~\cite{MILAGRO}. The GRAND array has reported some excess of observed muons during seven BATSE bursts~\cite{GRAND}. @@ -65,5 +65,5 @@ by peak energies below 50~keV and a dominant X-ray fluence. Because of similar properties a connection between XRFs and GRBs is suggested. The most popular theories say that XRFs are produced from GRBs observed ''off-axis''. -Alternativly, an increase of the baryon load within the fireball itself or low efficiency shocks can produce XRFs. +Alternatively, an increase of the baryon load within the fireball itself or low efficiency shocks can produce XRFs. If there is a connection between the XRFs and GRBs, they should originate at rather low redshifts (z $<$ 0.6).\\ Index: /trunk/MagicSoft/GRB-Proposal/Monitor.tex =================================================================== --- /trunk/MagicSoft/GRB-Proposal/Monitor.tex (revision 6119) +++ /trunk/MagicSoft/GRB-Proposal/Monitor.tex (revision 6120) @@ -18,8 +18,8 @@ three communication channels to notice the shifters about an alert situation. The program is called {\it gspot} (Gamma -Sources POinting Trigger). It is a C based daemon running 24 +Sources Pointing Trigger). It is a C based daemon running 24 hours a day on the {\it www} machine, our external server, in a {\it stand alone} mode. It does not need to be operated and is -fully automatic. It manages network diconnections +fully automatic. It manages network disconnections within the external net and/or the internal one. @@ -29,9 +29,9 @@ The connection to {\it GRB Coordinates Network} (GCN)~\cite{GCN} is performed by {\it gspot} through a TCP/IP connection to a computer at the Goddard Space Flight Center (GSFC). -This computer distributes the information it recieves from the satellite +This computer distributes the information it receives from the satellite experiments through the normal internet socket connection. The {\it gspot} on 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. \\ +and concerning the status of the connection. \\ The format of the data distributed through the GCN differ between the individual satellites @@ -74,7 +74,7 @@ An interface to {\it gspot} sends all the relevant information 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}. +of the two subsystems, are continuously exchanged between CC and {\it gspot}. In the alert case {\it gspot} starts to send to CC special alert packages, -containg information about of the GRB and the ''colour'' of the alert. +containing information about of the GRB and the ''colour'' of the alert. The exchange of the alert packages continues until the following steps occur: @@ -82,11 +82,11 @@ \item {\it gspot} receives from {\it arehucas} the confirmation that it has received the alert notice; {\it arehucas} must send the alert back in order -to perform a crosscheck of the relevant data; +to perform a cross-check 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 +At the moment {\it arehucas} informs the shift crew about the alert 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. +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. @@ -103,5 +103,5 @@ 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. +alert are displayed on a separate web page. The page is hosted on the web server in La Palma. The address is the following:\\ @@ -109,9 +109,9 @@ The web page automatically updates itself every 10 seconds. In this way -the status of the Burst Alarm System can be checked from everywere. +the status of the Burst Alarm System can be checked from everywhere. \subsection{The acoustic alert} -A further CC-indipendent acoustic alarm called {\it phava} +A further CC-independent 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 @@ -122,8 +122,8 @@ of the system and of the alert. -\subsection{Alerts recived until now} +\subsection{Alerts received until 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. +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 @@ -131,6 +131,6 @@ 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$. Pitty that the weather -conditions were very bad durnig this night. +on December 19th at 1:44 am and the GRB zenith angle was $\sim 60^\circ$. It is a pity that the weather +conditions were very bad during this night. @@ -161,6 +161,6 @@ 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 +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. In such a case we propose Index: /trunk/MagicSoft/GRB-Proposal/Requirements.tex =================================================================== --- /trunk/MagicSoft/GRB-Proposal/Requirements.tex (revision 6119) +++ /trunk/MagicSoft/GRB-Proposal/Requirements.tex (revision 6120) @@ -4,19 +4,19 @@ in order to complete the GRB Alarm System. Parallel to our system also the different subsystems of the MAGIC telescope have -to implement and test strategies for the GRB survay. +to implement and test strategies for the GRB survey. \par -We strongly push the responsibles of the drive-, camera-, amc- and central -control subsystemsto fullfill the criteria defined in~\cite{design}. We suggest -to make a one week shift wherethe experts meet together and test the GRB -stategies. In order to avoid good observation timewe suggest to make the shift -during the moon period. This shift should take place, in arrangementwith the -different subsystem responsibles, before april this year. The time limitation is -based onthe moment when SWIFT will start to work fully automaticly, sending -allerts in real time to the groundstations. +We strongly push the responsible persons of the drive-, camera-, amc- and central +control subsystems to fulfill the criteria defined in~\cite{design}. We suggest +to make a one week shift where the experts meet together and test the GRB +strategies. In order to avoid good observation time we suggest to make the shift +during the moon period. This shift should take place, in arrangement with the +different subsystem managers, before April this year. The time limitation is +based on the moment when SWIFT will start to work fully automatically, sending +alerts in real time to the ground stations. \par -We present a list of tasks that are very crucial for the GRB survay: +We present a list of tasks that are very crucial for the GRB survey: \par @@ -32,9 +32,9 @@ The use of look-up tables to correct the mirror focus during the movement to the GRB -coordinates is advantegous. In the alert situation it is a vaste of time if we would have to +coordinates is advantageous. In the alert situation it is a waste of time if we would have to close the camera lids and carry out the full laser adjustment (\~5~min) before starting the observation. The reproducibility of the focus with the use of look-up tables has to be proven. In order to use the time during the telescope movement for the focussing of the mirrors to the desired -telescope positon, the AMC needs the coordinates immediately. In this case it is necessary to change the protocol between the AMC and CC. +telescope position, the AMC needs the coordinates immediately. In this case it is necessary to change the protocol between the AMC and CC. \item {\bf Behaviour of the camera during moon:}\ @@ -42,5 +42,5 @@ It has to be checked what happens when during the pointing to a GRB position the telescope move over the moon. It is excluded by the GRB Alert System that a burst closer than 30$\deg$ to the moon will be pointed. However it is not prevented that during the movement of the telescope the moon will pass the FOV. -In this case the HV of the PMTs will be reduced automatically and will not increase fast enought for the +In this case the HV of the PMTs will be reduced automatically and will not increase fast enough for the GRB observation. @@ -49,6 +49,6 @@ \par -All this issues have to be checked during the suggested shift. The aim would be to send fake allerts to -the GRB Alarm System and proove the behaviour of all subsystems. +All this issues have to be checked during the suggested shift. The aim would be to send fake alerts to +the GRB Alarm System and proof the behaviour of all subsystems. Index: /trunk/MagicSoft/GRB-Proposal/Strategies.tex =================================================================== --- /trunk/MagicSoft/GRB-Proposal/Strategies.tex (revision 6119) +++ /trunk/MagicSoft/GRB-Proposal/Strategies.tex (revision 6120) @@ -7,17 +7,17 @@ the results on the studies on the MAGIC duty-cycle made by Nicola Galante \cite{GALANTE} and Satoko Mizobuchi \cite{SATOKO}. -Considering a MAGIC duty-cycle of about 10\% and a tollerance of 5 hours +Considering a MAGIC duty-cycle of about 10\% and a tolerance of 5 hours to point the GRB, we should be able to point about 1-2 GRB/month. Such duty-cycle studies, made before MAGIC started its observations, are reliable as long as weather constraints that were considered -(~maximum wind's speed of 10 m/s, maximum humidity of 80\% and +(~maximum wind speed of 10 m/s, maximum humidity of 80\% and darkness at astronomical horizon~) revealed similar to the real ones that are affecting MAGIC's observation time. In this duty-cycle study -also full moon night are considered usefull (~just requiring +also full moon night are considered useful (~just requiring a minimum angular distance of the GRB from the moon of 30$^\circ$~), while 3-4 nights per month are actually skipped because of full moon, but this reduction of the real duty-cycle is about compensated -by the tollerance of 5 hours for considering the alert -(~5 hours more before the beginning of the night usefull +by the tolerance of 5 hours for considering the alert +(~5 hours more before the beginning of the night useful for getting GRB's alerts are equivalent to an increase of the duty-cycle of about 6 days per month~). Actually @@ -29,6 +29,6 @@ technical tasks, MAGIC should employ 1-2 nights per month in GRB observations. This means that we must do as much -as possible to observe them EVERY time that a usefull -alert occours. +as possible to observe them EVERY time that a useful +alert occurs. \subsection{What to do with the AMC ? } @@ -43,8 +43,8 @@ a fast moon-flash shouldn't damage the PMTs, but the behaviour of the camera and of the Camera Control {\it guagua} must -be tested. Otherway, if such test concludes that it is not safe +be tested. On the other hand,, if such test concludes that it is not safe at all to get even a short flash from the moon, the possibility -to implement a new feature into the Steering System wich -follow a different path while selwing must be considered. +to implement a new feature into the Steering System which +follow a different path while slewing must be considered. \par There was a shift observing the Crab-Nebula with half-moon at La Palma in December 2004. @@ -103,5 +103,5 @@ 500\,GeV at $\theta = 65^\circ$. Inserting these results into the GRH (figure~\ref{fig:grh}), one gets a maximal observable GRB distance of $z = 0.1$ and $z = 0.2$, respectively. We think that the probability for -GRBs to occur at these distances is suffiently small in order to neglect the very difficult observations +GRBs to occur at these distances is sufficiently small in order to neglect the very difficult observations beyond these limits. Index: /trunk/MagicSoft/GRB-Proposal/Timing.tex =================================================================== --- /trunk/MagicSoft/GRB-Proposal/Timing.tex (revision 6119) +++ /trunk/MagicSoft/GRB-Proposal/Timing.tex (revision 6120) @@ -14,5 +14,5 @@ \par In~\cite{DERMER}, two peaks in the GeV light curve are calculated. An early maximum coincident -with the MeV eak is the high-eneryg extension of the synchrotron component, some seconds +with the MeV peak is the high-energy extension of the synchrotron component, some seconds after the burst onset. The second maximum peaking at $\approx$ 1.5 hours is due primarily to SSC radiation with significant emission of up to $10^5$ sec. ($\approx 25$ hours) after the burst.