[Jennie, Louis, Gabriele]

This morning we carried out some tests to understand if the excess DARM noise could be OMC length noise. We increased the OMC  in-lock residual length RMS (by changing the loop gain and by injecting a 4 Hz line), and changed the OMC lock offset. We expect the coupling from OMC length to DARM to scale linearly with both the RMS and the offset.

More details will follow in comments, but we increased the OMC length RMS by about a factor 10 and saw no visible change in the DARM noise in the bucket. We also added several lock offsets and saw no change in DARM noise in the bucket.

So the DARM excess noise is not OMC length noise.

During the test we injected a 135 Hz OMC length line, and checked that the coupling scales as expecetd with the RMS and the offset.

We lost lock at the end of the ramp when we were changing the OMC length dither frequency from 4100 Hz to 4101 Hz with a 30 second ramp. We saw that the 4 Hz bump in the error signal was moving toward 5 Hz during the ramp: this confirms that the origin of the 4 Hz bump is due to some "beat" between 4100 Hz and 4096 = 16348/4 Hz

TITLE: 03/21 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.21 μm/s
QUICK SUMMARY:

We've been locked for 9.5 hours! More commissioning!

TITLE: 03/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC

STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

A return to Observing for H1 (first time since mid-Jan, and a return to Triple Coincidence with Virgo + both LIGO detectors for the first time since O3!)---this occured after about 90min of Commissioning work.  It was a little bit of a rocky start with a wind storm with sustained winds in the 20mph range for almost half the shift (and gusts above 40mph).  This made for several hours of down time (forgot to mark as "WIND" with OBSERVATORY MODE unfortunately).  Eventually able to get back to Observing toward the end of the shift.
LOG:

• 2345-0119 SHG work in optics lab (julian)
• 0043 Back to Observing! (with a cleaned range value of 150Mpc).
• 0110 LOCKLOSS (Lock Clock 3hrs38min, but only about 27min of Observing)
  • Lock#1:  had to go to CHECK MICH FRINGES, but lockloss at ENGAGE DRMI ASC.
  • Lock#2:  lockkloss at FINDIR
• 0141-0207 Initial Alignment:  No issues running it.
  • 0200 MX wind gusts over 40mph
• Lock#3:  Lockloss at FIND IR (again)  :(
• Lock#4:  Lockloss at LOCKING ALS----will stop documenting locking attempts due to strong winds.
• Stopped locking for an hour (winds were still high; could hear noise from Control Room!).  When returning to locking, H1 had a stint of trouble for CHECKING IR.  TR_Y had flashes around nice DIFF OFFSET values, but it kept going/skipping over them (passed about 3 "nice spots" and then said it could not FIND IR---so I did it by hand, but that seemed odd---granted this also happened during the high winds time.).  Then when H1 got to DRMI and PRMI, they looked completely dead/no-flashes at all--possibly due to being "down" for a couple hours at this point.
• 0415 This is when the wind started to calm down.
• 0422-0450 2nd Initial Alignment of the night.
  • INPUT_ALIGN had a bout of having nice quick flashes, but these would kick the IMC out of lock (similar to the painful attempts last night).  It did this a handful of times and then finally TR_X stayed locked and INPUT_ALIGN was able to finish.
• 0503 Dust Monitor #10 major alarm (probably due to wind.
• 0533 NLN (where at 0535 CAMERA SERVO completed & 0537 Violin Damping completed).  There were SDF diffs for PR3 which were accepted.
• 0539 Return to OBSERVING and Triple Coincidence!

After our windstorm, finally ready to get back to OBSERVING, but we had SDFs for PR3 (I could have sworn we had SDFs for PR3 at the beginning of the shift when we were racing to address the piles of SDF Diffs we had so we could get to Observing.).  At any rate, the (3) channels are for Enabling the Input for (3) PR3 channels (see that attached photo of the SUSPR3 Diffs which were ACCEPTED).

Winds really picked up a bit shortly after we went to Observing.  Have run an alignment, but the last 90mins have seen little action beyond DRMI....made it to OFFLOAD DRMI once.  Will hold for an hour at LOCKING ARMS GREEN for an hour (and while I make lunch).

Let's assume the additional flat noise in the ~100 Hz region that might be limiting now (w.r.t. to O4a) is due to OMC length noise. Either the OMC lenght noise is larger than before, and coupling through the residual OMC length RMS noise, or the OMC lock has an offset.

Let's assume that the OMC was locked at the top of the resonance (no offset, to be confirmed with the new demodulation phase).

According to 76137, the two PZT responses are PZT1 = 11.3 nm/V, and PZT2 = 12.7 nm/V.

Following Sheila's note in 30510, the normalized OMC transmission (RIN) is given by [after correcting for a mistake in the coefficient multipling F]

RIN = 1 / (1 + (2 F (x0 + dx)/ lambda)^2 )

where F = 400 is the OMC finesse (76386), x0 is a static lock offset (or equivalent RMS fluctuation) and dx is OMC lenght noise (form example due to dither).

The amplitude of the dither line is 0.23 V peak, corresponding to a dither amplitude (peak) of A = 2.6e-9 m, using the PZT1 calibration above.

The locking error signal is obtained using a length modulation dx = A sin(wt) that gives a RIN = (2F/lambda)^2 A sin(wt) x0, where x0 is the offsetf from resonance of the OMC length. Once demodulated, this gives

OMC-LSC_I = (2F/lambda)^2 A/2 x0 = 7.3e8 error_signal_demodulated_RIN / m (note that 30510 seems to be wrong and missing some factors, thank you Elenna for checking)

This allows me to calibrate the OMC-LSC input signal. The RMS with the OMC locked is 4.7e-5 RIN, corresponding to 6.4e-14 m RMS of residual OMC fluctuation around the lock point.

The flat noise in DARM is about 7e-21 m/rHz. Using the optical gain from the calibration measurement (3.4e6 LSC-DARM_IN cts/m) and the ratio LSC-DARM_IN / OMC_DCPD_NORM = 1.6e-5, I find an optical gain of 2.1e11 RIN/m for OMC-DCPD_NORM

Therefore the noise in DARM corresponds to a OMC-DCPD RIN of 1.5e-9 RIN/rHz

Noise coupling due to the residual OMC length RMS goes like (2F/lambda)^2 x_RMS dx_noise, where x_RMS is now the residual RMS motion computed above. Using this conversion, I found that the excess noise in DARM would correspond to a OMC length noise of 4e-14 m/rHz at 100 Hz. This still seems higher than the expected noise that should be in the 3e-16 m/rHz range (see for example section 8 of T1000276)

Tests to do:

1. check if the new demodulation phase improves anything in DARM
2. scan the OMC lock offset around 0, looking at DARM noise and at the optical gain (for example amplitude of the 410.3 Hz calibration line)
3. change the locking gain to reduce / increase RMS and check DARM

In addition to the BSC10 accelerometer, the amount of floor motion also increases over the past 6 weeks, though not in a sudden fashion.

This does not correspond to the time of the most recent fan swap, judging by fan accelerometers.

Naoki, Daniel, Nutsinee

Today we increased RF6  from -22dBm to -13 dBm and 8 dBm. We saw excess noise at 8 dBm above 300Hz but no excess noise at -13dBm. REF 12 is the squeezing at -22dB before we started the test. Using the time from alog76553. REF9 and REF10 both show squeezing at -13dBm RF6 at different squeeze angle where one has a better sensitivity at low frequency bucket. REF13 shows squeezing at 8dBm RF6. The excess noise above 300Hz cannot be improved with squeeze angle. Investigation is required.

We turned off ADF sqz angle servo during the test. We readjusted the ADF squeeze angle demod phase and accepted the new value in the SDF.

We are parking RF6 at -12dBm. Since Daniel didn't like the unlucky number 13.

SDFs from green initial alignment setpoints

Jenne was pecking away at SDFs (separate alogs), Jennie/Evan did OMC (I took screenshot below), Louis helped with PCal.....Squeezer work is currently active, so will wait for that team to ACCEPT Squeezer!

Pecking away at some SDFs in preparation for OBSERVING tonight:

Easy Ones To ACCEPT: 

• SUSETMY & SUSITMX:  Both of these only had (1) Time Ramp diff  (image#1)

More Involved to ACCEPT:

• SUSETMX:  handful of diffs (image#2), but they were from the recent lock and are confirmed in the ISC_LOCK.py.
• OMC:  Jennie & Evan worked on accepting these (see images 3&4....the latter is accepting the DARM1 filter bank before I could take an SDF screenshot).
• OAF: (image#5)  Jenne said I could ACCEPT these (she couldn't find notes on them in the alog, but she said they should be accepted).
• CALEY:  (image#6)All of these were for PCal--->REVERTED a recent T-Ramp & ACCEPTED the rest of the diffs (which were from Feb).  Louis was looking over my shoulder.

These changes were accpted, but need to be set again after aligning the FC IR transmission.

Noaki added a gain increase to the CAM1 PIT loop for faster convergence.  It should be in the guardian, so I've accepted it in SDF.

DHARD yaw new FM8, alog 76314.

Accepting AS_A offset engagement in Observe.snap.  Values from alog 76500

I've accepted dark offsets for the LSC and ASC PDs in SDF for the Observe.snap files. 

Naoki, Nutsinee, Camilla

We turned the SQZ_ANG_ADJUST servo back to it's O3a nominal ADJUST_SQZ_ANG_ADF.  Changed sqzparams.use_sqz_angle_adjust to True and reloaded SQZ_MANAGER and SQZ_ANG_ADJUST.

Set H1:SQZ-ADF_OMC_TRANS_PHASE as 133deg, new scan (as in 76434) running now to check what angle is best for total squeezing.

The commissioners are aware of this now and some people are looking into it, but it seems that the new DARM offloading scheme has been sending big kicks (a few 10s to 200 microns) to the ETMX HEPI at almost every lockloss from NLN. This doesn't seem to be happening with ETMY. On attached trends, top blue trace is the ISC tidal signal sent to ETMX HEPI, yellow is the ISI watchdog state, bottom is the ISC LOCK state number. The ISI doesn't trip every time, but it's happend 5 times just over the last week. This isn't normal behavior, but it seems like we've just been ignoring this for a while. I recall having this happen a bit before the end of O4a, and we added a filter to the input to the HEPI model, but that just seems to slow the kick a bit.