A new VCO for the CLF was installed. This VCO has a higher modulation bandwidth compared to the previous VCXO at the cost of more low frequency phase noise.

The SSB phase noise according to the data sheets:

Lights turned off. 

Noting but left alone as commissioning work is still ongoing :

• W-bay  - Faro plugged in
• W-bay  - Geine lift charging
• W-bay  -  extension cords still on y-concrete slab
• SQZ-bay electronics plugged in, oscilloscope, laptop on
• Mechanical room/ cable bridge noisier than usual 
• Wifi on
• Paging system plugged in 

Cabling on the HAM5 D3 flange was redressed. Cables routed behind the cross beam. This required cables for the HAM5 DCPD and the OFI TEC/THERMISTORS to be disconnected. D. Sigg disabled the servo for the OFI TEC. Servo enabled after cable work was completed.

A few days ago Jenne mentioned that our IM4 Trans NSUM diode was reading lower than before, because it was badly pitched down on the QPD.
IM4 TRANS is used as our PRG calculator, so we would like make sure it's a trustworthy readback of our input power.

This morning I adjusted IM1, IM2, and IM3 such that the alignment onto IM4 Trans is repaired.
This brought the IM4 Trans NSUM estimated power incident on PRM from 1.8 to 1.9 W.

We are now back to similar levels on IM4 TRANS / IMC PWR IN we were at at the beginning of the run:
Current IM4 TRANS / IMC PWR IN ratio = 0.96
Ratio on August 8, 2023 = 0.95

I was never able to find an alignment which 
1) maximized our detected power and
2) properly brought our YAW on IM4 TRANS back to zero.  
Right now, IM4 TRANS YAW is sitting at 0.4.

Because of max power/YAW discrepancy, I walked significantly in a bunch of directions (IM1 + IM3, IM2 + IM3) to check for clipping on the IFI or the post IM4 path.
I did not find anything obvious, so I suspect we are okay where we sit.
Still, we should be prepared to have to massively adjust the input alignment using IM4 when locking later today.
If we need to, we can revert to the IM alignments from 8 am this morning, and simply pico on the IM4 TRANS path like we did in alog 64446.


alogs:
August 2022 Picoing onto IM4 Trans alog 64446
July 2022 IM4 TRANS calibration alog 63812


EDIT: After this, because we were more worried about locking, I restored the sliders to their original locations, then further restored all of the IMs OSEMs to close to their original locations from before the vent.  
Somehow, we are still falling off IM4 TRANS.
Additionally, Daniel advised to look at the ISS QPD, seems like we are not falling off that one yet, but are significantly yawed, not pitched.  
I believe that this actually makes sense, and that ISS QPD was 90 degrees rotated compared to the other QPDs.
I'm now in the process of checking the IMC OSEMs.

EDIT 2:  Mode cleaner OSEMs seem close to their original values from before the vent.  It's very hard to tell what changed about our input alignment, if the IMC and IMs OSEMs are at the same values.  
In any case, I've left it at the same slider values we had this morning, with the loose plan of slowly aligning IM4 TRANS during full lock with the input alignment loops on.

Tue Mar 12 10:15:18 2024 INFO: Fill completed in 15min 14secs

Gerardo confirmed a good fill curbside.

Today I updated the firmware of sw-fces-cds0 to match the other icx 7150 units.  Due to the age of the firmware it was a two step process which involved 2 restarts of the switch.

This was done completely remotely.  After the upgrade I reviewed the configuration, make some changes to update how the spanning-tree was done and recorded the config.  The first restart of the switch took about 3 1/2 minutes, the second tool about 5 1/4 minutes.  Adjusting the spanning tree took some minor outages while the spanning tree was re-discovered.

The command sequence for the upgrade was:

copy tftp system-manifest 10.20.0.85 fastiron_08080f/FI08080f_Manifest.txt all-images-primary
boot system flash pri
copy tftp system-manifest 10.20.0.85 fastiron_0895g/FI08095g_Manifest.txt primary
boot system flash pri
copy tftp system-manifest 10.20.0.85 fastiron_0895g/FI08095g_Manifest.txt secondary

TJ, Trent, Matt, Georgia, Craig

This morning we went to ISCT1 with the goal of touching up the ALS DIFF beat note (currently sitting at around -13dBm), and investigating the clipping on the ALS Y transmission path, since there visible clipping on the ALSY camera and low-ish transmitted power on ALS-C_TRY.

• Craig took ISC_LOCK to GREEN_ARMS_MANUAL and locked the Y arm
• The rest of us went to ISCT1 with a CDS laptop and monitored the beatnote and the Y arm transmission
• We tried aligning the steering mirror directly before the ALS_DIFF PD in case the beams were clipping, this did not increase the beat note
• We noted that the beams on the DIFF PD were not well overlapped (first photo) and wanted to touch up the alignment of the beamsplitter which splits the beam into the Y arm transmission and DIFF paths
• The Y arm came unlocked, either due to wind of sensor correction being turned off. The Y arm did not reacquire, so we took some photos on the table and headed out

Second and third attached photos show locations where we might be clipping.

Fourth and fifth attached photos show overviews of the ALS Y and Diff paths.

Sixth photo shows what the beam splitting prism looks like at the moment.

It appears that after a reboot of the h1guardian computer a week or so ago, the PEM_MAG_INJ node was requested to INJECTIONS_COMPLETE, meaning that at 14:20 UTC (07:20 PDT) this morning while H1 was locked at low noise, the injection suite ran for the following 20 minutes. This seems to have gone without issue, and the log lives in the normal injection directory, /ligo/www/www/exports/pem/WeeklyMagneticInjection/logs/

The magnetic injections do NOT appear to correspond with the lockloss at 14:45 UTC (the suite had finished 4-5 minutes prior). It's also worth noting that the in-lock SUS charge measurements did not run this morning, which would normally start at 07:45 local time, so that isn't the cause of the lockloss either.

I'll leave the magnetic injection suite set to run automatically on Tuesday mornings unless people have objections to it (it will not run unless the IFO is locked at low noise anyway).

Trent, Georgia, Craig

The table below gives the OMC finesse calculations for the different modes of the carrier field. These were caclulated with the code [/ligo/gitcommon/labutils/omc_scan/fit_peak_w_args.py]. When the code is run, it prints the finesse out to the terminal. The GPS time used for these caclulations was 1393542033 and the duration was 80sec.

This code could be improved becasuse the data finesse has the chance of miss identifying where the HWHM frequency is if there is a nearby peak. This was the case in carrier 50. We also need to add in the capability of including the q number as an argument to fit_peak_w_args.py so that we can compare the finesse for the same modes but seperated by an FSR.

The lower finesse as the mode increases is most likely due to the worse fit (the SNR is worse as the mode increases).

TITLE: 03/12 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: USEISM
    Wind: 19mph Gusts, 16mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.54 μm/s
QUICK SUMMARY:

Maintenence day today!

E. Hall, S. Pandey, S. Dwyer, L. Dartez

We took another look at the new DARM configuration this evening. Evan had a suggestion for a new test: move into NLN_ETMY, pause here before switching back to ETMX in the new configuration (but after all the new filters have been put into place) to take measurements of the new ETMX OLG before activating it. I took us into NLN_ETMY using the guardian then manually ran the instructions in NEW_DARM to set up the ETMX locking filters but paused before switching arms (so we were still locked with ETMY, notably without the MICH feedforward which remained inactive for the rest of our testing).

We measured H1:SUS-ETMX_L3_LOCK_L_IN1 / H1:SUS-ETMX_L3_LOCK_L_IN2 and H1:SUS-ETMY_L3_LOCK_L_IN1 / H1:SUS-ETMY_L3_LOCK_L_IN2 (DTT template paths are below) to isolate the OLG for the new DARM path on the x-arm. Some post-processing of the data is needed to do this. We'll follow up with that.


Finishing the Transition to the new state:
After the measurements above (but before we had a chance to look at the data) we tried slowly bringing up ETMX slowly starting with an L3 LOCK gain of 0.01 (and an ETMY L3 LOCK gain of 1). We immediately lost lock. This indicates that there is something severely wrong with the new DARM configuration as it's currently installed. Most likely, this is not something as subtle as an instability. We'll need to walk through these steps more carefully next time.


DTT Templates:
H1:SUS-ETMX_L3_LOCK_L_IN1 / H1:SUS-ETMX_L3_LOCK_L_IN2: /ligo/home/louis.dartez/projects/20240311_new_darm_investigations/SUSETMX_L3_SS_new_darm.xml
H1:SUS-ETMY_L3_LOCK_L_IN1 / H1:SUS-ETMY_L3_LOCK_L_IN2: /ligo/home/louis.dartez/projects/20240311_new_darm_investigations/SUSETMY_L3_SS_new_darm.xml

Relevant logs:
- Old Matlab model revived (LHO:75584)
- Unsuccessful attempts in early 2024 (LHO:75308)
- Times spent successfully in new DARM state (LHO:75631)
- Calibration attempts in new DARM state (LHO:74977)

Naoki, Nutsinee

Today SQZ_MANAGER failed to go inject freq independent squeezing multiple times. There were a couple of issues:

1) FC ASC engages when the Q error signal went below a certain threshold but didn't actually grab lock. We haven't fixed this one so the problem can repeat. Hopefully we will fix this tomorrow.

2) SQA_MANAGER waited 2 minutes for SQZ_FC to go to the correct state. See attached screenshot of SQZ_MANAGER, line 532. Without checking to see what's actually going on if the SQZ_FC guardian didn't reach its nominal state SQZ_MANAGER will just close the beam diverter and go to SQZ_READY_IFO. SQZ_FC worked fine most of the time but it just happened to take a little more than 2 minutes to reach its nominal state. The logic needs to be fixed with a loop that checks for FC_LOCK guardian state. For now we bypass the issue by increasing the wait time to 3 minutes.

Quiet time between

PDT: 2024-03-11 19:11:02.319941 PDT
UTC: 2024-03-12 02:11:02.319941 UTC
GPS: 1394244680.319941

and

PDT: 2024-03-11 19:21:42.276196 PDT
UTC: 2024-03-12 02:21:42.276196 UTC
GPS: 1394245320.276196
 

Used this time to run BruCo: https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_1394244680_STRAIN_CLEAN/

Notable coherences:

• DHARD_Y at frequencies below 30 Hz [so we might need to tune A2L]
• to a lower extent, CHARD_Y below 30 Hz

OMC-REFL_A_LF shows low-ish but broadband coherence with DARM above 30 Hz, and this is suggestive of the excess noise we see now w.r.t. O4a. Evan suggests that this could be 45 MHz sidebands amplitude noise, that dominates the OMC reflection, and has a small transmission through the OMC

[Gabriele, Louis, Evan H., Swadha]

After tuning the LSC feedforward and updating the calibration, we took a DARM quiet time to compare with the O4a sensitivity. With the updated calibration, our range sits around 140 Mpc. The attached screenshot shows a comparison between cal delta L on January 7th to today. Louis walked me through updating the DARM calibration for both traces to make sure it was accurate. I chose Jan 7 because it appeared to be a time of a recent, decent sensitivity in O4a (around 160 Mpc). Our low frequency noise does not appear to have changed significantly. The reduction in range seems to come from the mid-range region where adjustments in the squeezing would probably help.

Template saved in /ligo/home/elenna.capote/DTT/DARM_compare_O4a_b.xml

Matt, Stefan, Jennie W

Overall: We adjusted the OMC input matrix resulting in a factor of ten reduction in the OMC suspension drive.

The procedure is as follows:
1) Start by calculating the sensing matrix which maps OM3 and OMC degrees of freedom to QPD A and B changes for one of the suspension degrees of freedom (pitch or yaw).

2) Calculate the inverse of the sensing matrix, which will give you a possible input matrix, mapping QPDA and B changes to OM3 and OMC changes which we use for feedback. The first row of the matrix maps only to OM3, for example, which we chose to be our primary degree of freedom with the higher bandwidth. The trouble we were finding before is that the inverse of our sensing matrix yields a strong degeneracy between the two degrees of freedom, and so we push our second row in the direction that cancels most of the noise in the error signal, and also reduces the degeneracy between the error signals.

This procedure can then be repeated for the other degree of freedom (pitch or yaw).

The results of the noise reduction can be seen in the time domain as well.

Jennie, Craig

Today we reran the mod-depth up down tests.  We are not fully trusting these numbers because we suspect we are clipping a bit on IM4_TRANS, which might artificially raise all of our estimated PRGs, including those for RF9 and RF45.
Additionally, there was obvious thermalization still happening during the measurement.  Still, the first pass measurement is useful for up to 10% estimates?
We should rerun after we recenter on IM4.

PRGs
9 MHz PRG = 85.6
45 MHz PRG = 36.6
Carrier PRG = 50.4

REFL ratios
9 MHz reflection ratio = 0.309
45 MHz reflection ratio = 0.268
Carrier reflection ratio = 0.055

Table of relative powers
Channels
9 MHz
45 MHz
Carrier
H1:IMC-PWR_IN_OUT16
0.013
0.015
0.972
H1:IMC-IM4_TRANS_NSUM_OUT16
0.013
0.015
0.972
H1:LSC-REFL_A_LF_OUT16
0.065
0.065
0.870
H1:LSC-REFL_B_LF_OUT16
0.063
0.062
0.874
H1:LSC-POP_A_LF_OUT16
0.022
0.011
0.967
H1:ASC-POP_A_NSUM_OUT16
0.021
0.011
0.968
H1:ASC-POP_B_NSUM_OUT16
0.021
0.011
0.968
H1:ASC-AS_C_NSUM_OUT16
0.181
0.521
0.298
H1:ASC-OMC_A_NSUM_OUT16
0.174
0.637
0.189
H1:ASC-OMC_B_NSUM_OUT16
0.180
0.565
0.255
H1:ASC-X_TR_A_NSUM_OUT16
0.008
0.009
0.983
H1:ASC-X_TR_B_NSUM_OUT16
0.008
0.009
0.983
H1:ASC-Y_TR_A_NSUM_OUT16
0.009
0.009
0.983
H1:ASC-Y_TR_B_NSUM_OUT16
0.009
0.009
0.983

EDIT:
We forgot where the POP beam diverter was, so I'm also posting some MEDMs and Guardian code snippets of where and how to reopen that beam diverter.  We have left the POP beam diverter open for now.

We successfully balanced the BRS with the remote mass adjuster for the first time this morning. The process was relatively painless. We used a windows machine to drive the picomotor and a separate laptop to monitor the BRS readouts. The BRS is still equilibrating and will drift more into range over the next few days.

Total movement today: -60k steps
Coupling/decoupling move: 1.25k steps
Maximum: +- 140k steps
Be careful: +-100k steps

Log:
-2.5k steps
-2.5k steps
+1.25k steps
-1.25k steps
-2.5k steps
+1.25k steps
-1.25k steps
-10k steps
+1.25k steps
-1.25k steps
-10k steps
+1.25k steps
-1.25k steps
-5k steps
+1.25k steps
-1.25k steps
-2.5k steps
+1.25k steps
-1.25k steps
-2.5k steps
+1.25k steps
-1.25k steps
-5k steps
+1.25k steps
-1.25k steps
-10k steps
+1.25k steps
-1.25k steps
-2k steps
+1.25k steps
-1.25k steps
-1.25k steps
+1.25k steps
-1.25k steps
-2.5k steps
+1.25k steps
-1.25k steps
-2.5k steps
+1.25k steps