Burst DSO and DMT Investigations during LIGO's E7
January 12, 2002

Overview

I looked at roughly two hours of (continuous) locked acquisition at LLO and the E7 run currently in progress. The lock started at GPS=694242050 corresponding to Jan 04, 2002 23:00:37 CST (Jan 05, 2002 05:00:37 UTC) and ended at GPS=694249130 corresponding to Jan 05, 2002 00:58:37 CST (Jan 05, 2002 06:58:37 UTC). The total lock duration was 7140 seconds. I looked at a number of things that the bursts DSO and DMT monitors generated during this time interval, mostly to get a feeling of what is going. You may find a number of investigative plots herein.

Procedure

The steps involved in producing the diagnostic plots can be summarized as follows:

• I used GUILD to retrieve corresponding DB entires for POWER (DSO), TFCLUSTERS (DSO), GLITCH (DMT) and GLITCHMON (DMT). I will refer to each one of them generally as 'trigger'.

• For each 'trigger' I built 'events' by grouping multiple entries in the DB corresponding to the same START TIME. For each trigger and event I assigned 'multiplicities' equal to the number of DB entries with the same start time. At present, in generating multiplicities for glitch and glitchmon triggers individual channels are NOT discriminated. For events with multiplicity greater than one the quantities of the 'loudest' among them is kept and ploted. For example, in the following two DB entries for the POWER DSO:

  SEARCH START_TIME  START_TIME_NS  DURATION       CENTRAL_FREQ   BANDWIDTH      AMPLITUDE      SNR           
  power  694242086   123046874      1.0009766e+00  3.0299707e+02  6.9931707e+00  1.4651468e+02  1.4651468e+02 
  power  694242086   873779295      3.7536621e-01  3.0000000e+02  7.9921951e+00  1.0984850e+02  1.0984850e+02 
  

  a single event was created of multiplicity two and the reconstructed quantities of the entry of the highest S/N were assigned to it.

• Initially the following diagnostics were meant to be performed:

  • establish raw 'event' rates for the 'triggers' (notice that DB entry rates are not 'event' rates per se),

  • produce general histograms of calculated quantities by each of the 'triggers' (e.g. S/N, central frequency, duration, multiplicities),

  • study time-variation of these quantities, including trigger rates- watch for patterns and clustering, qualitatively establish uniformity in time. Especially for what concerns the triggers' 'arrival' times, use Poisson test (fit Delta(arrival time)).

  • study time coincidence of 'loud' events among DSO and DMT triggers

• There are four groups of graphs corresponding to POWER, TFCLUSTERS, GLITCH and GLITCHMON which you might want to browse through with your morning coffee. There are fewer summary plots that show the trigger rate vs. time as well as their significance vs time. I am going to summarize my observations in the following section.

Plots

• Trigger summary plot in ps , pdf or in gif p.1 ,
• Coincidence summary plots in ps , pdf or in gif p.1 , p.2
• POWER plots in ps , pdf or in gifs p.1 , p.2 , p.3 , p.4 , p.5 , p.6
• TFCLUSTERS plots in ps , pdf or in gifs p.1 , p.2 , p.3 , p.4 , p.5 , p.6
• GLITCH plots in ps , pdf or in gifs p.1 , p.2 , p.3 , p.4 , p.5
• GLITCHMON plots in ps , pdf or in gifs p.1 , p.2 , p.3 , p.4 , p.5

Preliminary Observations (POWER)

• The first page shows counts of POWER events (as grouped together based on START TIME) as a fuction of time. All time plots have t=0 at the beginning of the locked segment and are in seconds. I allowed automatic binning (by PAW), thus it ended up with 70secs bin. It is trivial to force the binning to any desired value (e.g., 60s for day plot, hrs for week plots, days for monthly plots?). Variations in this plot may flag changes (as a funtion of time) of detector noise or problem of the DSO is getting through LDAS. Combining this plot with similar ones for the other triggers it may help resolving which of the two may be occuring.
  

  In this case, POWER was generating fewer triggers at the beginning of the 'RUN' (=locked segment in consideration), contrary to the TFCLUSTERS and with noise rates rather flat. I thus suspect, LDAS problem (?).
  

  The average rate of the POWER trigger for that segment was 0.4Hz.

• The second page starts with the previous plot in smaller scale and then shows histograms of the following quantities of the POWER events:

  • Event multipliticy- it probably shows sensitivity of the trigger DSO to the pulse shape and frequency content
  • Duration
  • Central frequency and bandwidth
  • S/N which for the Burst DSO is the total power in the band/pixel not normalized though to the total noise power, so it should trace the noise of the instrument.

• The third page treats the arrival time distribution of the POWER events. For every POWER event the time stamp of the previous one is subtracted and an entry is made in this histogram (for all but the first event). The top plot imposes no cut while the bottom plot applies a cut at 20s. Assuming a Poisson process, an exponential is expected and the exponential fit is shown. Outliers in this plot are interesting as they may flag intermitent problems of the DSO's (or DMT's) execution. The x^2/ndf is not especially good- needs to be understood (could be related to problem described in page one).

• The fourth page has a collection of scatter plots of reconstructed quantities versus time (t=0 is the start of lock). There is only entry (dot) PER EVENT. Notice that the y-axis is logarithmic. The main purpose of this plot is to investigate if the time-summed plots of page two display any time structure, e.g., if the high multiplicity events all occured and the start or end of the lock.
  

  This can be useful in establishing whether the very beginning or the very end of the lock segment should be thrown away for analysis etc.
  

  No obvious time structure is seen in these plots. The SNR vs time graph identified immediately the instances of possible bursts. In the case of POWER, most of the loudests events came in close to the end of lock, probably picked up the source that caused the loss of lock (which was not picked up by the GLITCH/ GLITCHMON ??)

• The fifth page is identical to the fourth with the exception of the vertical scale that is linear.

• The sixth page throws away the outliers by selecting events within ~4sigma of the SNR and studies the dependance of calculated quantities on the frequency.

Preliminary Observations (cont'd)

• TFCLUSTERS started triggering rather high (?)
• TFCLUSTERS multiplicity is not monotonic function (notice the dip for multiplicity=2 events)- suggests particular pulse shape that is sensitive to?
• TFCLUSTERS showed 4-5 bursting episodes during the run, one of which in coincidence with POWER at the end of lock.
• TFCLUSTERS traces the detector noise in the frequency bands. Look at the SNR vs. frequency grouping of events.
• GLITCH reports a 'size' that is not normalized to the sigma. The spread in the figure corresponds to the different channels that it processes. The 'significance' is probably more legitimate measure of 'loudness' of glitch??
• GLITCH reports funny deltaT distribution of arrival times. It displays a second peak at ~70s way beyond Poisson expectations. It may signal something instrumental or the way GLITCH is executed. Look at the sample pair where 'glitch' was 'quiet' for more than 70 seconds.

  NAME   SUBTYPE           START_TIME  START_TIME_NS  DURATION       SIZE           SIGNIFICANCE  
  Glitch L1:PSL-FSS_FAST_F 694243123   793945313      9.9792499e-03  1.9498300e+03  5.4187498e+00 
  Glitch L0:PEM-HAM2_ACCX  694243196   796875000      1.0742200e-02  1.9852800e+03  6.3819599e+00 
  

• Summary plots of trigger rates can monitor the behaviour of the various DSO and DMT systems as a function of time. Once again, the binning here is 70s but it can trivially adjusted as needed.
• Coincidence plots of loud events in each of the systems can be seen in linear and logarithmic scales. High S/N (or significance) events are identified with triangles. Time is one the x-axis in seconds. There is one clear coincidence between POWER/TFCLUSTERS at the end of the run.

Action Items

• verify the above observations and make sure there are no software errors (will take me about a day to do so)
• code channel option in studying GLITCH and GLITCHMON triggers
• build robust statistical tools to flag rate changes, coincidences of rate excursions in order to automate things
• go over more data. The bottleneck (for me) is interacting with GUILD- preparing scripts that can do it in a more automated way will help. HOW CAN YOU ACCESS MORE THAN 10,000 DB ENTRIES AT A TIME USING GUILD? Occasionally, formatting to ascii file from GUILD resulted in corrupted lines- haven't understood why
• manually investigate outliers in S/N- this is what I'm currently working on
• is there any merit and information we want to keep from these plots? Should it be fully automated, mix of manual investigations?
• as always, comments, questions or suggestions are welcomed