RyanS noted this morning that the temperature change in the LVEA seems to have caused some alignment shifts to optics in the corner station (first screenshot, from RyanS), and so he had to run an initial alignment this morning. I suspect that, since the temperature change primarily happened while we were locked, the ASC was able to follow along over the last day or so, however when we lost lock (due to the earthquake) and the ASC histories got cleared (as they do at every lockloss), the residual alignments were too poor for lock acquisition. After initial alignment, things seem to be going smoothly.

Out of an abundance of caution, I ran the rubbing checking script, and all the optics in the corner station seem to be fine, and clear of egregious rubbing (I didn't check the ETMs, TMSs, or FC2), and all consistent with the last time the script was run by RyanC in alog 74522.  I think this means that there is no need for Facilities to change the setpoint of the LVEA.  If the system can keep us where we are right now, then this seems to be a fine place to be. 

I'll note that it does look like both RM1 and RM2 have a little bit of fuzz to their spectra between 7-9 Hz.  This fuzz was there in RyanC's checks on the 1st of Dec, but is not there in the reference time from the 20th of Nov.  We don't have vertical control over the RMs, so we can't try moving them to see if that alleviates the fuzz.  Overall we seem to be doing fine, but that fuzz zone may be something to keep an eye on.  While the rubbing script looks at the L, P, Y dofs, I had a look at the individual OSEMs.  The fuzz seems to only show up in Length in the dof view, and that's consistent with my finding that it looks about the same in each individual OSEM (because it's cancelled out in the P and Y dofs).  I attach in the second screenshot one representative individual OSEM to show the fuzz that I'm looking at (green is a reference from 20th Nov 2023, and blue is earlier today when the IFO was down, but the earthquake was mostly done).

Thu Dec 21 10:02:15 2023 Fill completed in 2min 13secs

I viewed the online MEDM trends at the time, it looked like a good fill. There is no DAQ data for this time, so no plot attached.

Erik, Jonathan, Dave:

We upgraded cdslogin to deb12 at 09:45 PST this morning. This caused the EDC on h1susauxb123 go constantly restart. For a short term solution we removed all the channels being served by cdslogin from the H1EDC.ini channel list (lock-loss-alert and remote-access channels) and restarted the DAQ. The EDC is running stably now.

The loss of EDC channels caused a secondary Guardian issue, which is now resolved.

The h1cdssdf system would not run, again because it is connecting to cdslogin lock-loss-alert channels. We have temporarily removed these channels from the monitor.req and safe.snap files. This also caused a secondary Guardian problem which has now been resolved.

Current situation:

Alarms system is running

Lock loss alert system of offline.

EDC is missing all of its cdslogin channels

No slow channels from EDC in the DAQ between the times of 09:50:00 and 10:21:00

TITLE: 12/21 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 3mph Gusts, 2mph 5min avg
    Primary useism: 0.39 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY:

A M6.3 earthquake from near the Aleutian Islands knocked H1 out of lock around an hour ago, and H1 has been properly waiting to try relocking until the seismic configuration leaves EQ mode. The alignment spot on the AS AIR camera looks quite bad, so I imagine I'll start with an initial alignment once the ground motion calms enough.

All other systems look good.

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

[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.

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. 

TJ, Ansel, Dave, Camilla

After finding that 1Hz and 5Hz DARM combs were caused by HWS camera sync frequency in 74617, we've turned off all HWS at 21:00UTC so we can check that nothing else from HWS is effecting DARM.

Stopped all HWS code (ETMY was already off 73915). Tuned off all cameras and RCX CLinks. Turned off the ITM SLEDs, ETMX laser will still be on but was tested in 69648 not to effect DARM.

As long as the computers aren't restarted I think that the H1:TCS-E{OPTIC}_HWS_ channels will remain reading their last values, if not Dave might need to "green-up" the CDS overview.