TITLE: 11/15 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Pretty quiet night, I ran a calibration suite, and the range has been steadily just under 160 Mpc. Lock time of 9:35 at the end of the shift.
03:02 dropped observing to run a calibration measurement alog74212
03:32 Back to NLN, the DARM fom timed out during the state transition and I had to restart it
03:33 back into Observing
I've seen the MC3 camera on NUC26 flash blue a few times.
I ran the analysis for the OPLEV charge measurements on ETMY that Rahul took this morning. The charge on ETMY is fairly stable, some small increases and decreases on the quadrants since the last measurement.
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:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 16:04 | FAC | Cindi | FCES, FCT | n | Tech clean | 17:50 |
| 16:04 | FAC | Karen | EY | n | Tech clean | 17:26 |
| 16:05 | FAC | Kim | EX | n | Tech clean | 17:28 |
| 16:05 | VAC | Janos, Mike | All site | n | Add air ports to scroll pumps | 19:53 |
| 16:11 | FAC | Randy, Betsy, Ibrahim | LVEA, FCES | n | Craning, W & N bay cranes | 19:17 |
| 16:12 | SAFE | Ryan S | LVEA | not anymore | Laser safe transition | 16:22 |
| 16:16 | VAC | Jordan, Gerardo | FCTE | n | Valve installation | 20:07 |
| 16:16 | FAC | Tyler | Xarm, Yarm | n | Tumbleweed harvesting | 19:53 |
| 16:30 | CDS | Fernando, Marc | CER | n | Swap SQZ chassis | 18:26 |
| 16:33 | CDS | Jonathan, Tony | MSR | n | Switch replacement | 17:07 |
| 16:34 | CDS/SQZ | Daniel | CR | n | Beckhoff | 20:05 |
| 16:52 | CDS | Fil | EX, EY | n | Cable pulling | 19:53 |
| 17:02 | VAC | Norco | CP2 (CS) | n | LN2 fill | 18:59 |
| 17:07 | CDS | Dave | - | n | DAQ restart | 17:08 |
| 17:13 | VAC | Janos | LVEA | n | Turbo tests | 19:19 |
| 17:21 | SUS | Rahul | EY | n | SUS oplev charge meas. | 19:21 |
| 17:29 | FAC | Kim. Karen | LVEA, high bay | n | Tech clean | 19:29 |
| 17:40 | SEI | Jim | LVEA,CR | n | HAM1 noise investigation | 20:05 |
| 17:40 | SQZ | Sheila, Naoki | CER | n | Looking for a cable | 18:00 |
| 18:13 | IAS | Jason | LVEA | n | Monument scouting | 19:36 |
| 18:17 | ISC | Sheila | CR | n | OMC scan | 19:17 |
| 18:23 | SEI | Jim | HAM8/CR | n | Quiet time and meas. | 19:49 |
| 18:32 | VAC | Norco | EY | n | LN2 fill left site 19:55utc | 19:58 |
| 18:40 | FAC | Chris | FCES | n | Tumbleweeding | 19:50 |
| 19:06 | ALS | Sheila, TJ, Ryan S | EX | n | ALS health check | 20:01 |
| 19:32 | TCS | Camilla | CTRL Rm | N | TCS CO2 adjusting | 19:52 |
| 19:38 | EE | marc | Mid Y | N | Geting ballasts parts. | 20:05 |
| 19:52 | FAC | Tyler | LVEA | N | Inverntory & looking for parts | 19:54 |
| 19:56 | EE | Fil | Y arm LVEA | N | Taking OP Lev Pics | 20:05 |
| 20:08 | OPS | Oli & Camilla | LVEA | N | Post Maintenance LVEA sweep | 20:38 |
| 23:02 | CDS | Fil | MY | n | Parts pickup | 23:28 |
| 23:03 | PCAL | Tony | PCAL lab | local | Troubleshooting | 23:24 |
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:
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.
| PLL Before | PDH Before | PLL After | PDH After | ||
| UGF | 30.7 kHz | 16.8 kHz | 17.6 kHz | 15.0 kHz | |
| Phase margin | 45 deg | 42 deg | 43 deg | 45 deg | |
| Gain margin | ~5dB | ~4dB | ~4dB |
~6dB |
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.
Tue14Nov2023
LOC TIME HOSTNAME MODEL/REBOOT
08:48:11 h1lsc0 h1sqz
08:52:40 h1daqdc0 [DAQ] <<< 0-leg restart
08:52:52 h1daqfw0 [DAQ]
08:52:52 h1daqtw0 [DAQ]
08:52:53 h1daqnds0 [DAQ]
08:53:01 h1daqgds0 [DAQ]
08:53:49 h1daqgds0 [DAQ] <<< 2nd GDS0 restart
09:03:18 h1daqdc1 [DAQ] <<< 1-leg restart
09:03:28 h1daqfw1 [DAQ]
09:03:29 h1daqnds1 [DAQ]
09:03:29 h1daqtw1 [DAQ]
09:03:39 h1daqgds1 [DAQ]
09:04:20 h1daqgds1 [DAQ] <<< 2nd GDS1 restart
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.
Since we doubled up terminals, the terminal for the OPO thermistor physically changed. The resistance reported by the OPO thermistor changed by about 45Ω, whereas the EL3692 measurement error for the 10KΩ range is 50Ω. This seems within the expectation.
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:
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:
The OPO witness thermistor seems broken.
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.
I re-fit this data and think i have a better filter saved (not loaded) in FM3 as "27-10-23-a". We could try this during a commissioning period this week if we wanted to try to further improve MICH.
Tried this FM3 FF 2023/11/14 16:04:30UTC to 16:06:30UTC. It did not cause a lockloss. I did not run the MICH comparism plot but DARM looked slightly worse. Plot attached.
From 16:07:05, I tried FM6 which is the currently installed MICH FF (FM5) without the 17.7Hz feature 74139.
I tried to test a new MICH FF FM3 Camilla made. First I measured the current MICH FF FM5 as shown in the attached figure. The pink and black curves are the current MICH FF FM5 on 20231027 and 20231103, respectively. The current MICH FF gets worse between 30-80 Hz in a week. The MICH FF on 20231103 was measured after 6.5 hours into lock. Then I ramped the MICH FF gain to 0 and turned off FM5 and turned on FM3. After I ramped the MICH FF gain to 1, a lockloss happened immediately.
Sorry that this caused the 1383077917 lockloss.
Unsure why this FM3 would be unstable. Lockloss occurred 10 seconds after MICHFF had finished ramping on (13s - 3sec ramp time). FM3 MICH_FF looks to be outputting ~ factor of 2 higher than the current FM5 filter. Don't see any obvious instabilities in the 10seconds before the lockloss.
LSC and ASC plots attached. I wonder if the lockloss was just badly timed. We could attempt to repeat this before our Tuesday Maintenance period.