Sheila, Jenne, TJ, Ryan, Keita, Jennie W

Today we had trouble locking from the start of the commissioning period. This seems to have been a problem with OMC locking - see Ryan's log for further details.

We scanned the OMC in single bounce anmd everything seemed to look ok.

We managed to power up but then eventually lost lock after Sheila measured LSC FF and Robert took some photos at viewports.

Alena had suggested a better spot we could be aligned to on the OFI (second column on second last page), so since we have been having locking problems since maintenance on Tuesday we decided to unlock and try this move.

The best spot suggested is so far off that we know we will have to use the HAM6 picomotors to recentre the beam on the AS_A, AS_B and AS_C QPDs.

TJ and Jenne slowly brought us to this new spot (between two t cursors in this image) while also using picomotors 2X, 3X, 3Y, 1X to keep us centred on AS_A, AS_B and AS_C. During this time we were also trying to run the DC centering loops on OM1 and 2 to keep us centred on AS_A and AS_B, unfortunately we then ended up in a situation where we were saturating OM1, 2 and 3 and OMC suspensions at different points. Turning off the DC centering loops relieved OM1 and 2.

We couldn't get past PREP_DC_READOUT_TRANSITION.

Before doing this, at 22:50 UTC Sheila and I measured the spot positions on the SRM and SR2 mirrors using the A2L gains.

Sheila tried to releive the OMC and OM3 suspensions using their sliders but eventually we realised that we might have to do a combo of this with more pico-motoring to lock the OMC and power up.

This is shown in this image, however, these efforts eventually unlocked us.

Here is another ndscope showing the full days efforts with the ISC_LOCK guardian state also.

Andrei, Naoki, Sheila

Following the research of aLOG 78125 and aLOG 78262, we aimed to quantify the value of backscattering from the ZM2 and ZM5. We performed backscattering measurements under the assumption that modulation of the optical path between scatterer and interferometer would introduce additional noise in the DCPD spectrum [1-4].

We used data from the H1:OMC-DCPD_SUM_OUT_DQ channel (calibrated to mA of photocurrent) for the times of aLOG 78125. We've then calculated RIN with correction for the DARM control loop. Using Eq. 25 from [1], we performed manual fit. Although we couldn’t perfectly fit within the range from 15 Hz to 21 Hz (probably because of the chosen Welch's transform parameters), we were still able to obtain meaningful results for the backscattering coefficients (see Fig. Backscattering_meas.png). The resulting coefficients are below:

r_ZM5 ≈ 4 x 10^-4

r_ZM2 ≈ 0.1 x 10^-4

Also note, that the amplitude of the excitation used for fit is several times larger than that we've measured from the H1:SUS-ZM#_M1_DAMP_L_INMON channel (1.2 μm unstead of 0.4 μm).

Code that was used for this calculation is attached to this report. OM1_fringewrapping_test.m (Sheila's code) was used to calculate RIN, main.nb was used for manual fit and plotting.

[1] Martynov, D. V., Hall, E. D., Abbott, B. P., Abbott, R., Abbott, T. D., Adams, C., ... & McIver, J. (2016). The sensitivity of the Advanced LIGO detectors at the beginning of gravitational wave astronomy. Physical Review D, 93(11), 112004.

[2] Ottaway, D. J., Fritschel, P., & Waldman, S. J. (2012). Impact of upconverted scattered light on advanced interferometric gravitational wave detectors. Optics express, 20(8), 8329-8336.

[3] Nguyen, P., Schofield, R. M. S., Effler, A., Austin, C., Adya, V., Ball, M., ... & Moreno, G. (2021). Environmental noise in advanced LIGO detectors. Classical and Quantum Gravity, 38(14), 145001.

[4] Fricke, T. T. (2011). Homodyne detection for laser-interferometric gravitational wave detectors. Louisiana State University and Agricultural & Mechanical College. 

On Tuesday, I tried running the HAM7 high voltage CPS electronics again. This time I was able to get all 6 sensors to the noise floor I expected. I replace another ethernet cable and one of the in-air triax cables, and I had to use one of the test cards the RichM used at MIT to get there though. After that I was able to turn the isolation loops on let the ISI run for a while when we were trying to lock. My initial measurement looked like the low frequency isolation was pretty bad, so I reverted to the old electronics that afternoon. 

Attached first 3 images compare the performance with the high voltage cps (refs) and the nominal cps (live traces). The high frequency performance is not really any better, and in RX and Y the below .3hz performance seems much worse. Z seems to be worse pretty much everywhere below 10hz. Maybe one of these sensors has a funny calibration or something? I will probably try again next week and see if I can measure that with some ISI tfs.

Fourth image is calibrated spectra for each individual hv cps. The H1 still had a high noise floor for this test. Another thing to try to fix next time.

Robert noticed that we have been set to the incorrect R0 offsets for ITMY for the last 36 days. I've saved what they should be in SDF so they will not be reverted.

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Since my midshift report (alog78281), efforts have been focused on trying to find optimal alignment into the OMC with this new spot position in the OFI. Work on this is ongoing, with the current plan being to use picomotors to adjust the pointing onto PDs in HAM6 to then give more range with OM mirrors to direct light into the OMC.
LOG:

Jennie W, Sheila

After our picoing efforts, at 22:50 UTC today Sheila and I measured the A2L gains of the SRM and SR2.

Sheila notched 31 Hz out of the SRCL control loop and I injected a line at this frequency first at SUS-SRM_M3_LOCK_P_EXC, then SUS-SRM_M3_LOCK_Y_EXC.

Sheila changed the A2L gains for the corresponding degree of freedom so that the line height was minimised in SRCL_IN1 and in DARM using the channels H1:SUS-SRM_M3_DRIVEALIGN_P2L_GAIN and H1:SUS-SRM_M3_DRIVEALIGN_Y2L_GAIN.

SRM spot position:

P2L -1 with precision of 1

Y2L 6 with a precision of 0.5

(not too sure of the precisions as I lost my alog halfway through (d'oh).

We then did the same thing for SR2 by injecting in the M3_LOCK P and Y channels and changing the DRIVE ALIGN gains for SR2.

SR2 spot position was

Y2L 1.5 with precisioon of 0.25

P2L is 8 with precision of 1

The templates for these measurements are in: /ligo/home/jennifer.wright/Templates/Measure_spot_size_SR2.xml and Measure_spot_size_SRM.xml

TITLE: 06/06 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.22 μm/s
QUICK SUMMARY:

IFO is at PREP_DC_READOUT_TRANSITION and is staying there for comissioning.

Comissioners are testing out alignment configurations with respect to the OFI spot trials

At the start of commissioning today, before we got to NLN and were having trouble locking the OMC, I took an OMC mode scan when we were locked at 10W.

We manually move the OMC_PZT2_OFFSET to its lowest slider value then run the template which does two 100s ramps of this PZT.

Posting for posterity.

Time of Scan = 15:23:43 UTC

200s length. See template in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_06_06_OMC_Scan_15-23UTC.xml

Today has so far been busy with commissioning time, mostly in the effort of moving to a new spot on the OFI. We were able to get locked to NLN this morning after diagnosing the OMC locking issue (see alog78275), then after some commissioning tests, we purposefully unlocked the IFO to start the process of moving the OFI spot in single-bounce configuration.

As of about 20 minutes ago, we've successfully completed an initial alignment after finding the new spot (where SRM needed to move a LOT) and are locking, no issues so far up to ENGAGE_ASC.

FAMIS25994

I didn't notice any higher frequency noise that was appreciably elevated.

Jenne D,  Jennie W

Jenne noticed that our AS_A_YAW offset was on in the current state (PREP_FOR_LOCKING). We don't want this offset on currently as we are moving to a different spot on the OFI for which we need the picomotors, therefore we my need to rethink AS_A and B alignment offsets.

We turned this offset and the other AS_A and AS_B oiffsets off.

This is the only one I could find set in the ISC_LOCK guardian so I commented this line out.

        elif self.counter==9 and self.timer['LoopShapeRamp']:
            #ezca['ASC-AS_A_DC_YAW_OFFSET'] = -0.15 J Wright commented this out on 6th June 2024.
            ezca.switch('ASC-AS_A_DC_YAW', 'OFFSET', 'ON')

I reloaded the ISC_LOCK guardian.

Thu Jun 06 10:09:03 2024 INFO: Fill completed in 9min 0secs

Gerardo confirmed a good fill curbside.

P. Baxi , J. Kissel 

Finished characterizing (Channels 1 to 4) of the new 524KHz Analog OMC Anti-Alias Chassis - S2300162

• Bode plot for the system include the Transfer function and Phase of each individual Channels (1 to 4) and their (Channel 2 to 4) respective ratio with Channel 1 for comparision. The system was characterised from Start Frequency of 1KHz to a Stop Frequency of 102.4KHz with 100 steps.

                       BodePlot_Channel_1_4_freq_start_102.4KHz_Freq_stop_1KHz_Steps_100.pdf  (raw data - available in DCC S2300162)

              - We see the frequency response has minimal phase impact in the gravitational wave band, with deg of phase loss at 1000 Hz.

• Noise Measurements for Channels 1 to 4 with reference to the noise of SR785 is shown in the plots below. To achieve the maximum frequency range we incorporate and merge three frequency spans: 4Hz to 3.2 KHz, 32 Hz to 25.6 KHz, and 128Hz to 102.4KHz.

                       ASD_SR785_Channel_1_4_Freq_span_4to32K_32to256K_128to1024K.pdf  (raw data - available in DCC S2300162)

              - We see the noise of each of these 4 representative ADC channels is around ~20 nV/rtHz

• Python scripts to regenrate the plots. (Bode plot and ASD plots) 
• Measurement notes to reproduce the above raw data.  (Bode plot and ASD plots) 

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY: H1 has been unlocked since 10:21 UTC this morning. It's been able to relock up to PREP_DC_READOUT_TRANSITION, but the OMC is not locked; OMC_LOCK is stuck in the SET_WHITENING state with a notification reading "DCPD gains not equal after whitening switch -- yikes!" (I've not seen this before; will start troubleshooting)

• Wind is low
• Microseism is trending downwards

Ibrahim, Ryan S, Jenne, Sheila, TJ

TITLE: 06/06 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

IFO is in NLN and OBSERVING (after a 24 hour outage) as of 07:59 UTC (cutting it real close H1...)

For the majority of the shift, I was unable to lock - here’s why:

1. DARM_OFFSET: 

   • Issue: IFO loses lock at DARM offset at which point PR Gain oscillates very vigorously and plummets. If we can manually turn the offset off in time, it recovers and we don’t lose lock.
   • Fix: ASC Loops were not fully converged at the time of the PRG plummet and so we moved the states around (Ryan S, Jenne, Ibrahim) and put ENGAGE_SOFT_LOOPS and ASC states before DARM_OFFSET, which seemed to have fix the issue owing to the less noisy IFO. However, this means that the OMC locks sequentially instead of simultaneously, adding time to lock
   • Cause: Largely unknown but seemingly related to an alignment issue that Jenne thinks has to do with ASC Yaw.
   • Other Troubleshooting/Relevant Alogs: We have seen that DHARD_Y gets spiky and oscillates in the seconds leading up to SRC1_Y and SRC2_Y engaging right before the lockloss. Alog 78251, Alog 78258, Alog 78259, Alog 78265, Alog 78267

2. ACQUIRE_DRMI_1F:

   • Issue: IFO loses lock here due to very poor pop19 and pop90 flashes, not even making it past PRMI or MICH_FRINGES at times. 
   • Fix: Turning on an 0.6 Offset in SRC1_Y seems to help get past this state but interestingly, this was not required during the last lock attempt post-initial alignment so maybe just initial alignment?
   • Cause: Unknown but thought to be due to more SRC alignment issues.
   • Other Troubleshooting/Relevant Alogs: Alog 78267, Alog 78265

3. LOCKING_ARMS_GREEN: 

   • Issue: IFO cannot lock green arms for longer than 5 minutes. ALSX is the problem here, where it gets extremely fuzzy and oscillates with a huge amplitude (between 1.2 and 0.8 on its scale). The fuzziness is indicative of a weird comb interference. During this time, it usually loses lock but in the times that it doesn’t, TRX degrades slowly and randomly and then recovers slightly. While this is happening, PLL and PDH fault alarms go up and the state prompts me to “check crystal frequency”
   • Fix: With Jenne, we went into the ALSX Crystal Polarization screen and found that the number was 15 when it is usually supposed to be below 9. Playing with it manually, we were able to get it to 11 by playing with the sliders, which allowed us to get past ALS. I don’t know if this mattered though because after our most recent initial alignment, the value read: 9.
   • Cause: Unknown
   • Other Troubleshooting/Relevant Alogs: None

4. VIOLINS:

   • Issue: Violins are extremely high, to the point that the primary is occulted by the DARM legend on Nuc30
   • Fix: Damp them violins.
   • Cause: All the above, though it’s interesting that they maintained their magnitude despite initial alignments and hours of non-movement during non-violin exciting periods.
   • Other Troubleshooting/Relevant Alogs: There was a lockloss when violins got sufficiently damp to go to OMC_WHITENING but when there is no wind, there is still pain - and we lost lock minutes before that happened.

On top of these, we have also had a few totally spontaneous lock losses which do not have tracks as egregious as the three above. Moreover, running INITIAL_ALIGNMENT seems to randomize what issue I face in that I either will be acquainted with a totally new problem or face no problems.

A summary of controls moved (with permission):

• PRM
• PR2
• SRM
• SR2
• SR3 (don’t panic - moving it back to nominal after it got moved earlier)
• SRC1_Y Offset
• DARM1 Offset
• ALSX Polarization Frequency

SDF Diffs Attached (All Seismic Related)

LOG:

None

IFO is still LOCKING (I know)

While violins were damping to turn on whitening (pretty steadily too), we lost lock unexpectedly. DRMI could not lock - PRMI could not lock and MICH Fringes could not lock PRMI. So now I'm doing an initial alignment.

Jennie W, Jenne D, Sheila

The other day I designed a new notch to get rid of a bump we had been seeing at 17.75Hz. We think this is the bounce mode of the BS coupling into the MICH loop. The notch for this in LSC-MICH has not been updated since the BRDs were installed I think, and there is no notch for this mode in the ASC-MICH_P and ASC_MICH_Y loops.

Changes made to ISC_DRMI.py

Added Bounce-roll notch (FM8) to MICH2 (line 457) in DRMI_LOCKED state and took out line turning on notch at 15Hz (line 456).

#ezca.get_LIGOFilter('LSC-MICH2').switch_on('FM10') # Turn on the BounceRoll FM10 in LSC FM

ezca.get_LIGOFilter('LSC-MICH2').switch_on('FM8') # Turn on the BounceRoll FM8 in LSC FM 05/06/2024 J Wright

Added bounce-roll notch to PREP_PRMI_ASC in FM MICH_P and MICH_Y in FM9. These were added to lines 690 and 692.

Added these same filters in PREP_DRMI_ASC state in FM MICH_P and MICH_Y in FM9 in lines 920 and 922.

With the difficulties locking, I tried changing some of the CPS diff filters to get the end station ISI to follow the corner ISI. The CPS diff uses a band pass filter to reduce the differential motion between the ISI, but this filter can inject motion at the microseism. Microseism is low, I'm guessing the arms are struggling more with the below .1hz motion. In the attached image the filters we had been using, are the red trace, blue is what I switched to. It kind of seemed to help, but I think we lost lock after I left the room. I'll leave this running for now, going to try a couple other things.