Author: Natalia Zotov

PT:  Peak-Trough, otherwise known as peak-to-peak, values.


    PTmon is a glitch monitor, designed to find glitches onany of LIGO's auxiliary channels.  It's primary purpose is to help establish vetoes for inspiral candidates or unmodeled bursts appearing in the 'gravity wave channel', AS_Q.

Data preparation

     The raw time series is first downsampled to some frequency above the Nyquist frequency of the desired pass band.  (This is done in PTmon using the DMT class DecimateBy2.)  Besides speeding the filtering, decimation allows for steeper shoulders on the filters, with more cleanly defined pass bands.  The decimated series is filtered using FIR filters, chosen partly for speed.  Each type of channel needs to be studied, and typical resonances or glitching frequencies found to help determine what frequency bands should be monitored.  There are a number of passbands of interest for the 16 kHz channels.

    The GPS time of the first point in the time series in each frame is recorded, then times are stripped, and replaced by position indices.  The peak-trough (or PT) series is formed next, using the signs of the slopes between adjacent points to locate local maxima and minima.  When the slope changes from positive to negative, a local maximum has been found, and when it changes from negative to positive, a local minimum has been found. In practice, one just checks whether the difference between adjacent values is positive or negative (or zero).
Standard deviation and thresholds
    A running estimate of the standard deviation of the background is desirable, because this does not have long term stability, and also may change significantly after a major glitch.   The basis of its algorithm is that on average, 95% of data values fall with approximately two standard deviations of the mean.
    A set of thresholds for glitch-finding is established using the estimate of sigma.  These are usually around 3 and 4 sigma, with a 2 sigma threshold being used to trace back to the onset or start time.  Currently it is the start time that is reported under 'start_time' in the trigger tables, although the peak time would correspond more closely to the coalescence time used by the Inspiral group.
Defining a glitch
    A glitch arising from a physical oscillation can be expected to pass through the mean and beyond 3 sigma at least once.  The coefficients are adjustable, but for the purposes of explaining the algorithm, it will be convenient to use 2, 3, and 4.  There are two basic cases to consider.
(1) A large spike will have a PT value that crosses the 4 sigma threshold, and at least two others that cross the 3 sigma threshold, within a specified time window.

                   Time series                     PT series
    Dotted lines represent 3- and 4-sigma thresholds

(2) Alternatively, a glitch must cross the 3 sigma threshold at least, say, four times within the same time window.  The choice of window will depend on the expected frequency of the glitch.

                  Time series                    PT series
                 Dotted line represents 3 sigma threshold


    After it has been determined that a glitch has occurred, the setting of a trigger is delayed until a specified number of PT values has been accumulated.  (The number depends on the downsampled channel rate and likely frequency.)  The values are used to estimate the glitch frequency, which will only be aproximate, and to determine the peak amplitude, which is used to calculate the signal-to-noise ratio.

    Glitches with snr < 5 are currently not reported.   This is partly to keep the number of triggers from becoming unreasonable during online running, but also because it was found when running the monitor on simulated data, that a 16KHz white noise background generated triggers up to around 5 sigma just from random fluctuations, whereas all triggers above 6 sigma corresponded to injections.

Output reported

    The following information is contained in PTmon triggers:  start_time, start_time_ns, size (which contains snr), and frequency.  A summary report is posted to the monitors' status page  on 'blue' at Hanford.  This lists the channels monitored, the total number of glitches, and the glitch rate for each channel.  The glitch rate is the only trend being written currently.

Setting parameters

    Currently all parameters are set internally, and the filters are  set according to channel type.   The author plans to move the selection of filters to the configuration file as soon as possible, to accomodate investigations on the fast channels using a variety of frequency bands.