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.

Attaching a set of slides summarizing the on-going efforts to reproduce the beam path from SR3 through the OFI. Two sets of the beam spot position measurement on SR2 and SR3 were used to "calibrate" the slider moves and to simulate the beam position for other alignment configurations using Zemax. The slides are posted to the dcc https://dcc.ligo.org/E2400189-x0
The aLogs with the beam spot position measurements:
beam spot 1 measurement  aLog77443 
beam spot 2 measurement aLog78119

[Jenne, Sheila, Jennie, RyanS, Ibrahim]

The interferometer has remained fussy all day.  I suspect we may have some alignment issue somewhere, since the AS_AIR camera looks a little bit lobe-y and wrong in yaw.  Twice now, if we've gotten past the DARM_OFFSET state and convinced the OMC to lock (which it will do with the autolocker once the darm offset is at the full value of 9e-5), we're able to at least start powering up. 

• One time, as RyanS mentioned, we succeeded by slowly stepping the DARM offset up to the value of 9e-5, after all ASC for full IFO (Including SOFT) loops had converged. I'm not sure why we lost lock on this one, but it's possible that we're more sensitive to motion on the LVEA floor, and Robert was out taking photos.
• One time, that wasn't enough, and we were more successful with an offset of +0.6 in place in the SRC1 yaw loop both during DRMI ASC and re-engaging it during full IFO ASC.  This current lock, with that technique, once the OMC was locked I slowly set that offset back to its nominal value of zero, and we're powering up okay.  More specifics on what I did:
  • With the ISC_LOCK at CHECK_DRMI_ASC, I turned on an offset of +0.6 in SRC1 yaw.  I then let the ASC converge and set ISC_LOCK to PREP_ASC_FOR_FULL_IFO, which turned off the offset (during a time when SRC1 was not engaged).
  • I set ISC_LOCK to ENGAGE_ASC_FOR_FULL_IFO, and it was clear that the alignment was getting a bit worse with the SRC1 yaw offset off, so I re-turned it on again to +0.6. 
  • I set ISC_LOCK to PREP_DC_READOUT_TRANSITION, and the OMC was able to lock, we didn't lose lots of PRG, everything seemed overall fine.
  • I ramped the SRC1Y offset back to 0, and then requested NomLowNoise.  The alignment definitely saw the move, but it didn't seem terribly dramatic, so it seems fine.
• I am hopeful that this was a fluke, and we don't need to actually have a SRC1 yaw offset.

My hypothesis of why we might be needing this alignment offset, is that increasing the DARM offset is letting more carrier light go to the AS port, and the the AS WFS loops are seeing that and responding poorly.  So, this alignment offset helps kepe them in the right spot.  That's not a very satisfying story though.

Earlier, I had tried moving SR3 by +/- 1urad on the slider in yaw (reverting afterward to the previous slider val), but that didn't really help.  I also tried offsets in AS_C and AS_A pointing, but neither of those had the same improvement in the AS camera or POP90.  They would improve momentarily, but after the rest of the ASC caught up, we still had the lobe-y look on the AS camera.

Jennie also noted earlier (and it happened at least both of these last two power ups) that we're saturating the OMC suspension when we power up (before moving spots).  But, after all the ASCs catch up, it's no longer saturated.  So, we're close to the edge of what the OMC suspension can do, but it seems surviveable.

Attached are screenshots at CHECK_DRMI_ASC of the AS air camera, without and then with my hokey offset of 0.6 in SRC1 yaw.  You can see that with the offset in place, the camera image is much more centered and nice looking.

For posterity, here are the mattermost versions of the notes, starting with this message:

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.

Wind was brutal today, so I was messing with the controls on the BSCs to try to help. Mostly just running RX/RY sensor correction from St1 to St2 on the BSCs. Sensor correction is focused on improving the ~.4hz motion and doesn't really affect the motion outside that. I don't think this really helped, winds calmed down after I left at 5:30 and Ryan is almost all the way NLN now, so I will leave the extra sensor correction running for tonight. I'll accept SDFs for tonight, then turn it back of during maintenance tomorrow.

Wind and lock losses make a comparison challenging, but the blrms trends show the (log scale) improvement ETMY sees when it's turned on over .3-1hz. Top trace is the St2 RX GS13 blrms, middle trace is the gain for the sensor correction, sc is on when it's 1, off at 0. Bottom trace are the .3-1hz ground blrms. For the las 3-ish hours the St2 RX motion is lower with the sensor correction on even when the ground is moving more in this frequency band.

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.