## Follow-Ups on S2 BlockNormal Review

This page details the follow-ups we have performed on the outstanding issues in the S2
BlockNormal review (PDF final draft), as well as their status in our S5 work

## Problem in Whitening Filters

We first developed a metric (the Rayleigh statistic) and tested the performance of each step of our data-conditioning. The expectation is that each step (Kalman line filter, line regression filters, and whitening filters) should each improve the whiteness of the data. We studied the performance on all playground in S2 (web page S2 Data-Conditioning Performance on Playgrounds) and S3 (web page S3 Data Conditioning Performance). The playgrounds are relevant as they are used to create the filters. If the data-conditioning fails on those, it will not be better on the whole data. These studied identified which steps on which frequency bands were failing. The worst problem was in the Band 4 filtering in S3. We investigated in detail (web page Band 4 Filtering Study and Fixes) what was causing the problem. The root cause was that the 60Hz harmonic regression filters were of too high an order (90-150). The calibration line regression filter (which worked) were only of order 4. For S5, we developed a technique to track the Rayleigh statistic performance on regression filters as a function of order (web page S5 Regress Filter Selection). The filter order would only be increased until the Rayleigh statistic reached the plateau. We tried regressing the 60Hz harmonics, but we never found filters of low order that worked well. So we only regress calibration lines in S5.## Regression Channel Glitch Testing

We did not develop a test for this. However, in S5 we are only using injection channels to remove calibration lines (normal and photon calibrator. We are not doing any regression filtering with the PEM channels. The low-order regression filters ensure that any glitches in these high-coherence channels will be filtered matching their strength in DARM_ERR. In fact, the regression filters might remove some of these glitches that couple into DARM_ERR.## History Effects on Event Detection

As mentioned in the final S2 report, we analyzed the performance of BlockNormal on two MDC sets (web page Signal Pile-Up Studies). Both sets had the same average injection spacing (120s), but one set (BH3) used Poisson sampling, so the spacing ranged down to 10s, while the other set (BH4) forced spacing to be centered on 120s. An early version of WaveBurst had performed poorly on BH3 (and was fixed to resolve that issue). The BlockNormal performance was essentially identical on both MDC sets. We did some detailed tests (same web page) that showed there might be an issue of injections only 15s apart. However, no metric was determined to push this further. We note that all current Burst Group MDC sets use forced spacing.## Change-Point Uniformity

As noted in the final S2 report, we did some initial studies on S2 data (web page Change-Point Uniformity Studies). What these showed is that the uniformity issue disappeared once we applied non-zero thresholds on the blocks to define events. During S5, we examined this issue in more detail when we tuned the BlockNormal thresholds of &rho_{2}on change-points and P_{E}on blocks between change-points. As shown in our background rate tuning (web page S5 Background Tuning - Epoch 2), we found that the smooth statistical behavior broke down if we tried too high a &rho_{2}threshold. We explored this further in our BlockNormal methods paper (PDF BlockNormal CQG Paper). The root cause was that a too-high of a &rho_{2}threshold resulted in so low a change-point rate of the iteration interval that the assumption of Gaussian statistics was invalid. As long as one keeps the &rho_{2}threshold low enough, the blocks above the event threshold have the expected Poisson spacing distribution. There is a different, but related issue with event pile-up at the beginning and end of each epoch. This is mostly due to some ringing in the filters as well as an excess of change-points in BlockNormal. We studied this in S2 (web page Fiducial Cut Study). This is only a problem within 0.25 s of an edge. We solve this by extending the time epoch edges by 1 second in each direction, then removing all events in the last second during clustering.## Frequency Band Non-Overlap

We haven't done any studies yet regarding this (as it would require special MDCs). However we typically get good performance on Sine-Gaussians that are close to band edges.
$Id: S2_Review_Followups.html,v 1.2 2007/11/06 16:47:32 kathorne Exp $