next up previous contents
Next: Tests Before Production Up: Step 3: Assesment and Previous: Database monitoring

Detailed diagnosis

While the time-line based monitoring plots described in the previous section are useful for identifying problem running periods, they have only a limited capability to determine the specific cause of the problems observed.

Timing:
The major source of problems seen in particle id, is in the relative timing of the various detector elements. Specifically, for electron beam data the primary souce of particle id problems is with miscalibrated time-of-flight paddles. In this case one will often observe an increase in the number of Kaons or unknown particles in a particular sector. For photon-beam data the situation is more complicated since the start time of the event is derived from information from the tagger, start counter and time-of-flight. A common problem seen in photon data is a misalignment in the timing between the tagger and time-of-flight. The alignment of the tagger and the time-of-flight is controlled by a single parameter contained in the map file TAG_CALIB.map in the tag2tof subsystem. A misalignment of this number is the cause of the drop in proton yield near run 11910 seen in Fig. 4. To check that the tagger and time-of-flight are aligned it is useful to look at the photon_mon histograms. Specifically, to check the tag2tof number we looked at photon_mon histogram number 109 which plots the difference between the start time determined by the tagger and the start time determined by the time-of-flight for pions. As can be seen in the top histogram in Fig. 7 the tag2tof number was misaligned by several nanoseconds for pass 0 processing of run 11910, before processing pass 1 this number was corrected.
 
Figure 7: Top Figure: Tagger vertex time - pion vertex time, g1a pass 0, before tag2tof alignment, Bottom Figure: Tagger vertex time - pion vertex time, g1a pass 1, after tag2tof alignment  
\begin{figure}
\vspace{150mm}
\centering{\special{psfile=pion_vertex_time.ps hscale=80 vscale=80 hoffset=-40 voffset=0}}\end{figure}

Hardware Failure:
Many times when a problem appears in the time-line based monitoring plots the possible sources of the problem can be narrowed down by looking at the pid_mon histogram associated with that run. For example, Fig. 8 shows the normalized number of gamma particles in each sector for the 4.46 GeV period of the E1B running period. The sudden jump in the total number of gammas at run 17746 is caused by the change in the main torus current from 3375 A to 2250 A. However, the increase in the number of gammas in sector 5 for runs 17591 and 17599 can not be written off so easily. The pid_mon histogram file for run 17599 contains a plot of the angular distribution of the gamma particles which can be seen in the top plot of Fig 9. This plot shows a strange pattern in sector five. This same pattern can not be seen in the electron distribution in the bottom plot of Fig. 9. Since electron reconstruction uses the full CLAS detector and gamma reconstruction uses only the calorimeter reconstruction this seems to indicate the sector 5 calorimeter as the source of the problem. At this point the EC expert was contacted and the source of the problem was identified as a set of noisy ADC boards in the calorimter.


 
Figure 8: Number of gammas per sector normalized to the Faraday Cup for ``pass 0'' of the E1B running period using prod-1-7. 
\begin{figure}
\vspace{75mm}
\centering{\special{psfile=gamma_4.46_prod17.ps hscale=60 vscale=55 hoffset=-30 voffset=325
angle=270}}\end{figure}


 
Figure 9: The top plot is the angular distribution of reconstructed gamma particles in CLAS. The bottom plot shows the angular distribution of reconstructed electrons in CLAS. Both of these plots were taken from the pid_mon histogram generated for run 17599 during step 3 of E1B ``cooking''. 
\begin{figure}
\vspace{175mm}
\centering{\special{psfile=theta_vs_phi_17599.ps hscale=90 vscale=100 hoffset=-40 voffset=-80
angle=0}}\end{figure}


next up previous contents
Next: Tests Before Production Up: Step 3: Assesment and Previous: Database monitoring
Elton Smith
10/8/1999