TITLE: 12/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing at 155Mpc and have been Locked for 10 hours. We temporarily were taken out of Observing a bit earlier due to the squeezer pzt hitting its limit and unlocking SQZ, but it was able to relock itself within a few minutes. Pretty quiet night otherwise.
LOG:

00:00 Detector Observing and Locked for 2hours

00:33 Popped out of Observing and into Commissioning for SQZ
00:36 Back into Observing

07:14 SQZ unlocked and took us out of Observing due to SHG PZT hitting its limit
07:17 SQZ relocked itself and I put us back into Observing

Observing at 157Mpc and have been Locked for 6 hours now. Nothing to report.

We have made significant improvements to our low frequency sensitivity since I last put a coarse Newtonian noise estimate on the same plot as DARM, back in 2015 (alog 22113) so this is an update to that plot.  The highest level conclusion is that Newtonian noise is still more than a factor of 10x below our current DARM sensitivity, for both H1 and L1.  It turns out it's about a similar factor of 25x below DARM at both H1 and L1. 

In the attached plot I show the GDS-CALIB_STRAIN_CLEAN channel for both H1 and L1.  I also show an estimate of the Newtonian noise at each of H1 and L1 (after Jim helped me find a missing 1/(2*pi) - thanks Jim!).  Since this NN estimate comes entirely from an average of our ground seismometers (1 per building), we expect that this has not changed much now vs. back in 2015, and indeed it doesn't.

In the attached notebook (download, remove the .txt and make sure it has .ipynb, and then run it), the final plot shows that indeed Jan's estimate of NN from T1500284 matches the estimate I get with more recent seismic data.   As Jan noted back in 2015, to do a more proper estimate, we need to look at an array of sensors, but this is a fine coarse-grained estimate to show that NN is not responsible for our noise limitations at this time.

Dave, Ansel, Camilla 

Dave has written script /opt/rtcds/userapps/release/cds/h1/scripts/hws_camera_control.py that is running on in a tmux session called "camera control"  ITMX and ITMY hws computers (h1hwsmsr/h1hwsmsr1). Now we will be able to see HWS data for lockloss, locking and power up without contaminating  DARM with combs when observing:  more details in 74915. FRS4559 updated. 

It takes takes two arguments (optic_name and cam_id) and runs in an infinite loop, every minute it gets the camera status and the IFO lock state. It monitors if H1 is locked and  turns the cameras on and off accordingly (via an external triggering setting): OFF if ISC_LOCK > 580, on if  ISC_LOCK < 580.  

It logs its actions to the screen. Each cycle it writes the camera status to a file /opt/rtcds/lho/h1/hws/{optic_name} with the future plan to write this to a trendable channel. For now we can trend if the camera is on or off by seeing if the HWS data is updating,  see attached. 

TITLE: 12/20 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Most of the day was spent for commissioning that ended in a lockloss, but relocking was straightforward. H1 has been locked for 2 hours.

• 18:00 Dropped observing for coordinated commissioning time
• 21:03 Lockloss from commissioning activities - alog74938
  • ETMX ISI (both stages) WDs tripped
• 22:04 Reached NLN
• 22:26 Started stochastic magnetic injections - alog74941
• 23:12 Started observing

LOG:

TITLE: 12/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 7mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.33 μm/s
QUICK SUMMARY:

Detector is Observing and has been Locked for 2 hours now. Everything is looking good but I will keep an eye on the LVEA temps.

Naoki, Sheila, Camilla

After our SQZ data taking 74935, we adjusted H1:SQZ-ADF_OMC_TRANS_PHASE from 80 to 78 to have the SQZ_ANGLE_ADJUST servo keep the sqz angle slightly lower, to sacrifice some high frequency squeezing for more squeezing in the DARM bucket. We can already see this has improved the image (135Hz) BLRMS, plot attached. Yellow 350Hz BLRMs is the same. Plot attached.

Note that the SQZ_ANGLE_ADJUST servo wasn't on in the two previous locks 74918 so that may slightly effect SQZ angle.

Naoki, Vicky, Camilla

After cooling down OM2, we took LSC/ASC/jitter noise injection and ran the noise budget using the following time. The result is attached.

UTC: 2023-12-20 15:16:44 UTC
GPS: 1387120622

The noise budget with cold OM2 uses GDS-CALIB_STRAIN_CLEAN, while the noise budget with hot OM2 in 74788 uses CAL-DELTAL_EXTERNAL_DQ. We will make the noise budget with hot OM2 using GDS to accurately compare the noise budget with hot/cold OM2

Camilla, Naoki, Sheila, Nutsinee

We did a repeat of the measurement set from 73621 with OM2 cold.  For a summary, Camilla's plot shows 200V/200V PSAMs setting with solid lines and 120V/120V as dashed lines. There is a stronger frequency dependence for the 120V/120V settings, which confirms what we saw with OM2 hot, that 200V/200V has better mode matching and less frequency dependent SQZ rotation. (This plot is a direct comparison to October's data. )

The third attachment is a plot that shows that the squeezing angle that maximizes the squeezing at 2kHz is not the same as the one that maximizes the squeezing at 200Hz, (green traces are optimized for 2kHz, blue traces are optimized for 200Hz, solid is 200V/200V and dashed is 120V/120V), you can see that the frequency dependence is larger for 120V/120V.

The fith attachment compares OM2 hot vs OM2 cold for antisqueeze and squeezing, with PSAMS at 200V/200V.  There is less anti-squeezing with OM2 hot, which could be due to a difference in nonlinear gain or reduced readout losses.  The green traces show that the squeezing level is similar, although the no sqz spectra is also different between the two times. 

times:

• NO SQZ: 2023/12/20 18:00:16- 18:20:40 UTC  (during this time we reset AS42 offsets see attached, and measured NLG 18.1) ref0
• SQZ: PSAMS 200/200 CLF RF6 203.85 deg 18:24:30- 18:31:33 (ASC running) ref19
• ASQZ:PSAMS 200/200 CLF RF6 270.22 deg 18:35:00-18:40:00 (ASC IFO and FC off) ref20
• MID SQZ+: PSAMS200/200 CLF RF6 237.04 deg 18:42:00-18:47:10 ref 21
• MID SQZ-: PSAMS 200/200 CLF RF 89.13 deg 18:50:40-18:56:00 ref 22
• repeat sqz slightly better at low F worse at high F: PSAMS 200/200 CLF RF6 194.37 deg 19:00:30-19:07:20 ref 23 (a couple of glitches happened)  (suggests we should be watching 100Hz to tune SQZ ANG instead of 1kHz)
• turned ASC back on, moved PSAMS to 120/120, waited about 3 minutes for the AS42 to converge. 
• SQZ PSAMs 120/120 CLF RF6 214.28 deg 19:18:30-19:24:00 ref 24(This is the DEMOD angle that gave the best sqz at 2kHz, changing the PSAMs changes which demod angle this best squeezing is at)
• SQZ PSAMs 120/120 CLF RF6 194.37 deg 19:27:40-19:33:20 ref 25  (better SQZ at 200Hz)
• ASQZ PSAMS 120/120 CLF RF6 100.5 deg CLF servo sign flipped 19:42:20-19:47:40 ref 26
• MID SQZ PSAMS 120/120 CLF RF6 237.04 deg 19:49:10- 19-54:50 ref 27
• MID SQZ PSAMS 120/120 CLF RF6 89.13 deg 19:56:10 - 20:01:40 ref 28

Since our ASQZ with PSAMS 200/200 was a little lower than with 120/120, and that seemed inconsistent with our sqz data and our previous measurement with OM2 hot, we went back to SQZ with PSAMS 200/200, ran ASC then turned it off, and checked the sqz angle carefully. This did give a little more anti-sqz to replace the reference 20 above:

• ASQZ PSAMS 200/200 CLF RF6 100.5 deg CLF servo flipped 20:13:15- 20:19:30 ref 29

Camilla saved these references in userapps/sqz/Templates/dtt/DARM/PSAMS_tests_Dec2023.xml

Updated nuc25 LSC Loops references from 05 May @ 76W input to 16 Dec 16:20UTC @ 60W input. Only PRCL lops is a little different from when we were running at 76W, plot of old and new refs attached.

No difference seen between cold/hot OM2.

[Jenne, RyanS, JoeB remote at LLO]

We've started the 45 min stochastic magnetic injection set after having recently reacquired lock.

We turned on the amplifier in the LVEA by clicking the ON button on H1:CDS-PULIZZI_ACPWRCTRL_VERTEX0_OUTLET_1 (sitemap -> CDS -> CDS AC Power Control), then put in the same gps time (1387146396) as LLO into the script from userapps/pem/h1/scripts/inject_mag_10to40.py, which is using waveform = 'CorrMagInj_timestream_2700sec.dat'.

The attached screenshot shows the vertex magnetometers and a (not necessarily well calibrated) version of DARM with the references before the injections, and the 'live' traces during a time of the injection.

This will run for about 45 mins, then we'll turn off the amplifier and go to Observing for the night.

[Louis, Sheila, Gabriele]

Today Sheila and Louis transitioned again to the new DARM offloading to check if the low-frequency non-stationarity in the strain was due to the ESD drive non-linearity. In summary: it works

First of all, GDS-CALIB_STRAIN was not yet calibrated for the new configuration, so in the "New DARM" offloading the absolute values of strain spectrum are wrong. Nevertheless we can study the non-stationarity.

The new DARM offloading scheme reduces the ESD drive and its RMS as expected in the few Hz region. There is an increase of ESD drive below 0.5 Hz, to be understood. But that increase doesn't seem to be a problem for now.

We can compare a period with the "Old DARM" scheme with a period with the 'New DARM" scheme by looking at a spectrogram and at a whitened spectrogram. The difference is evident: the fast non-stationarity evident with the old scheme is not visible in the new scheme.

We can also make a scatter plot of strain noise BLRMS between 16 and 60 Hz and the ESD RMS. Since the strain channel is not calibrate yet, absolute values of the strain BLRMS are not informative. Nevertheless, the correlation between ESD RMS and strain noise is gone.

As a final point, we can compare the bicoherence of ESD times ESD to DARM with the old scheme and the new scheme. All bicoherence is gone in the new configuration

All changes are reverted for now.

Lockloss @ 21:03 UTC from commissioning activities (switching DARM control between ETMX and ETMY). This was the last test performed at the end of commissioning time.

H1 is now out of observing in coordination with L1 for a planned ~3 hours of commissioning. Starting with no-SQZ time.

Jenne, Naoki, Louis, Camilla, Sheila

Here is comparison of the DARM CLEAN spectrum with OM2 hot vs cold. The second screenshot shows a time series of OM2 cooling off.  The optical gain increased by 2%, as was seen in the past (for example 71087).  Thermistor 1 shows that the thermal transient takes much longer (12 + hours) than what thermistor 2 says (2 hours). 

Louis posted a comparison of the calibration between the two states, there are small differences in calibration ~1% (74913).  While the DARM spectrum is worse below 25Hz, it is similar at 70 Hz where we in the past thought that the sensitivity was worse with OM2 cold.  From 100-200 Hz the sensitivity seems slightly better with OM2 cold, some of the peaks are removed by Jenne's jitter subtraction (74879) but there also seems to be a lower level of noise between the peaks (which could be small enough to be a calibration issue).  At high frequency the cold OM2 noise seems worse, this could be because of the squeezing.  We plan to take data with some different squeezing angles tomorow and will check the squeezing angle as part of that.

So, it seems that this test gives us a different conculsion than the one we did in the spring/summer, and that now it seems that we should be able to run with OM2 cold to have better mode matching from the interferometer to the OMC.  We may have not had our feedforwards well tuned in the previous test, or perhaps some other changes in the noise mean that the result is different now. 

Rahul, Camilla, Jonathan, Erik, Dave:

At 07:33 PST during a measurement this morning the ETMX test mass was set into motion which exceeded the user-model, SWWD and HWWD RMS trigger levels. This was very similar to the 02 Dec 2023 event which eventually led to the tripping of the ETMX HWWD.

The 02 Dec event details can be found in T2300428

Following that event, it was decided to reduce the time the SUS SWWD takes to issue a local SUS DACKILL from 20 minutes to 15 minutes. It was this change which prevented the ETMX HWWD from tripping today.

The attached time plot shows the details of today's watchdog events.

The top plot (green) is h1susetmx user-model's M0 watchdog input RMS channels, and the trigger level (black) of 25000

The second plot (blue) is h1susetmx user-model's R0 watchdog input RMS channels, and the trigger level (black) of 25000

The lower plot shows the HWWD countdown minutes (black), the SUS SWWD state (red) and the SEI SWWD state (blue)

The timeline is:

07:33 ETMX is rang up, M0 watchdog exceeds its trigger level and trips, R0 watchdog almost reaches its trigger level, but does not trip.

At this point we have a driven R0 and undriven M0, which was also the case on 02 Dec which keeps ETMX rung up above the SWWD and HWWD trigger levels

The HWWD starts its 20 minute countdown

The SWWD starts its 5/15 minute countdown

+5min: SEI SWWD starts its 5 minute countdown

+10min: SEI SWWD issues DACKILL, no change to motion

+15min: SUS SWWD issues DACKILL, R0 drive is removed which resolves the motion

HWWD stops its count down with almost 5 minutes to spare.

We have opened a workpermit to reduce the sus quad models' RO trigger level to hopefully always have M0 and R0 trip together which will prevent this is the short term. Longer term solution requires a model change to alter the DACKILL logic.

Here's a comparison of Pcal to DeltaL External and GDS Calib Strain broadband measurements with OM2 hot and cold.

File path to DTT template: /ligo/home/dana.jones/Documents/OM2_heating/OM2_hot_v_cold.xml