Sheila, Georgia

We have taken measurements of the OMC length noise - the top plot of the first attachment shows the length noise ASD in yellow - and projected it to be a factor of 30 below DARM at its closest point (second attachment). In the second attachment the blue and purple curves are DARM and the OMC length noise projection with no excitation. The red and yellow traces are taken when a 12 Hz line is injected at OMC PZT2, causing a 24 Hz line in DARM (OMC length to power on the DCPDs is a quadratic coupling), and additional broadband length noise below 100 Hz, and around the 1080 Hz resonance in HAM6. The prediction of length noise to DARM around 100Hz is a little off but this isn't unexpected given the way we have combined to witnesses of length noise, details below.

---

This measurement is a bit convoluted. When the OMC is on resonance the coupling from change of cavity length to power on the transmission DCPDs is quadratic (figure 1 in Dan Hoak's alog (19212) about exactly this measurement taken 2 years ago). To make a linear coupling from change in length to power on the DCPDs we can lock the OMC with an offset in the servo, i.e. on the side of a fringe. From the noise on the DCPDs while locked on the side of the fringe, and knowledge of how far off resonance we are, we can work out the change in OMC length this corresponds to. The maths for this conversion is summarised in the pdf attached to Sheila's alog (30510) about this measurement in 2016, and the script I used to make this projection is in:

/ligo/home/sheila.dwyer/Noise/OMC_LENGTH/2019/calibrate_DCPD_spectra_750_blend_servo.m

When we lock on the side of the fringe, above a few hundred Hz we see length noise. However around the dither line which the OMC length is locked to (4100 kHz), there is extra noise which then gets down-converted. This extra noise limits this measurement at low frequency (extra noise below a few hundred Hz in the blue trace in the first attachment). To see below this noise we can look instead at the in-loop error signal when in full lock, as Sheila did in the previous length noise measurement. The red trace of first attachment shows this error signal filtered by the closed loop gain of the OMC length loop. We also tried looking at the drive signal to the OMC PZT2, but this was too noisy. So the actual OMC length noise projection is made by combining the low frequency component of the in-loop error signal, and the high frequency component of the side-of-fringe measurement, shown in yellow in the first attachment. The top plot in the first attachment shows the length noise with no excitations to OMC length, and the bottom plot shows the length noise with a 12 Hz line injected, which we'll use later as a sanity check when projecting to DARM. The combination of length noise witnesses is a bit of a guess in the 50-300 Hz region, which is why I'm not surprised out projection doesn't line up perfectly with DARM in this region.

We next convert the length noise in m into the DCPD RIN (using equation 1 of the pdf attached to alog 30510). Multiplying this by the full lock DCPD current and adding the DARM calibration in m/mA (and the cavity pole and optical gain), we can convert this projection into meters of DARM displacement. This gives the yellow and purple traces in the second attachment.

As a sanity check we inject a 12 Hz line into the OMC length (A=0.3, applied to PZT2) while locked on the side of fringe, and while in full lock. We can compare DARM and OMCL at the line frequency, the extra length noise around it, and the extra broadband noise around the 1083 Hz resonance (3rd attachment), it agrees well.

Some things to note:

• This projection doesn't tell us anything about the shoulders on the 60 Hz line, both the side-of-fringe and in-loop error signal don't have anything much at 60 Hz.
• The ambient OMC length noise projection and the shoulders around that (4th attachment), underestimating them by a factor of ~6.

Sheila, Nutsinee

Following up alog47184 we investigated on how the other two peaks (one at 177.7Hz and the other at 262Hz) behave with different CLF power and UGF. The peaks only responded to decreasing/increasing loop gain but not to increasing power. We didn't do other tests (eg. noise eater on/off) since the IFO lost lock. We also tried decreasing LO loop gain but that didn't do anything. The mystery continues. 

Note that the high CLF gain with 0.02mW going in to the coupler is what we are normally operating. 

Same CLF gain label of the third plot means same UGF as the first plot.

I think we left the CLF power at 0.08mW into the coupler. For optimized IFO squeezing tonight (if needed) I recommend putting it back to 0.02 mW. 

In order to try to eliminate channels that are changing too frequently for the data acquisition, I have reduced the monitored channel list to these. There are still 264,176 channels in this set, and the startup time remains long (more than 20 min). The queue size however has finally dropped to 0. The channel list is attached.

The FEC channels include those ending in:
DIAG_RESET
OVERFLOW_RESET
LOAD_NEW_COEFF
LOAD_CONFIG
BUILD_SVN
MSG
MSGDAQ
SDF_MON_ALL
SDF_CONFIRM
SDF_LOADED
SDF_RELOAD
SDF_SAVE_CMD

The filter module channels include those ending in:
SWSTAT
TRAMP
OFFSET
GAIN
LIMIT
SW1
SW2
RSET
SW1R
SW2R
SW1S
SW2S
Name00
Name01
Name02
Name03
Name04
Name05
Name06
Name07
Name08
Name09

The following channels are currently unmonitored:
H1:DAQ-FEC_27_LOAD_CONFIG
H1:FEC-27_BUILD_SVN
H1:FEC-27_DIAG_RESET
H1:FEC-27_LOAD_NEW_COEFF
H1:FEC-27_MSG
H1:FEC-27_MSGDAQ
H1:FEC-27_OVERFLOW_RESET
H1:FEC-27_SDF_CONFIRM
H1:FEC-27_SDF_LOADED
H1:FEC-27_SDF_MON_ALL
H1:FEC-27_SDF_RELOAD
H1:FEC-27_SDF_SAVE_CMD

Keita and Daniel decided that the CNS-II GPS receivers should be returned to the end stations and ran with the current firmware for ER14/O3. The firmware upgrade was to fix a midnight problem, whereby the IRIG-B decoded time had an incorrect seconds field at midnight, zero seconds being replaced by the month number (1-12).

I reinstalled the receivers at the end stations:

The units were powered between noon and 1pm PST, as of writing we are still waiting for GPS lock.

TITLE: 03/04 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:

16:00 ER 14 BEGINS

16:15 Corey out to check HEPI pumps

16:21 Daniel out to HAM5 - warming-up SRM heater

16:25 Corey back

16:27 Daniel back

17:00 WP meeting

17:49 Chris S out to inspect road conditions down both arms

18:13 Kyle, Karen, Chandra and Fil out to MY

18:30 Jason to MX - Laser for SR3 OpLev

19:25 Dave B out to ends - EX first then EY (GPS clocks)

19:58 Karen leaving MY

20:01 Vanessa to MX

20:28 Dave B done at EX and reporting arrival at EY

20:29 Richard and Fil out to LVEA

20:31 Kyle back

20:41 Richard and Fil back

21:13 Fil back out to MY

22:00 Rich and Richard out to EX

22:30 Rich and Richard back

22:45 Danny and Dan out to LVEA HAM6

Attached are the VPW desiccant plots with the data since December 2018 added.  All 4 data readers are recording data as they should.  Nothing out of the ordinary shown

This is a follow-up on Sheila's alog about DHARD limiting the sensitivity (47209). 

In summary: DHARD_P coupling to DARM is non stationary, we can subtract more with a non-stationary algorithm (at least during the noise injection, to be checked during quiet time)

Evidence of non-stationary coupling

The first evidence, as pointed out by Sheila, is that during a DHARD_P noise injection "the noise in DARM was increased by about a factor of 10-20 below 50Hz, but the coherence between DARM and the excitation is only around 0.7". The plot below shows the increase in DARM noise during the injection (note: I don't know what the line at 3X Hz is, probably my "quiet" time was during some other test) and how the coherence is too low, considering the SNR of the injection in both DARM and DHARD.

Another better evidence is provided by the spectrogram of DARM and DHARD around the injection time. The first figure below shows the DARM and DHARD signals when the noise injection is turned on (quiet time before t~=60s, DHARD_P injection for t>~60 s). DHARD_P is stationary, DARM is not. The second figure shows the DARM spectrogram, whitened to the median of the quiet time. The non-stationarity of the DARM noise is evident.

Non-stationary noise subtraction

I used the non-stationary noise subtraction code described in many previous alogs for SRCL (45823 and links therein) and in all the details in T1800525. The noise witness channel is in this case ASC-DHARD_P_OUT_DQ, and the modulation channels are all the ASC input monitors. I used about 60 seconds of data during the DHARD_P noise injection (GPS = 1235434291 + 60s) to train the non-stationary model. For now the performance of the subtraction is shown on-target, meaning that I am using the same 60s to train and evaluate. There are other noise injections near that time and some quiet periods that I will later use.

First observation: the linear noise subtraction (green trace) does not perform very well, since it reduces the DHARD noise into DARM only by less than a factor 2. Second observation: the non-stationary noise subtraction (red trace), obtained by allowing the coupling to be modulated by the ASC input signals, performs much better at frequencies above 30 Hz, and slightly better at frequencies between 10 and 30 Hz. Not all DHARD noise is removed (compare red and orange).

The plot below shows the main contribution to the noise subtraction, the main modulation coming from PRC1_P.

The last plot attached (not shown inline) contains all the coupling transfer functions.

To do list

• convert the subtraction filters to time domain
• apply the time-domain subtraction to
  • another noise injection to check off-target performance
  • a quiet time, to see how much we can gain at low frequency

H1tw3 (the new tw) is reporting a failed disk.

[530922.324644] sd 0:0:3:0: [sdd] Unhandled error code
[530922.324649] sd 0:0:3:0: [sdd]  
[530922.324653] Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
[530922.324657] sd 0:0:3:0: [sdd] CDB: 
[530922.324661] Read(10): 28 00 3d 15 ab 68 00 00 80 00
[530922.324674] end_request: I/O error, dev sdd, sector 1024830312
[530922.833251] md/raid:md2: read error corrected (8 sectors at 1024830312 on sdd)
[530922.833260] md/raid:md2: read error corrected (8 sectors at 1024830320 on sdd)
[530922.833264] md/raid:md2: read error corrected (8 sectors at 1024830328 on sdd)
[530922.833268] md/raid:md2: read error corrected (8 sectors at 1024830336 on sdd)
[530922.833270] md/raid:md2: read error corrected (8 sectors at 1024830344 on sdd)
[530922.833273] md/raid:md2: read error corrected (8 sectors at 1024830352 on sdd)
[530922.833277] md/raid:md2: read error corrected (8 sectors at 1024830360 on sdd)
[530922.833280] md/raid:md2: read error corrected (8 sectors at 1024830368 on sdd)
[530922.833282] md/raid:md2: read error corrected (8 sectors at 1024830376 on sdd)
[530922.833287] md/raid:md2: read error corrected (8 sectors at 1024830384 on sdd)
[2037012.740535] md: data-check of RAID array md0
[2037012.740541] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[2037012.740544] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[2037012.740551] md: using 128k window, over a total of 1950720k.
[2037012.772561] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
[2037012.786333] RAID conf printout:
[2037012.786339]  --- level:6 rd:6 wd:6
[2037012.786353]  disk 0, o:1, dev:sda
[2037012.786356]  disk 1, o:1, dev:sdb
[2037012.786358]  disk 2, o:1, dev:sdc
[2037012.786360]  disk 3, o:1, dev:sdd
[2037012.786362]  disk 4, o:1, dev:sde
[2037012.786364]  disk 5, o:1, dev:sdf
[2037012.786414] md: data-check of RAID array md2
[2037012.786418] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[2037012.786421] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[2037012.786430] md: using 128k window, over a total of 512674304k.
[2037022.277393] md: md0: data-check done.
[2037022.281423] md: data-check of RAID array md1
[2037022.281427] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[2037022.281429] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[2037022.281434] md: using 128k window, over a total of 242114560k.
[2038242.597751] md: md1: data-check done.
[2041160.323778] md: md2: data-check done.
[2041160.335370] RAID conf printout:
[2041160.335391]  --- level:6 rd:6 wd:6
[2041160.335393]  disk 0, o:1, dev:sda
[2041160.335395]  disk 1, o:1, dev:sdb
[2041160.335397]  disk 2, o:1, dev:sdc
[2041160.335398]  disk 3, o:1, dev:sdd
[2041160.335400]  disk 4, o:1, dev:sde
[2041160.335401]  disk 5, o:1, dev:sdf

To aid in finding it:

ata-Crucial_CT525MX300SSD1_1710162E56E0 -> ../../sdd

I'll check with Dave but we will probably take care of this during the daq downtime tomorrow.

The general query log had grown to 1.3 TB, so I turned it off and restarted both MySQL and conlog. The queue size is currently around 970,000 and growing. I'm not sure if it is going to drop to 0 or not. The list of added and removed channels is attached.

Averaging Mass Centering channels for 10 [sec] ...
2019-03-04 12:04:49.360399
There are 10 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 1 DOF X/U = 0.412 [V]
ETMX T240 1 DOF Y/V = 0.317 [V]
ETMX T240 1 DOF Z/W = 0.419 [V]
ETMX T240 2 DOF X/U = -0.307 [V]
ETMX T240 2 DOF Y/V = -0.736 [V]
ETMX T240 3 DOF X/U = 0.345 [V]
ITMX T240 1 DOF X/U = -0.427 [V]
ITMX T240 3 DOF X/U = -0.373 [V]
ITMY T240 3 DOF Z/W = -0.59 [V]
BS T240 1 DOF Z/W = 0.31 [V]

All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 2 DOF Z/W = 0.234 [V]
ETMX T240 3 DOF Y/V = 0.292 [V]
ETMX T240 3 DOF Z/W = 0.292 [V]
ETMY T240 1 DOF X/U = 0.085 [V]
ETMY T240 1 DOF Y/V = 0.264 [V]
ETMY T240 1 DOF Z/W = 0.107 [V]
ETMY T240 2 DOF X/U = 0.107 [V]
ETMY T240 2 DOF Y/V = 0.021 [V]
ETMY T240 2 DOF Z/W = 0.036 [V]
ETMY T240 3 DOF X/U = 0.115 [V]
ETMY T240 3 DOF Y/V = 0.107 [V]
ETMY T240 3 DOF Z/W = 0.289 [V]
ITMX T240 1 DOF Y/V = 0.165 [V]
ITMX T240 1 DOF Z/W = 0.138 [V]
ITMX T240 2 DOF X/U = 0.184 [V]
ITMX T240 2 DOF Y/V = 0.165 [V]
ITMX T240 2 DOF Z/W = 0.257 [V]
ITMX T240 3 DOF Y/V = 0.152 [V]
ITMX T240 3 DOF Z/W = 0.057 [V]
ITMY T240 1 DOF X/U = 0.217 [V]
ITMY T240 1 DOF Y/V = 0.142 [V]
ITMY T240 1 DOF Z/W = 0.192 [V]
ITMY T240 2 DOF X/U = 0.154 [V]
ITMY T240 2 DOF Y/V = 0.268 [V]
ITMY T240 2 DOF Z/W = 0.24 [V]
ITMY T240 3 DOF X/U = -0.092 [V]
ITMY T240 3 DOF Y/V = 0.23 [V]
BS T240 1 DOF X/U = 0.004 [V]
BS T240 1 DOF Y/V = -0.078 [V]
BS T240 2 DOF X/U = 0.079 [V]
BS T240 2 DOF Y/V = 0.29 [V]
BS T240 2 DOF Z/W = -0.02 [V]
BS T240 3 DOF X/U = 0.112 [V]
BS T240 3 DOF Y/V = -0.162 [V]
BS T240 3 DOF Z/W = -0.154 [V]
Assessment complete.

Averaging Mass Centering channels for 10 [sec] ...
2019-03-04 12:07:07.353372
There are 1 STS proof masses out of range ( > 2.0 [V] )!
STS A DOF X/U = -7.969 [V]

All other proof masses are within range ( < 2.0 [V] ):
STS A DOF Y/V = -0.922 [V]
STS A DOF Z/W = -0.258 [V]
STS B DOF X/U = 0.29 [V]
STS B DOF Y/V = -0.523 [V]
STS B DOF Z/W = -0.308 [V]
STS C DOF X/U = 0.358 [V]
STS C DOF Y/V = 0.165 [V]
STS C DOF Z/W = 0.645 [V]
STS EX DOF X/U = 0.026 [V]
STS EX DOF Y/V = 0.345 [V]
STS EX DOF Z/W = 0.317 [V]
STS EY DOF X/U = 0.359 [V]
STS EY DOF Y/V = -0.13 [V]
STS EY DOF Z/W = 0.793 [V]
Assessment complete.

Laser Status:
Front End Power is 32.1W (should be around 30 W)
70W Output Power is 70.84W
Front End Watch is GREEN
70W Watch is GREEN

PMC:
It has been locked 4 days, 20 hr 12 minutes (should be days/weeks)
Reflected power = 10.43Watts
Transmitted power = 54.54Watts
PowerSum = 64.97Watts.

FSS:
It has been locked for 0 days 0 hr and 16 min (should be days/weeks)
TPD[V] = 4.103V (min 0.9V)

ISS:
The diffracted power is around 2.4%
Last saturation event was 0 days 0 hours and 16 minutes ago (should be days/weeks)

Possible Issues:

Stefan, Peter, Rich

It was found that the overall DC gain, and the pole-zero location associated with the second filter module of the OMC DCPD Whitening chain, was somehow dependent on input signal level.  A parametric study was done on the OMC DCPD whitening chain for different whitening filter combinations with and without DC offset.  Notes detailing the parametric study are attached to this entry.  

There were two causes of these phenomena:  
1.  Gain Change - As the DC input to the OMC DCPD Whitening amplifier (D1002559 Chassis S1101627) is varied, the DC level causes saturation in some of the DC coupled gain stages.  This saturation causes the normally high-impedance amplifier input to be fairly low due current flowing into the input protection diodes internal to each opamp stage.  This lower input resistance in conjunction with the series resistance of the FET switches produces a voltage divider with a division ratio dependent on signal level.
2.  Pole-Zero Change - The second filter module had an ECR (E1500252) performed that required a 1uF capacitor to be used.  This type of filter function is supposed to be implemented with a plastic film dielectric capacitor, but a ceramic capacitor was used instead.  The piezoelectric nature of ceramic capacitors can result in a capacitance that will change with applied voltage.  This caused the pole-zero location to vary as a function of DC level.  This capacitor was changed to the proper type and the problem went away.

Data (attached) was taken for both OMC DCPD chains by injecting signals into the input of the OMC whitening chassis (DCPD Preamps disconnected), and taking the output differentially from the analog output of the whitening chassis with the ADC cable still attached (to account for any loading effects).  This data was taken with and without a 5V DC offset to verify that there is no longer any effect on the signal path gain.

We note that the above were all small effects, but significant in the world of 1% calibratin uncertainty. The DC gain reduction with a 5 V offset (similar to the offset in NLN operation) was 0.2 dB. The errors in the filter stage with offset were -- phase: 0.6-1 degree at 50 Hz; magnitude: 0.15 dB gain difference between 50 Hz and 200 Hz.

Craig, Rich, Peter, Stefan,

We tried to measure and fine-tune the DCPD whitening filter compensation. so we took the following measurments:

a) Analog transfer function on the floor for PDA & PDB; FM1FM2FM3 all off and FM1FM2FM3 all on (run configuration). (That's 4 measurements total.) That data is still on disk and Rich will post it.

b)  Driving both DCPDs with noise, measure the PDA/PDB transfer function. This is done with FM1&FM2 on PDA and FM1 on PDB, normalized by  FM1 on PDA and FM1 on PDB to take out other systematics.

Measurement b) was performed with a variety of noise sources:

i) IFO on AS_RF45, with additional 100Hz-1kHz frequency noise injection. (IFO)
ii) White noise drive (10Vpkk) (Orig white)
iii) Same white noise, but FM6 filters in PDA and PDB off (White 2). Note that changed the transfer function at the 1e-3 level compared with ii) - consistent with T990013-B (dtt documentation)
iv) Same white noise, but now filtered by SR560 with 2 poles at 100Hz (Pink)
v) White noise at half the level (5Vpkk) (White 3)
vi) Same as white 3, but with 2 poles at 100Hz in the digital system (W3 Dig Poles)
vii) Same as white 3, but additional 2V offset (~13000cts at IN1) (W3 offset)
viii) Simple model z59.8265:p60.174,120k

Note that at 100Hz the transfer function is changing by as much as 0.3dB (3.5%) with drive level..THis is much bigger than the expected dtt error, so we conclude it is real, We will deal with the implications for calibration tomorrow.

Peter F., Rich A., Daniel, Nutsinee

The dark noise is factor of 3.75 better with the new diode. With this we can crank up the loop UGF as high as we could to squash the acoustic noise (and some of the stuff above 1kHz). We can also try operating at lower CLF power. With both of these things we should gain a bit more squeezing. 

Compared to the old diode we gained 8dB of RF power. More information about the new diode can be found in alog47171 and alog47196.

Also attached RF beat note and the sine wave from the IQ demod board RF mon (23dB attenuated).