Following the wiki I ran a calibration measurement while LLO was still relocking.

Starting with the BB

NLN calibration screenshot

03:02 NLN to NLN_CAL_MEAS

03:04 Broadband measurement started:

• /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231115T030313Z.xml

03:09 Simulines:

PST start: 2023-11-14 19:09:20.280160 PST
UTC start: 2023-11-15 03:09:20.280160 UTC
GPS start: 1384052978.280160

2023-11-15 03:31:25,595 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20231115T030922Z.hdf5
2023-11-15 03:31:25,644 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20231115T030922Z.hdf5
2023-11-15 03:31:25,657 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20231115T030922Z.hdf5
2023-11-15 03:31:25,671 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20231115T030922Z.hdf5
2023-11-15 03:31:25,683 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20231115T030922Z.hdf5

PST end: 2023-11-14 19:31:25.778909 PST
UTC end: 2023-11-15 03:31:25.778909 UTC
GPS end: 1384054303.778909

Closes FAMIS 26066, last checked in alog73538

I had to change the env to get the plots to show as RyanS mentions in alog73432

TITLE: 11/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Maintenance day recovery was fairly straight forward, with one lock loss on the way to low noise. We've been locked for almost 2 hours now.
LOG:

• 1612 Lock loss to start maintenance
• 2130 Lost lock at Laser_Noise_Suppression.
• 2252 Observing. ISS 2nd loop had no issues this time (alog74204)

TITLE: 11/14 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.50 μm/s
QUICK SUMMARY:

• All systems look good, microseism still a little high, range looks to be rising
• In observing since 22:52 UTC

Sheila, Ryan S, TJ

Today we went down to EX and looked at the UGFs for the PLL and the PDH, and then the I/Q ratio. To do this we connected the SR785 to the correct common mode chassis (Sheila knew which was which as labels were lacking), and then turned on the test output on the medm screen. We then looked at the I/Q ratio and adjusted the demod phase (H1:ALS-X_REFL_A_PHASE_PHASEDEG) to increase this ratio. Started at around 12.5dB @120deg and ended up at 115deg as the ratio become nonsensical with Q approaching 0 (picture). This value is now saved in SDF.

This isn't a large change, so we don't expect to see much of a difference but it will be good to compare this to EY when we get a chance to get down there.

WP11524 Upgrade sw-msr-h1aux

Jonathan, Tony, Patrick Dave:

The MSR switch sw-msr-h1aux was upgraded to new hardware by Jonathan and Tony (see Jonathan's alog for details).

Several restarts were needed following the upgrade to restore servers which are connected to this switch. Several cameras attached to h1digivideo[0,1,2] became unresponsive. We first tried to restore these by restarting individual processes on the digivideo machines but eventually decided to reboot the original server h1digivideo[0,1,2]. Note that nothing needed restarting on the new h1digivideo3 server.

The tp mon IOC froze around this time (08:52 PST) and was restarted on cdsioc0.

WP11521 New h1sqz model change

Daniel, Dave:

Daniel made a h1sqz model change, adding 7 filter modules. This required a DAQ restart

DAQ Restart:

Dave:

A fairly unremarkable retstart except both GDS needed a second restart to sync their channel lists.

Cell Phone Alert System Back Using Twilio

Dave:

On Saturday our Twilio toll free number was verified by the Campaign Registry and we were able to use it to send SMS text messages again. I decided to wait until H1 lost lock, and 79 hours later this happened at the start of today's maintenance. I reverted the hybrid code I had been running (Twilio for phone calls, cellphone providers for SMS) back to the Twilio-does-it-all code.

I spent some time this morning on the HAM8-GS13 v1 issue reported here by Jim, causing a 0.6Hz table oscillation. While working on it, the GS13 (or something along the chain) decided to fix itself. The problem has not reappeared -yet- since then.

1- Jim set the ISI to offline @18:21 UTC. We see GS13 v1 ASD x2 below v2 and v3 (fig1)
2- With the ISI offline, I sent a Z excitation and tripped the ISI @ 18:54 UTC.
3- Restarted the Z excitation with smaller amplitude between 18:55 to 18:57 UTC. The x3 vertical GS13 ASD now match (fig2)
4- Turning off the excitation, v1 asd is still matching the other 2 vertical gs13 (fig3)
5- Turning on the loops. No 0.6Hz anymore (fig4) ...

Puzzling... We'll continue to monitor.

Lock recovery was fairly straight forward. We lost lock at Laser_Noise_Suppression one time and it looked like the ISS 2nd loop would close with the diffracted power changing too much so it would try again. It did this 4 times before we lost lock. Next lock attempt the 2nd loop had no issues.

[Aidan, Alena]

Per the autogeneration of the LLO coordinates from ZEMAX, I've run a Python script on the LHO ZEMAX ray trace to generate the corresponding data set of locations and distances for H1. Note that ITMY,  ZM4, and OMC_in were not it the ZEMAX ray trace (the latter two were not in the model and ITMY was not intercepted by any rays) and so these optics do not appear in the PDF file. We'll work to resolve that omission.

The data is posted on the DCC: https://dcc.ligo.org/LIGO-E2100383-v4

I verified the coordinates for all the optics by directly interfacing with the ZEMAX model. The only slight difference was a 2mm offset of the pilot ray from center on the SQZ TFP - otherwise the rays intercepted the centers of all the optics with a precision better than 0.5mm.

Naoki, Daniel, Sheila, Camilla 

Naoki found the OPO would not lock like usual. After he locked it on green there was no CLF_REFL_RF6 signal. After checking settings, we followed 73801 instructions to measure the NLG (17.8). In doing so, found we needed to adjust the OPO temperature by 0.15degrees. After this OPO temperature adjustment, it locked fine. Daniel swapped thermistor readouts today that effected this even though the requested and measured OPO temperature were the same before and after, 74188.

Note that now the OPO LOCKED_SEED_NLG guardian state goes though LOCKED_CLF_DUAL (needs a locking OPO), we first dropped the CLF RF threshold in half (via SQZ Overview > HAM7 > OPO IR > OPO PZT1 > H1:SQZ-OPO_IR_RESONANCE_CLF_NOM), now reverted.

Today I did OMC scans, leaving the sidebands on, so that we can try to use the sidebands to calibrate the PZT voltage into frequency and estimate finesse from the scan.  

I left the input power at 2W (1.8W on PRM), and did the scan slowly to try to avoid the saturations that Keita observed in 72254.  I also took scans at three different speeds.  

I took scans with the OMC ASC on the QPDs.  We know that there is a slightly better alignment for single bounce, but don't think that this should matter much for the finesse measurement that we get this way. 

Times:

• 14/11/2023 19:05:00 UTC (200 seconds ramp up, then 200 seconds down) (red)
• 14/11/2023 18:53:01 UTC (100 seconds ramp up, then 100 seconds down) (mint green)
• 14/11/2023 18:48:03 UTC (50 seconds up, 50 seconds down, twice)  This scan seems to have rather different peak heights, so I think the scan was too fast and we shouldn't use this data. (blue)
• 14/11/2023 18:57:49 super slow scan, accidentally put an extra 0 in the frequency of the excitation.  This data may not be very useful because the laser frequency could be drifting over time with this very slow scan.  (brown)

WP 11523

Cabling for the manifold accelerometers pulled at both end stations. Cables pulled from TCS-C1 to the manifold. Cables need to be terminated.

LVEA has been swept following Tuesday Maintenance.

Note:

• Attached to the sqz tube there is a vacuum pump controller that is on and emitting a very high pitched noise (I could hear it, Camilla couldn't) (attachment1, attachment2). Tagging VE
• At HAM6 pump controller attached to HAM6 and on (attachment3). Tagging VE
• At the beamtube right when entering the LVEA, there is a black cable alligator clipped to a beam tube bolt and snaking its way to the upstairs portion of the CER (attachment4).
• In CER, a fan for the Coil Driver on HAM4 was making a high pitched electronic ticking noise (like it was catching or slowing), but Fil was able to stop the sound by poking at the fan. Might come back if fan is failing so keep an eye out for issues there. Tagging OpsInfo

The OPO witness thermistor seems broken.

(Janos Cs.)

Output mode cleaner tube turbo station;
     Scroll pump hours: 5563
     Turbo pump hours: 5623
     Crash bearing life is at 100%

X beam manifold turbo station;
     Scroll pump hours: 785
     Turbo pump hours: 787
     Crash bearing life is at 100%

Y beam manifold turbo station;
     Scroll pump hours: 1879
     Turbo pump hours: 604
     Crash bearing life is at 100%

FAMIS tasks 23523, 23595 and 23643.

Flush ports have also been added to the scroll pumps at all stations. These help the pumps to remain clean, and also the chilling efficiency will be better.

This is a regular life cycle replacement.  Anthony Sanchez and Jonathan Hanks replaced sw-msr-h1aux.  This resulted in an outage to the cameras and slow controls while we moved the connections.

It generally went smoothly.  Two things to note.  First, due to being blocked on the front of the rack we found that in removing the old switch it was useful to wrap a sling around it (through the access holes in the top of the rack) in order to support the switch (and not drop it on fibers, and other equipment).  Second, it looks like we ripped a tube/sleeve protecting fibers while putting the new switch in.  The fibers did not look or feel damaged or kinked, so I think we just nicked the sleeve while positioning the replacement switch.

Noticed that the CO2's weren't exactly outputting 0W at their NO_OUTPUT settings, plot attached, so I searched for home on both rotation stages. This brought them back much closer to zero. Daniel reminds us that "search for home" needs to be done after every Beckhoff reboot, unsure if we did it after the Beckhoff came back on Tuesday. 

I further adjusted CO2X calibration as it hadn't been getting close to 1.7W since we touched it on Tuesday, 74044, TJ's bootstrapping was getting it closer to 1.7W but works best when we start with a close power.

CO2Y Rotation stage weirdness: On my final test, asking CO2Y to go to 1.7W it jumped to -700degrees! I then asked it ot go back to minium power, which it slowly did. Very strange. A better way to take it back might have been to ask it to "search for home" but I remembered that clicking "abort" often crashes Beckhoff! Searched for home after this. Plot attached.

Took MICH FF measurements following instructions in lsc/h1/scripts/feedforward/README.md but running MICHFF_excitation_ETMYpum.xml. Data saved in lsc/h1/scripts/feedforward/ as .txt files. Last tuned MICH in 73420. 

I saved a new filter in FM6 as 27-10-23-b (red trace) but it made the MICH coupling worse between 20 and 80Hz so we left the original (pink trace). We could try to re-fit the data to load in Wednesday's commissioning period.