TITLE: 10/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Locking up to where the commissioners have been having trouble has been very repeatable and straight forward. Initial alignment right now had ALSY DOF 3 P very slowly going unstable. Handing this off to Oli and Elenna, sorry!

• Morning locking notes

LOG:

TITLE: 10/12 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 4mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.33 μm/s 
QUICK SUMMARY: Commissioners doing good work 

I have designed a basic 3 part blend for differential length for SPI, now installed on HAM2 X in the supersensor 6 path. This is not meant to be a highly optimized blend filter, I'm still puzzling through how to try to do the modeling for this and I know Sina is working on something that will probably be better. It should be good enough to try turning on and seeing if we can get some improvement in, ferinstance, the IMC. First attached image compares the installed version ("new") to the 250mhz CPS/GS13 blends that we use most of the time for X. 

Second image shows the complementary form of the filter magnitudes and the sum, showing the total for the super sensor is 1 at all the cross-overs. 

This is mostly meant to be a starting point, I expect we will need to do some more development on this.

The chillers at the Mid stations have been disabled for the winter. They have been shut down through FMCS but are still energized to allow for operation of the compressor crankcase heaters. 

FAMIS 63920

There was a brief incursion last Tuesday, as usual shown on several trends. I'll bump up the ISS diffracted power as it looks like it's drifted down again. Otherwise, no major evens of note this week.

Sophie, Miriam, Fil, Camilla 

The ITMY CHETA laser table that we moved to the LVEA turned on fine when tested this morning. The alignment appears be good after the move. Fil added it into the interlock on Tuesday. 

We needed to adjust wiring of fan to get it to run. Laser ran fine, Flipper powered on but wasn't behaving as expected, expect we may need to reprogram it (T1700462) as it's not had power for many months. 

The Beckhoff system is working, we have been able to move the rotation stage and read back powers. When the laser enable (H1:AWC-ITMY_LASER_ENABLE) was off, the laser could not be turned on. 

FAMIShttps://ligolab.famis360.com/LB_Request_UpdateElevate.asp?InstallID=2&RequestID=85076

Noise is looking slightly better in a few spots compared to last week's check, but nothing really worth looking further into.

Crossover from the CEBEX alog: these images, taken today by Bubba Gateley, are of the current state of facility construction, featuring the building from the east and west sides.

• Initial alignment
  • ALSY alignment was very finiky this morning. I ran a scan alignment which brought the power up to 0.8. Then when I went to improve by hand, it seemed like there was no combination of ETMY and TMSY that would increase the power past 0.8 and make the pitch on the camera better. I moved ITMY around a bit, which didn't seem to help at first, but then after going back to ETMY and TMSY again, suddenly a small change in TMSY made the power jump up to 1.0. I then touched up yaw and tried locking, but it didn't want to stay locked. I made one more minor (2 clicks) change in ETMY Y and then it stayed locked after a few tries.
  • COMM and DIFF beatnotes at -3 and -9 at this point 
  • After input align the IMC lost lock as usual, then 1.5 min later the JAC lost lock and didn't relock for minutes until I brought it's guardian to Down and then back to Locked. The IMC still took another 5 minutes to lock.
  • No issues with PRC, MICH dark, SR2. SRY I had to move SRM in pitch ~40-50urads to lock.
• Locking locking
  • SRC1 & 2 P are still off, so I stopped at Engage_DRMI_ASC and touched up SRM P before moving on.
  • Lost lock at Start_TR_CARM
  • Handing off to commissioners

TITLE: 10/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.26 μm/s 
QUICK SUMMARY: Environment is calm, no alarms other than an old VAC instrument air PT599. Temps look good, CDS looks good. 

Starting initial alignment, more commissioning today.

Summary: The QOSEM LED feedback loop is working, as it can be seen reducing noise of the raw QPD difference channels. Despite this, we still can't get down to the expected shot noise limit for the QOSEM readout, for reasons that are still not clear. Further modeling of this feedback loop and readout scheme are underway.

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466. 

During a period of time with the BBSS M1 damping loops off (see LHO:92011), the QOSEM LED feedback circuit was switched on and off at the sat amp, to further investigate the LED behavior, which is the leading suspicion for the excess noise. In short, the LED feedback circuit takes the sum channel from each QOSEM, and uses this as an error signal to control the LED current. The idea being this suppresses the intensity noise on the LED. 

In Figure 1, we plot the 6D motion of the BBSS M1, as measured by the QOSEMs. Here we see that the state of the LED feedback being on or off has no noticeable effect on the noisefloor. Likewise the damping being on and off has no effect on the noisefloor observed,

In Figure 2, we plot the OSEM basis motion of the BBSS M1, as measured by the QOSEMs. Here we see the state of the LED feedback has some effect on the F1 and RT QOSEM, just in there y axis. This was not observed in the figure 1 6D Euler basis plot, as this is formed by combining many QOSEM measurements in the OSEM2EUL matrix conversion, which obscured things if only a channel or two are off.

In Figure 3, we plot raw voltage spectrums from the QOSEMs from the same datasets as figure 1&2, showing the raw QPD Sum, XDiff and YDiff signals. Here we see a few interesting things:

• Looking at the sum channels the feedback loop is certainly doing something, as we see the sum channel go from about 1uV/rtHz with no feedback, then suppressed down to the ADC noise level, as one would expect from an in loop signal.
• The XDiff channel does not change significantly with feedback on or off
• The YDiff channel does drop significantly when the feedback is switched on
• The sum channel for F1 and RT is not included as these channels were saturated at some points on the ADC

In Figure 4, we plot the DC position of the QOSEM flag, against how much the noise on the QPD difference channels reduced when switching the LED feedback off to on. We see an interesting correlation, that as the offset increases, so too does the amount of suppression provided by LED feedback. This is actually expected; when the QOSEM flag is far from centered, the common mode rejection of the QPD difference channel reduces (See slide 52 of G2500799), making it more susceptible to LED intensity noise. So when the QOSEM is far from centered, the LED feedback is seemingly doing it job, and suppressing the LED noise such that the difference channel is less noisy, and when the QOSEM is relatively centered, the LED feedback has no effect, as the good common mode rejection in this regime is already suppressing the LED noise.

While I'm still thinking over what this all means, the take aways are, the LED feedback loop is definitely doing something, as its helping the QOSEM difference channels which are far from center be less influenced be LED noise. However, this isn't actually having a huge impact on the QOSEM readouts, as the normalization we do in the readout scheme (dividing the difference channels by the sum), seems to be getting rid of this LED noise anyway, even if the feedback loop isn't active. The question remains though, why can't we push below this limit we are seeing, why are the sum normalization steps and the LED feedback not allowing us to be anymore sensitive at 10Hz. I am going to try run some models to predict the LED noise coupling through the circuity and readout chain, and I think measuring the coherence between the QPD Sum + Diff channels to the LED drive current at the sites will be useful. 

Summary: With BBSS M1 Damping off, there is no coherence between the QOSEM readouts and coil drive monitors, ruling out DAC or CD noise as the excess noise culprit, which agrees with the noise budgeting. 

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466. 

We recently switched the BBSS M1 damping loops off such that coherence measurements could be taken between the coil drive monitors and the QOSEMs readouts. This damping off time is summarized here LHO:92011.

Figure 1 plots the spectra of the QOSEM readouts (in the OSEM basis), alongside that of the coil monitors, projected into M1 motion in OSEM basis. We also plot the coherence between the QOSEM readouts and the coil monitors. During this time period the QOSEM sum feedback was on. Note that the coil monitors are AC coupled and not useful below ~10Hz.

We see that there is no virtually coherence between the coils and QOSEM readouts, which is unsurprising as the coil monitors appear to be sitting at the ADC noisefloor. However they appear to still be sensitive enough to rule out DAC or CD noise as the cause of excess noise, as predicted by the noise budgets done in LHO:91871. 

Camilla, Sophie

We reprofiled the QCL unit 0970 because we were concerned the SNR was too low and effecting the profile of the beam (see alog 92242). The 99:1 BS placed in front of the QCL was replaced by the CO2 99:1 BS which at 4.6um acted effectively as a 70:30, with the 30% beam transmitted. We profiled the 30% beam at 1A and 25C over a 50cm range. 
The strange beamsize fluctuations around the waist were observed again so we concluded this was a not a measurement error and slightly non-gaussian behaviour of the beam.
The complex q parameter for the laser was found using a non linear fit to be:

--- Horizontal (A1) Fit ---

Data range: z = [97.0, 597.0] mm
Beam radii: [422.0, 1412.3] µm
Fit converged: w₀=411.4+/-9.2 µm, z₀=224.9+/-3.9 mm
q = -225+/-4 + 116+/-5i mm

--- Vertical (A2) Fit ---

Data range: z = [97.0, 597.0] mm
Beam radii: [413.6, 1183.7] µm
Fit converged: w₀=421.0+/-10.9 µm, z₀=293.7+/-3.9 mm
q = -294+/-4 + 121+/-6i mm
Note: Louis pointed out the plots of the fit have weird error bars which I will investigate in the QCL fitting code. 

The measured q-parameter is very similar to the Y-arm unit and a very similar telescope optimisation could be completed. This layout is listed in the git and has the following beamsize and astigmatisms. 

Beamsize at ITM
wx_ITM: 53.299 mm
wy_ITM: 52.042 mm
w_ITM_mean: 52.671 mm
w_ITM_astig: 1.257 mm

This is an improvement in astigmatism of approximately 7mm from the 0922 unit we swapped out.

We are currently aligning the table and the beam is aligned up to the PDBS. Unfortunately, many of the other optics had to move to ensure the PD intensity noise measurement optics would not be positioned in the waist so they do not get burnt.

During the latter part of the day, Louis and I tried to get back to resonance, but have yet to get there. First, we had problems with TR carm (again), and then we struggled at the carm offset reduction.

For TR CARM, we thought the gain might be a bit low in start_tr_carm, so we upped the analog H1:LSC-REFL_SUM_A_IN1GAIN by 3 dB. This seems to help! Louis also increased the time in the servo to 10 seconds.

CARM_OFFSET_REDUCTION problems:

• We ran carm offset reduction and failed. We tried stepping up slowly in the offset and adjusting the gain, but kept losing lock. We found we can step to -35 offset and a gain of 60, and then up to -40 and a gain of 61. This is 3 dB lower than the original final gain of 86, which makes sense based on our gain increase in TR carm.
  • Even though this is guardianized, this still seems to fail unless done by hand. I don't know why because the guardian code should be exactly replicating what I do by hand: step to -7, wait, step to -12, wait, engage darm boost, step to -35 and 60 gain, wait, step to -40 and 61 gain, engage reflbias boost
• I have tried stepping the alignment around to see if I can make the recycling gain better.
  • Looking at the transmitted powers both yesterday and today, I am concerned that the refl power is too low and that we have poor recycling gain.
  • In O4c, I measured arm transmission and refl ratios to see if our carm offset reduction sequence was having a problem, see here. Turns out we were fine at the time. But we can compare those powers to now, reminder we had recycling gain of about 54.
  • For arm transmission of 800, the refl power should be about 1.96 mW, compared to 3.7 mW off resonance, so a ratio of 0.52.
  • Tonight, for a transmitted power of 800, refl power is 1.3 mW compared to 3.5 mW off resonance, so a ratio of 0.37. We saw similar powers last night, although we were able to make it all the way to resonance. This is still in the region of a gain of 30, but that does seem low compared to a year ago.
  • I tried stepping the DHARD alignment around, but it did not improve the refl power. CHARD alignment seems to help, but it's a small improvement. Since the improvement is so small when the transmitted power is low, I think I stepped the wrong way and caused a lockloss by reducing the carm offset with very low recycling gain.
• I tried one more time to walk CHARD around, looked like I was going in the right direction, but we still lost lock.

We had one lockloss at carm 5 pm after completing carm_offset_reduction by hand. Don't know why, but this was another state we sometimes had to carefully do by hand.

Want to reiterate that the IMC is still being fussy when relocking.

TITLE: 10/10 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is in at DARM_TO_RF

Elenna and Louis worked hard to get past IDLE_ALS, whioch is the state right before we lose lock. The current hypothesis is that the PR_Gain ramp up is wrong so they've been measuring and then stepping up the gain (more negative) slowly to see what is enough.

It turned out that the arm alignment was bad, and we successfully got past DHARD_WFS. Though the problem is still happening so Elenna is troubleshooting.

We've relocked fully automatically with DRMI over 10 times. 

LOG:

TJ, Jim, Arnaud

Implemented a new HAM3_CRS guardian. The purpose of this guardian is to :

1) monitor the state of the CRS on HAM3 (Laser status, 25mHz tilt amplitude, and readout noise (3_10Hz)
2) adjust the damping gain depending on the tilt amplitude, and
3) take it to "SAFE" (Damping OFF) when maintenance is necessary 

This morning, we tested the condition for a rung up CRS, see attached screenshot. The CRS was manually rung up, and we let the guardian take over. After the 1urad rms threshold was reached, guardian jumped to CRS_RUNG_UP state, changed the damping gain to 1 (from nominal 0.01), and went back to CRS_GOOD after the RMS threshold came back under threshold. The earthquake that happened later today also triggered the CRS_RUNG_UP state as expected, see second plot from this alog

Guardian logic description is written under: T2600479

TITLE: 10/09 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: 

We are back to trying to relock after the big earthquake earlier today.

Locking notes:
Morning Initial Alignment
- Had to help XARM because it kept catching on wrong mode, but probably would've caught on its own eventually

Relocking
- Kept losing DRMI, mostly due to mode hopping - this was because the green arm references hadn't been sdf'd. After resetting the refs to what they were yesterday we were good
- Huge 7.6 earthquake come through and kept us down for multiple hours. It was in the BIG RED BUTTON zone, so I pressed the Big Red Button™.

LOG:                                                                                                                                                                                                                                                                                                                                 

TITLE: 10/09 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 17mph Gusts, 12mph 3min avg
    Primary useism: 0.12 μm/s
    Secondary useism: 0.17 μm/s 
QUICK SUMMARY:

IFO is back to locking after Panam M7.7 (and 6.6 aftershock).

We're getting to DRMI.

Oli, TJ, Arnaud

We used the earthquake down time opportunity to evaluate safe IMC thresholds for a rung up, in loop CRS. A threshold of 1urad rms at 25mHz seems safe for alerting the seismic nodes to take the CRS out of loop. We will have to verify those thresholds are not too conservative, and that they still work with a full ifo. 

For this test :

HAM2-HAM3 were set to their nominal blends (no sensor correction), and the CRS was put in loop for HAM3. The CRS was rung up to 80 urad pp, 28 urad rms, by flipping the sign of the CRS damping gain. We monitored the IMC stayed locked throughout (fig1). The mode cleaner controls (on MC2) reached at most +/- 50e6 out of the +/- 134e6 limit (less than half the total dac range). In comparison, the Panama earthquake from this afternoon (or the change of ISI state) rung up the CRS to +/- 2.2 urad, 1.5 urad rms (fig2). 

Louis and I started morning locking once Oli re-re-ran initial alignments with the "correct" green camera offsets (ones set by the baffle scripts).

We got to DRMI ASC, and the SRC P error signals looked close to zero, so I tried engaging SRC1 and SRC2 P. However, we saw slow large oscillations that went away when the SRC P loops were turned off. I also saw that the alignment wasn't brought to the best buildups- I had to move SRM pitch more to maximize. I also reset the POP A offsets (SDF attached), which is a minor change but we have the best buildup now (ignoring the >200 buildup from last Friday)- POP18 is 167 and POP90 is 20. As an aside, I think we need to pico onto the POP QPD sled. The POP A offset required is very large, about 0.98 in both pitch and yaw. We're probably close to or falling off of POP A and the same is true for POP B. Perhaps we can lock DRMI, close PRC1 with the current offsets, let it converge, open the loop, turn off the offsets, and pico to bring the beam closer to the center of the QPDs.

I have now created separate "use DRMI ASC" flags for SRC1 and SRC2 pitch and yaw. The yaw flags are set to TRUE, and the pitch are set to FALSE. The ISC_DRMI guardian will now separately engage these loops in ENGAGE_DRMI_ASC. This means that only SRM and maybe SR2 pitch will need to be hand-adjusted for buildups in DRMI ASC. Tagging opsinfo.

Louis and I tried to go through TR CARM four times:

• Try #1: tried running straight through carm to TR, lockloss
• Try #2: went to start TR carm, saw that the REFL_DC_BIAS output signal had an offset. Tried adjusting the TR CARM offset to remove the offset. Had to lower it to -0.3. REFL DC BIAS was around zero. Tried measuring TR CARM using the template, had no coherence, bumped up the template excitation by factor of 100. Measurement showed low TR carm loop gain, by roughly a factor of 3. Tried raising the REFL DC BIAS gain from 6 to 12, lockloss. See attached "TR carm fail 2" for measurement.
• Try #3: Decided maybe we railed the input to the common mode board on last try, decided to raise the analog gain instead. Went up 3 dB, remeasured. TR carm gain looked better, but still low. Went up 1 more dB step. Immediate lockloss. See attached "tr carm fail 3" for measurement.
• Try #4: Oli alerted us to an incoming earthquake from Panama, big enough for big red button. Oli spoke to Jim, was advised to press big red button asap. No chance to try carm on tr.

We're holding in down while this large earthquake passes.

I want to re-emphasize that we are still having trouble relocking the IMC after lockloss. The IMC will acquire lock, and the boost will kill it. This can get intense enough that the boost kicks the FSS which then kicks JAC. The only way around it is to either wait a really long time, or to hold the IMC guardian in acquire, wait a minute, and then engage boost. Doesn't always work, but can be faster than just waiting forever. Tagging IOO, someone needs to look into this boost.