S3 Data Quality Review

Data Quality Activities

I know of the following people working on evaluating the S3 data quality

Data Quality monitor (DataQual) was run throughout the S3 science run.
Once again Keith is maintaining an annotated list of science mode segments.
Science mode segment lists are maintained automatically for H1, H 2 & L1.
Statistics of several potentially useful quantities are kept on a segment-by-segment basis for H1, H2 & L1.
DAQ readout errors were noted. A summary of additional studies is here.
Data overflows monitored by the DAQ system are summarized.
Some data did not have calibration lines injected.
Front-end synchronization errors also occurred.

Note: As of now all results should be considered preliminary.

The following table summarizes the live-time loss of each of the data problems. All times are in minutes and percentages are the fraction of single-ifo science modes times.

Symptom	H1	H2	L1
Data Overflows	7 (0.01%)	86 (0.14%)	253 (1.39%)
Missing calibration lines	200 (0.29%)	407 (0.64%)	189 (1.04%)
Front-end synchronization errors	0 (0.00%)	0 (0.00%)	33 (0.18%)
Total science mode data	69,235 (100.%)	63,199 (100.%)	18,185 (100.%)

Still to be done:

Try to find out whether the DAQ errors affected the GW Channels. Is the DARM_CTRLchannel better?
Look for data zeroed by incorrect data-valid flags.

Data Quality Monitor (DataQual)

A data quality monitor based on the PSLmon program was running during the entire S3 run. This monitor made trends of band limited RMS and glitch rates on several channels. The DataQual configuration files can be viewed by following these links for the LLO configuration and for the LHO configuration. The current status of the monitors at LHO and LLO are also available online.

S3 Summary trends

Trends of AS_Q band RMS and Glitch rates are available as pdf files. Warning: The narrow band rms files are enormous (750 pages, ~150MB).

As_Q band limited RMS (narrow bands - LARGE Files)	H1	H2	L1
As_Q band limited RMS (wide bands)	H1	H2	L1
Glitch Rates	H1	H2	L1

These plots currently cover the entire S3 run) (October 31, 2003 16:00 UTC through January 9, 2004 ~16:00 UTC. The plotted RMS points are average variance (sigma^2) within the specified band for each 1-minute period while the interferometer was locked and in common mode. The glitch plots show the glitch rates in Hz, averaged over 1 minute. Each plot corresonds to 1 day and the x axis is the GPS hour (note that this differs from UTC by the net number of leap-seconds, 13 seconds during S3?). The bands are indicated in the title of each plot. The error bars are calculated from the distribution of the fifteen 4-second measurements made during each GPS minute. A histogram of all points is plotted at the beginning of the trends for each band. Thick red bars near the bottom of each trend plot indicate the science mode segments. On some plots I have also drawn a green line at an arbitrary value to "guide the eye".

Line removal from trends

It was noted during the S3 run that the figure-of-merit bands were unexpectedly stable. This is due in a large part to the fact that most bands were dominated by line features (e.g. power lines, calibration lines, violin lines and TM internal modes). Since S3, I have modified the PSLmon monitor and the DataQual configuration to remove apparent line features from the RMS calculation so that the figures will give a better view of the data. The following table gives the excluded frequencies and the resulting average RMS differences.

FOM Band	Excluded bands	Whole Band	WIthout Lines
H1 10-100Hz	41-41.75, 59.75-60.5	1.970e+03	1.970e+03
H1 100-200Hz	119.75-120.5, 151-151.75, 179.75-180.5	1.218e-04	4.912e-05
H1 200-400Hz	299.75-300.5, 342-349	4.415e-04	1.221e-04
H1 400-1000Hz	890.25-891, 972.75-974	2.998e-04	1.486e-04
H1 1000-7000Hz	1441.75-1442.5, 2883.75-2884.5, 4325.75-4326.5, 5677.75-5678.5, 4728.5-4729.25	1.897e-03	1.861e-03
H2 10-100Hz	41.5-42.25, 60-60.25	4.225e+02	4.092e+02
H2 100-200Hz	119.75-120.5, 151.5-152.25, 179.75-180.5	7.329e-04	1.176e-04
H2 200-400Hz	239.75-240.5, 299.75-300.5, 343.5-344.75, 348.75-350, 359.75-360.5	3.253e-04	5.484e-05
H2 400-1000Hz	973.5-974.25	2.903e-05	2.594e-05
H2 1000-7000Hz	1488.5-1489.75, 3732-3735, 5478.5-5480, 6497-6497.75, 6991-6996	9.385e-05	8.296e-05

The LHO trends, plotted for a sample time interval with and without the line exclusions, can be seen here. (Note that the trend plots with an "X" at the end of the name exclude the line frequencies specified in the table above).

Scan of DAQ overflow channels

I have scanned the minute trends for non-zero overflow counts as measured by the DAQ overflow channels for the LSC subsystem. At present, errors are scanned and tabulated through ~0:00 UTC 2004-01-06. All channels named Xn:LSC-*_OVERFLOW were scanned except Xn:LSC-MASTER_OVERFLOW and Xn:LSC-RESET_OVERFLOW. The RESET_OVERFLOW channels are supposed to have a single count each time the MASTER_OVERFLOW counter is reset (nominally once per second). In fact what is seen is that RESET_OVERFLOW is always set while MASTER_OVERFLOW is reset at irregular intervals. Since the other overflow channels should have a complete list of the overflows, ignoring these channels should not cause any errors to be lost.

Times with overflows are summarized in the following table and the raw results are in H1, H2 and L1. Note that minutes that are not completely contained in a lock segment are ignored.

Start (GPS)	Duration (s)	IFO-Segment	Comments
753720480	60	H1-149	Many channels
755401200	120	H1-301	H1:LSC-AS3_[IQ]
755401560	60	H1-301	H1:LSC-AS3_[IQ]
757297440	60	H1-471	Many channels
757374600	60	H1-477	H1:LSC-AS3_I
757379280	60	H1-478	H1:LSC-AS3_[IQ]

Start (GPS)	Duration (s)	IFO-Segment	Comments
753268320	60	H2-155	H2:LSC_AS3
753335160	60	H2-158	H2:LSC_AS3I_CORR
753697380	60	H2-215	H2:LSC_AS3I_CORR
753721740	60	H2-222	H2:LSC_AS3_Q
753939540	60	H2-239	H2:LSC_ADC1_4
754057920	60	H2-244	H2:LSC_AS3_Q
754062420	60	H2-244	H2:LSC_AS3_Q
754149060	60	H2-254	H2:LSC_AS3_Q
754150260	60	H2-254	H2:LSC_AS3_Q
754150740	60	H2-254	H2:LSC_AS[23]_I
754151400	60	H2-254	H2:LSC_AS3_Q
754153440	60	H2-254	H2:LSC_AS3_Q
754168140	120	H2-256	H2:LSC_AS3_Q
754168620	60	H2-256	H2:LSC_AS3_Q
754169040	60	H2-256	H2:LSC_AS3_Q
754171200	60	H2-256	H2:LSC_AS3_Q
754173180	60	H2-256	H2:LSC_AS3_Q
754173780	60	H2-256	H2:LSC_AS3_Q
754175460	60	H2-256	H2:LSC_AS3_Q
754178880	60	H2-256	H2:LSC_AS3_Q
754181640	60	H2-256	H2:LSC_AS3_Q
754183440	60	H2-256	H2:LSC_AS3_[IQ]
754184280	60	H2-256	H2:LSC_AS3_Q
754185600	60	H2-256	H2:LSC_AS3_Q
754186320	60	H2-256	H2:LSC_AS3_Q
754194300	60	H2-257	H2:LSC_AS3_[IQ]
754194720	60	H2-257	H2:LSC_AS3_Q
754197660	60	H2-257	H2:LSC_AS3_Q
754198560	60	H2-257	H2:LSC_AS3_Q
754201380	60	H2-257	H2:LSC_AS3_Q
754278720	60	H2-260	H2:LSC_AS3_[IQ]
754334220	60	H2-262	H2:LSC_AS3_Q
754349040	60	H2-264	H2:LSC_AS3_Q
754595640	120	H2-275	H2:LSC_AS3_[IQ]
754599000	60	H2-275	H2:LSC_AS3_Q
754637640	60	H2-277	H2:LSC_AS3_Q
754637820	60	H2-277	H2:LSC_AS3_Q
754662660	60	H2-278	H2:LSC_AS3_Q
754663020	60	H2-278	H2:LSC_AS3_Q
754670580	60	H2-279	H2:LSC_AS3_Q
754684560	60	H2-280	H2:LSC_AS3_Q
754685280	60	H2-280	H2:LSC_AS3_Q
754728960	60	H2-284	H2:LSC_AS3_Q
754740240	60	H2-284	H2:LSC_AS3_Q
754742580	60	H2-284	H2:LSC_AS3_Q
755055840	60	H2-314	H2:LSC_AS3_[IQ]
755165820	60	H2-323	H2:LSC_AS3_Q
755246700	60	H2-333	H2:LSC_AS3_[IQ]
755284020	60	H2-337	H2:LSC_AS3_Q
755357880	60	H2-342	H2:LSC_AS3_[IQ]
755533020	60	H2-366	H2:LSC_AS3_[IQ]
755574240	60	H2-378	H2:LSC_AS3_Q
755590320	60	H2-380	H2:LSC_AS3_[IQ]
755607720	120	H2-382	H2:LSC_AS3_[IQ]
755620080	60	H2-385	H2:LSC_AS3_Q
755622780	60	H2-386	H2:LSC_AS3_Q
755648520	60	H2-389	H2:LSC_AS3_Q
755708160	60	H2-401	H2:LSC_AS3_[IQ]
755745780	60	H2-416	H2:LSC_AS3_Q
756028500	60	H2-476	H2:LSC_AS3_[IQ]
756175800	60	H2-493	H2:LSC_AS3_[IQ]
756237000	60	H2-505	H2:LSC_AS3_[IQ]
756239880	60	H2-507	H2:LSC_AS3_Q
756242760	60	H2-507	H2:LSC_AS3_[IQ]
756256080	60	H2-513	H2:LSC_AS3_[IQ]
756256500	60	H2-513	H2:LSC_AS3_[IQ]
756273480	60	H2-518	H2:LSC_AS3_Q
756284880	60	H2-518	H2:LSC_AS3_Q
756289980	60	H2-520	H2:LSC_AS3_Q
756290280	60	H2-520	H2:LSC_AS3_[IQ]
756291240	60	H2-520	H2:LSC_AS3_[IQ]
756338580	60	H2-535	H2:LSC_AS3_[IQ]
756395820	60	H2-541	H2:LSC_AS3_Q
756407640	60	H2-545	H2:LSC_AS3_Q
756411060	60	H2-546	H2:LSC_AS3_[IQ]
756417540	60	H2-547	H2:LSC_AS3_[IQ]
756420480	60	H2-548	H2:LSC_AS3_Q
756439560	60	H2-553	H2:LSC_AS3_Q
756712860	60	H2-583	H2:LSC_AS3_[IQ]
756835080	60	H2-604	H2:LSC_AS3_[IQ]
757065300	60	H2-633	H2:LSC_AS3_Q
757069440	60	H2-633	H2:LSC_AS3_[IQ]
757483080	60	H2-683	H2:LSC_AS3_I

Start (GPS)	Duration (s)	IFO-Segment	Comments
751719600	540	L1-1	L1:LSC-AS3
751724940	420	L1-2	L1:LSC-AS3
752050320	1620	L1-15	L1:LSC-AS2_[IQ]
752053140	360	L1-17	L1:LSC-AS2_[IQ]
752055900	1380	L1-18	L1:LSC-AS2_[IQ]
752058060	2340	L1-19	L1:LSC-AS2_[IQ]
752063760	7320	L1-20	L1:LSC-AS2_[IQ]
752571540	60	L1-63	L1:LSC-AS2_[IQ]
752889540	60	L1-98	L1:LSC-REFL1_I
753020520	60	L1-114	L1:LSC-REFL1_I
753581220	60	L1-147	L1:LSC-REFL1_I
753821820	60	L1-183	L1:LSC-AS2_[IQ]
755795040	240	L1-315	L1:LSC-AS[23]_[IQ]
755808720	60	L1-319	L1:LSC-AS[23]_[IQ]
755819100	60	L1-323	L1:LSC-AS2_[IQ]
755822700	60	L1-324	L1:LSC-AS2_I
755823600	120	L1-324	L1:LSC-AS2_I
755986020	60	L1-362	L1:LSC-AS[23]_[IQ]
756154860	60	L1-398	L1:LSC-AS2_I
756566760	60	L1-442	L1:LSC-AS2_Q
756567060	60	L1-442	L1:LSC-AS2_Q
756710820	60	L1-464	L1:LSC-AS2_Q
756882000	60	L1-473	L1:LSC-AS2

DAQ errors

Numerous DAQ errors were noted throughout the S3 science run. These seemed to manifest themselves as improper data in the low order byte of some 32-bit words. Symptoms include:

Glitching in channels: These are most commonly notes in the H1 suspension sensor (OSEM) channels, although there is no reason to believe that this is the only place that the data were clobbered.
Non-integer quantities: Some channels (notably Epics state values) contain integer values represented as floating point numbers. These have been seen to have non-integer values in the frame data.
Invalid dataValid: The dataValid flags in the FrAdc frame structures are copied from the LIGO reflective memory status words which should have one of two values: 0 or 0xbad. These have been seen to have other values.

Ben Johnson has developed some LDAS Tools to search for these symptoms. He has produced a table of channels with broken integers and bad dataValids at LHO and LLO in the GPS range 755400000-755499999.

He has also followed a suggestion by Daniel Sigg and histogrammed the contents of the last byte of several channels for the same S3 data and for som S2 data. The channels that are supposed to contain 16-bit integer values (and should therefore have a zero low order byte), e.g. H2:SUS-MMT2_URYAW_SW1R show unabiguous evidence of errors
in bins {8, 12, 14, 15, 30, 31, 183, 247, 255}. For other channels, e.g. H1:LSC-AS_Q or L1:LSC-REFL_Q, it is much less obvious what the "correct" distribution of LSB values should be, although it is clear that the distribution should be sort of flat. There are, however, several effects that would tend to make the distribution deviate from purely poisson. For example, if the number were calculated from the difference of two larger numbers, the limited precision result would be left justified (i.e. padded on the right side by zeros) when packed into the 24-bit mantissa. This would tend to increase the frequency of data words with LSB that are a multiple of 2, 4, 8, 16, 32, etc. This may be what is seen in the L1:LSC-REFL_Q histogram, although there are several bins with large excess that are not multiples of a power of two and it is surprising that one channel would have so noticeable an effect while another (e.g. H1:LSC-AS_Q) is much more uniform.

I have also looked at the H1:LSC-AS_Q histogram in terms of a (hopelessly naive) Poisson statistical model. The number of counts in all histogram bins is N_tot= 1,626,865,664 (not quite 16k × 100000, but close). If the population were even in all bins, each would have N_bin = N_tot ÷ 256 = 6,354,944 entries. The poisson error on each bin is

E_bin = sqrt(N_bin) = 2,520.9

I have calculated the normalized frequency (N_i / N_bin), and deviation ( [N_bin - N_i ] / E_bin ) for each bin. They are tabulated here. The most obvious result is that the data don't fit a flat distribution (chi-square/df ~ 700). Some bins with errors in the integer channels have large positive deviations (e.g. 8, 255, 247), although others don't (e.g. 12, 14, 31, 183). Other bins that show no excess in the integer error list show large overflows in the AS_Q list (e.g. 3, 13, 100, 125). This comparison is a little difficult since the erroneous bit pattern may be ORed itno the existing data. In the case of the integer errors, the real data are all zeros so the erroneous data are show up uniquely. With non-zero data the error bits move cause it to occupy an entirely different bin.

Suspension Sensor Glitches

During the S3 running, Daniel Sigg noticed that there are numerous large glitches in the large optic suspension sensor (OSEM) signals. It is likely that these are caused by DAQ errors (the LSB of some data words are modified randomly). If they are real, they could potentially be fed into the interferometer length in those optics where the sensor signals are used for local damping during running (notably the ITMs). Triggers were generated for the detected glitches in the ITM, ETM, BS and RM sensors. PRELIMINARY studies indicate that these glitches do not affect the AS_Q signal.

Calibration lines

Calibration lines should havebeen injected throughout the S3 run, but it appears tat they were missing at some times. There are two ways to monitor the calibration lines:

SenseMonitor generates an alpha factor (Xn:CAL-CAV_FAC) exactly equal to 1.
The injection channel (Xn:LSC-DARM_CTRL_EXC_DAQ) is non-zero.

I have scanned the minute trends for the S3 data to find segments with these conditions. Unfortunately, these criteria differ somewhat in the segments indicated. I haven't determined yet which gives more reasonable results. The results are listed in the raw files (h1-sense, h1-inj, h2-sense, h2-inj, l1-sense, l1-inj) and tabulated below:

Start Time (GPS)	Duration (s)	IFO-Segment	Comments
751777200	900	H1-17	Inj
752526600	1860	H1-56	Inj
754585200	420	H1-221	Inj
754952640	2040	H1-253	Inj
754959600	300	H1-255	Inj
754961220	1200	H1-256	Inj
754963080	480	H1-257	Inj
755482020	660	H1-317	Inj
756669600	3120	H1-435	Inj
756950400	240	H1-455	Cal+Inj
757375200	780	H1-477	Inj

Start Time (GPS)	Duration (s)	IFO-Segment	Comments
751777200	600	H2-16	Inj
751782840	300	H2-17	Inj
751985760	1440	H2-33	Inj+Cal
752526000	2460	H2-81	Inj
752533200	900	H2-82	Inj
752887980	2460	H2-115	Inj+Cal
752944920	180	H2-130	Inj+Cal
752946180	180	H2-131	Inj+Cal
754585200	1500	H2-274	Inj
754952400	3720	H2-304	Inj
754959900	3660	H2-306	Inj
755028480	960	H2-310	Inj
755482260	600	H2-356	Inj
755705220	480	H2-400	Inj+Cal
756669600	3120	H2-578	Inj
756950400	300	H2-620	Inj+Cal
757375200	780	H2-671	Inj
757382400	540	H2-672	Inj
757383960	240	H2-673	Inj

Start Time (GPS)	Duration (s)	IFO-Segment	Comments
751719600	360	L1-1	Inj+Cal
751720020	120	L1-1	Inj+Cal
751724940	540	L1-2	Inj+Cal
752026200	180	L1-11	Inj+Cal
752364000	180	L1-33	Inj+Cal
752578740	60	L1-64	Inj+Cal
752897940	1020	L1-100	Inj+Cal
753156000	120	L1-124	Inj
753560220	660	L1-142	Inj+Cal
753561900	180	L1-143	Inj+Cal
753619740	300	L1-155	Inj+Cal
753645360	1020	L1-162	Inj+Cal
753768420	180	L1-168	Inj+Cal
754018260	180	L1-209	Inj+Cal
754800540	120	L1-261	Inj+Cal
754851960	1140	L1-268	Inj
755395320	300	L1-294	Inj+Cal
755895600	1200	L1-342	Inj+Cal(cal-sometimes!=1)
755901060	960	L1-343	Inj+Cal(cal-sometimes!=1)
755922060	1260	L1-348	Inj+Cal(cal-sometimes!=1)
756008040	60	L1-366	Inj+Cal
756100260	420	L1-387	Inj+Cal(cal-sometimes!=1)
756639960	660	L1-453	Inj+Cal
756690420	120	L1-461	Inj

Notes:

The SenseMonitor trends seem to be measuring slightly different minutes than the raw data trends. This may indicate that SenseMonitor is not synchronizing its minute segments to multiples of 60s. In these cases, I extended the length of the segments to cover the times flagged by both the SenseMonitor and the raw data.
In some cases I joined two or more segments that were separated by 3 minutes or less.

Front-end synchronization errors

I scanned for front-end synchronization errors by looking at minute trends of the following channels:

Channel name	Threshold
H1:SUS-RM_FE_SYNC	0.0001
H1:SUS-ITMX_FE_SYNC	0.0001
H1:SUS-MC2_FE_SYNC	0.0001
H1:SUS-ETMX_FE_SYNC	0.0001
H1:SUS-ETMY_FE_SYNC	0.0001
H1:LSC-ETP_00	60
H1:ASC-ETP_00	400
H2:SUS-RM_FE_SYNC	0.0001
H2:SUS-ITMX_FE_SYNC	0.0001
H2:SUS-FMX_FE_SYNC	0.0001
H2:SUS-MC2_FE_SYNC	0.0001
H2:SUS-ETMX_FE_SYNC	0.0001
H2:SUS-ETMY_FE_SYNC	0.0001
H2:LSC-ETP_00	60
H2:ASC-ETP_00	400
L1:SUS-RM_FE_SYNC	0.0001
L1:SUS-ITMX_FE_SYNC	0.0001
L1:SUS-MC2_FE_SYNC	0.0001
L1:SUS-ETMX_FE_SYNC	32
L1:SUS-ETMY_FE_SYNC	32
L1:LSC-ETP_00	60
L1:ASC-ETP_00	400

The FE_SYNC channels indicate the number of synchronization errors and the ETP channels give elapsed processing timeof the fron-end code (in microseconds?). The 16kHz LSC front-ends have nominally 61 microseconds available and the 2kHz ASC front-ends are allowed 488 microseconds. Rolf's statment about these channels is as follows:

I don't think that these signals are particularly good as data vetoes, at least not by themselves. LSC-ETP_00 staying over 61 for a period of time is a problem (LSC constantly late), but not a single occurrence. The FE_SYNC signals should stay at zero, and are definitely a problem at >16000. However, a count in between could be caused by only a few micro second difference between the LSC and optics controllers and may not be significant.

Nevertheless, I scanned the channels to see what can be seen. The threshold given was compared to the maximum value in each entry. Thus the comparison looks at the maximum second, but reports a whole minute. The segments flagged are listed in the following table:

Start Time (GPS)	Duration	IFO-Segment	Errors	Channel
752845860	1260	L1-97	16384	L1:SUS-ETMX_FE_SYNC
753425280	7500	L1-126	246	L1:SUS-ETMX_FE_SYNC
753425280	7500	L1-126	>32	L1:SUS-ETMY_FE_SYNC
753433560	1920	L1-127	259	L1:SUS-ETMX_FE_SYNC
753433560	1920	L1-127	37	L1:SUS-ETMY_FE_SYNC
753442620	900	L1-128	261	L1:SUS-ETMX_FE_SYNC
753442620	900	L1-128	41	L1:SUS-ETMY_FE_SYNC
753447300	360	L1-129	269	L1:SUS-ETMX_FE_SYNC
753447300	360	L1-129	41	L1:SUS-ETMY_FE_SYNC
753448560	360	L1-130	248	L1:SUS-ETMX_FE_SYNC
753448560	360	L1-130	41	L1:SUS-ETMY_FE_SYNC
753450000	2940	L1-131	251	L1:SUS-ETMX_FE_SYNC
753450000	2940	L1-131	>32	L1:SUS-ETMY_FE_SYNC
756124200	720	L1-392	7378	L1:SUS-ETMX_FE_SYNC

The highlighted segments have counts that are way over the top. The rest of the segments are from a period between November 21, 2003 4:45 UTC and November 21, 2003 12:30 UTC. In the segments where the number of errors is ">32", I joined together several sub-segments that had small intervening gaps (<2min). There are no related comments in the log and no obvious differences in the noise.

PEM Investigations

LHO Airplane Events

Katherine Rawlins has made some neat plots of noise from aircraft flying over LHO during the 8/04 LSC meeting, and in the S3 Playground. Note that the data from Both S3 and the LSC meeting were taken after the installation of sound deadening enclosures at LHO. This should have made the AS_Q channels effectively immune to most external noise. However, during the LSC meeting the IFOs were not running with common mode suppression so they were much more sensitive to acoustic pickup.

I believe that the overflights can be spotted most easily by looking at the band-limited RMS of microphone channels in the 60-110Hz band. Fortuately the RmsBands monitor has trended the 62-100Hz band rms of 5 microphones at LHO during the S2 and S3 runs. They are listed in the following table.

Channel Name	Location
`H0:PEM-PSL2_MIC`	H2 PSL table (LVEA)
`H0:PEM-BSC5_MIC`	X mid-station
`H0:PEM-BSC6_MIC`	Y mid-station
`H0:PEM-BSC9_MIC`	X end-station (poor data quality)
`H0:PEM-BSC10_MIC`	Y end-station

The X-end station (BSC9) microphone seems to have been glitching frequently during S3 so I will ignore it in this discussion. I have plotted the rms of the other four microphones in the 62-100Hz band. Each page of plots shows the RMS in the maximum 4 seconds of each 1 minute bin for all four microphones during a single day of S3. The x-axis is the UTC hour. The red line indicates times when H1 was running in science mode, and the green line is an arbitrary threshold (to 'guide the eye').

A quick visual scan of the microphone channels yields the following periods of high noise levels. I checked the eLog during the specified times and came up with the possible reasons for the elevated noise levels described in the comments field.

Start (UTC)	Start (GPS)	Duration	Comments
Nov 06 01:00	752115600	4200	EY PEM Injections
Nov 06 07:10	752137800	1800	EX PEM Injections
Nov 06 23:30	752196600	1800	LVEA PEM Injections
Nov 07 03:25	752210700	7500	LVEA PEM Injections (Noisy PSL2_MIC)
Nov 10 22:00	752536800	7200	Wind?
Nov 11 03:00	752554800	18000	Wind?
Nov 14 00:40	752805600	5640	LVEA PEM Injections
Nov 17 12:30	753107400	15000	Wind?
Nov 18 13:00	753195600	37800	Wind?
Nov 19 10:40	753273600	37200	Wind?
Nov 19 15:00	753289200	32400	PSL2_MIC noisy! Tumbleweed bailing, check ITMX coil in LVEA, replace 110Bs
Nov 20 15:00	753375600	30600	PSL2_MIC noisy! Tumbleweed bailing, work on waterpipe.
Nov 21 15:10	753462600	2100	PSL2_MIC noisy. Tumbleweed bailing.
Nov 21 19:00	753476400	18000	BSC5_MIC noisy! Tumbleweed bailing
Nov 24 18:00	753732000	7200	Wind?
Nov 25 11:00	753793200	43200	Wind?
Nov 26 21:20	753916800	3300	Noise in BSC5 (Tumbleweed baler on the move)
Nov 26 22:20	753920400	2400	Noise in PSL2_MIC (Tumbleweed baler?)
Nov 29 05:30	754119000	12600	Noise in BSC5 (Wind?)
Dec 03 01:10	754449000	10800	Noise in PSL2 (LVEA PEM Injections 0211-0357)
Dec 04 07:01	754556460	360	EY PEM Injections
Dec 04 07:21	754557660	240	MY PEM Injections
Dec 04 07:41	754558860	240	EX PEM Injections
Dec 04 07:51	754559460	660	MX PEM Injections
Dec 05 00:10	754618200	1800	Fiddling with DAQ
Dec 11 17:30	755199000	1800	Noise in PSL2 ("Hazardous Load" truck passed)
Dec 23 00:00	756172800	3600	Noise in BSC6 (Wind)
Jan 01 18:00	757015200	21600	Wind?

Once these bad periods have been eliminated, candidate airplane events can be found by looking at the RMS in the band 62-100Hz of


H0:PEM-PSL2_MIC

(this is the only LVEA microphone for which this band was trended). The following figure shows the RMS of the loudest 4 second sub-interval in each minute of S3 running. Except for the noisy periods listed above, no selection was made for e.g. IFO being in lock. Note that the red line indicates the threshold used below (1500). This seems to be within ±200 units of the break between a gaussian background peak and a power law amplitude distribution.

Maximum 4 second RMS in 62-100Hz band for all minutes of S3

Maximum 4 second RMS in 62-100Hz band for all minutes of S3

The maximum RMS in the 62-100 Hz band averaged over all minutes of S3 of H0:PEM-PSL2_MIC varies with the time of day as shown below. The x-axis is the UTC hour. Note that there are no noise spikes at night (midnight - 6 AM local time corresponds to 8-14 UTC), but large spikes in the average noise are visible at certain times (scheduled flight times?).

A complete list of airplane candidates seen while the interferometers were in science mode can be found here for H1 and H2. Each line of this file has the start time in GPS seconds and as a UTC date string, the number of minutes that the rms was above the threshold, the RMS value and the H1 segment number. The 20 loudest "Airplane" candidates seen while H1 was in science mode are:

Start Time (GPS)	Start Time (UTC)	Duration (min)	RMS	Segment
755627760	`Dec 16 16:35`	1	12598	H1-340
752692740	`Nov 12 17:18`	1	13552	H1-073
757276500	`Jan 04 18:34`	2	13805	H1-470
757694880	`Jan 09 14:47`	1	14346	H1-504
754592520	`Dec 04 17:01`	1	14519	H1-222
755116560	`Dec 10 18:35`	1	14631	H1-277
756535500	`Dec 27 04:44`	1	16524	H1-430
752377140	`Nov 09 01:38`	1	16972	H1-048
751760220	`Nov 01 22:16`	1	17187	H1-014
752739360	`Nov 13 06:15`	1	22784	H1-079
754888620	`Dec 08 03:16`	2	23419	H1-251
754781400	`Dec 06 21:29`	1	25349	H1-245
754900200	`Dec 08 06:29`	1	27679	H1-251
756426600	`Dec 25 22:29`	1	29166	H1-423
754207500	`Nov 30 06:04`	1	30375	H1-186
753667140	`Nov 23 23:58`	1	31851	H1-149
757454280	`Jan 06 19:57`	1	33077	H1-483
755551860	`Dec 15 19:30`	2	34165	H1-325
753645720	`Nov 23 18:01`	1	52097	H1-149
756844080	`Dec 30 18:27`	1	157037	H1-448

LLO Airplane Events

I Have performed a similar study on the LLO microphone channel. In this I assume that the same 62-100Hz band can be interpreted in a similar way, even though there is much less airplane activity near the LLO site. Unfortunately, the LLO RmsBands monitor look only at the L0:PEM-PSL1_MIC channel. This is analogous to the PSL2_MIC channel at LHO so it should give analogous results, but Robert has suggested that other microphones be looked at in future runs. I have plotted the RMS in the 62-100Hz and the 100-400Hz bands for all 1 minute intervals in the S3 science run. As in the case of the LHO trends, the red line shows time when the L1 interferometer was in lock. From this I found the following times where the environment was noisy, mostly because of work going on in the LVEA.

Start Time (UTC)	Start Time (GPS)	Duration (s)	Comments
Nov 01 03:00	751690800	1800	Tweaked PSL knobs to unload PZT sliders
Nov 05 16:30	752085000	3600	Extreme noise, Daq controller reboot
Nov 05 18:10	752091000	3600	Changed PSL periscope mirror driver (before 2100?)
Nov 11 20:50	75305100	600	Reboot l1dcs
Nov 19 19:15	753304500	4500	Pulled, reinstalled MC1 driver
Nov 24 03:00	753678000	32400	Missing data
Dec 04 19:00	754599600	1200	Noisy in 100-400 Hz band
Dec 11 22:50	755218200	2400	LSC FE died - open doors of ekectronics rack
Dec 12 04:50	755239800	3600	Noisy - Setup for PEM Inj?
Dec 12 05:50	755243400	1200	LVEA PEM Injections
Dec 12 09:00	755254800	1800	EY PEM Injections
Dec 13 04:50	755326300	1500	EX PEM Injections
Dec 13 05:50	755329800	1500	Noisy
Dec 13 06:20	755331600	600	LVEA Radio injections
Dec 15 05:00	755499600	2400	Noisy 62-100Hz (PEM Injections mentioned in eLog)
Dec 16 18:00	755632800	2700	noisy???
Jan 05 16:30	757355400	900	Noisy 100-400Hz
Jan 07 06:00	757490400	2400	Replaced electronics box on PSL table
Jan 07 07:00	757494000	900
Jan 07 07:30	757495800	3600

After eliminating these time segments, I histogrammed the maximum RMS in each minute, and calculated the average RMS versus the time of day, as shown below.

There is much less noticeable activity in these plots than those from LHO as can be expected from the lack of regularly scheduled flights passing over the laboratory.

After choosing a threshold (500) that eliminates the vast majority of the constant background noise, I listed all the minutes that exceed this threshold while L1 was in science mode. To my surprise, there are only two such events. These are listed below here and in the table below:

Start Time (GPS)	Start Time (UTC)	Duration (min)	RMS	Segment
753034500	Nov 16 16:14	1	530	L1-117
755996640	Dec 20 23:03	1	556	L1-364

Last modified: September 24, 2004 10:30 PST by John Zweizig