At 18:50, we were briefly pushed out of observing when the ITMX CO2 laser lost lock, and the resulting SDF differences in H1:TCS-ITMX_CO2_CHILLER_SERVO_GAIN & H1:TCS-ITMX_CO2_PZT_SERVO_GAIN (see attached). The SDF differences disappeared on their own about a minute later as the CO2 laser locked back on, and we observed that the power in H1:TCS-ITMX_CO2_LSRPWR_HD_PD_OUTPUT went down slightly from 46.7W before it lost lock to 46.4W after it locked back on.

At 18:53 we put the detector back into Observing

Yesterday I did a DHARD_Y noise injection that had band-limited noise between 1.5 and 3.5 Hz. In the first plot I compare ASC-DHARD_Y and LSC-DARM in quiet times and during the injection.

There are several interestiing observations:

• DARM see an increase of noise at the excitation frequency and at the doubled frequency (and maybe other harmonics too)
• DARM noise between 10 and 80 Hz is also increased during the injection, even though DHARD_Y was not more noisy in that band
• there is little coherence between DHARD_Y and DARM, even when injecting noise
• the coherence between DHARD_Y and DARM at 20-60 Hz iss actually lower while injecting noise

This is good evidence that DHARD_Y is causing some non-linear noise coupling in DARM. This is also visible in the bicoherence of DARM with itself or of DHARD_Y and DARM.

It would be interesting to repeat similar noise injections, but with shaped noise and amplitudes such to increase only slighlty the DHARD_Y signal: in this way we might be able to estimate the efffect on DARM in normal conditions.

17:06 Moved out of Observing and into Commissioning so Sheila's OM2 script could finish running.

17:16 Back into Observing

   - SDF Diffs (See attachment):

       H1:AWC-OM2_TSAMS_POWER_SET - ACCEPTED

       H1:OMC-READOUT_XO_TRAMP - ACCEPTED (accidentally but okay)

Gabriele's log entry 71205  pointed out that the OMC is moved a lot (at least in comparison to the LLO OMC) when it is receiving OMC ASC feedback. This observation led to the test of turning of the OMC ASC for some time to look for any effects, see 71422. Although no effect on DARM noise was seen, I was still curious to know: how much is the OMC moving under ASC control?

The attached plots show time series of the 6 BOSEM sensors that sense the upper/top mass of the OMC suspension (relative to the OMC suspension cage). The 5 minutes of data is during the 'OMC pause' test, so in the first half of each plot the OMC is receiving ASC feedback, and in the second half this feedback if off. The plots show:

• T2 & T3: On the top, and at one end, of the (top) mass, so they sense vertical motion. The motion is about 1 micron pk-pk. These 2 sensors are combined to form the Pitch (P) degree of freedom, so the top mass is 'pitching' by about 15 urad pk-pk.
• T1: On the top, at the other end of the top mass. This is moving much less, by about 0.2 micron pk-pk.
• LF & RT: On the long side of the top mass, separated by about 16 cm. The motion is also about 1 micron pk-pk. These sensors form the Yaw (Y) DoF, to the top mass is 'yawing' by about 10 urad pp.
• SD: On the short side of the top mass. This motion is very small, maybe 0.06 um pp, and there's little if any diffference between OMC ASC on or off.

So, even though the OMC is moving a lot compared to that at LLO (which has a different OMC alignment feedbak scheme), the motion is still small compared to the beam, which has: 500 um radius, 680 urad divergence angle.

We conducted a study using data from the Fscan pipeline that shows when the violin modes are rung up, there is a dramatic increase in the number of narrow lines (of the type problematic for CW searches) in the regions around the violin modes and harmonics. This increase in the number of narrow lines is visible both in daily and weekly plots since June 29th when the violin modes and its harmonics are known to have rung up. 

Figure 1 shows how the number of lines jumped significantly in the 300-600Hz and 900-1200Hz bands from June 29th to June 30th, and again from July 9th to July 10th without much change in the other frequency bands. Figures 2 and 3 show the averaged spectrum for the 29th and 30th respectively, demonstrating just how dramatic the increase in the number of lines is. Figure 4 shows how visible and persistent the lines are in the weekly data. 

Figures 5, 6, and 7 show the max amplitude of the violin modes vs number of lines per the square root number of SFTs in three different frequency bands surrounding the violin modes and its harmonics. To remove the effect of the duty cycle on the number of lines counted, the total number of lines counted is divided by the square root of the number of SFTs produced in a day because the number of SFTs produced in a day is directly proportional to the amount of time spent observing on that particular day. From here on out, I will refer to the number of lines per square root of the number of SFTs as the number of lines.

Looking at all the O4 data so far, it is obvious that the number of lines increases with the max amplitude violin modes in the bands surrounding the violin modes and its harmonics. The most dramatic effect is visible in the 300-600Hz band (Figure 5) where the number of lines seems to increase approximately linearly with the max amplitude of the violin modes between amplitudes of 10^-20-10^-18 strain/√Hz. Between 10^-18-10^-17 strain/√Hz, the number of lines increases significantly with no clear pattern. Multiple days after the June 29th ring up appear in this region, showing that these long ring ups can greatly increase the number of lines and decrease CW data quality for a significant period of time. Around the 1000Hz (Figure 6) and 1500Hz (Figure 7) harmonics, the number of lines increases approximately linearly with the max amplitude of the violin modes without displaying the jump present in the 300-600Hz band. This might be because the amplitude of the violin modes has a much smaller range of 10^-19-10^-18 strain/√Hz during the ring up. 

Wed Jul 19 10:06:31 2023 INFO: Fill completed in 6min 27secs

Robert confirmed a good fill curbside.

Adam and Janos

I inspected all installed HEPTA controllers and found all but the Y-mid to be satisfactory. We ran a test on the X-mid to verify thermal switch operated correctly by letting the pump heat up to ~100c. 

The corner station controller that the failed HEPTA was installed on passed all electrical tests. It is my belief that the failure was due to a mechanical defect inside the pump its self.

I inspected the "OMC" turbo controller that was having a issue with indicating lights and identified the issue of a missing component on the back of the indicating light. See address below

https://www.digikey.com/en/products/detail/siemens/3SU14001CK101AA0/15237249


Lastly, I inspected the Y-mid controller and prior to opening the panel I already found red flags such as an electrical connector for a solenoid operated gate valve that does not exist at the HEPTA stations wired into the panel. After opening the panel I noticed an entire relay added to the left side of the panel and wired in that is not part of any wiring diagram and a third small CPC drilled and added in to the bottom of the panel for GV indication which was not necessary as one of the originals is now spared. The extra relay was being used to detect the status of the small solenoid that controlled air flow to the pneumatic gate valve at the HEPTA inlet. We don't care about the status of the solenoid only the status of the GV which is already measured directly from the internal contacts of the GV. This relay only added another failure point for the opening of the GV and has since been removed. I found about 7 wires that were not secured and either pulled out or fell out of their terminals. I found one relay with a normally open and a normally closed contact wired in parallel. This is a logical fallacy as it will always conduct and provides no more control that just a straight wire.

I reconfigured the Controller per the wiring diagram and ran a stop work approved test and all systems that were available to test passed. I was not able to test the complete functionality of the GV as there was no instrument air available but the controlling solenoid did function so i have no reason to believe that the GV would not function. Lastly the thermal switch could not be tested as the pump could not run in the appendix configuration.

Range drop seemed to coincide with pump ISS tripping off; we haven't had this issue since re-aligning the pump AOM a while back (LHO:70190). But since the SQZT0 table fan got turned on yesterday, SHG power trends show that while the input IR power seems stable (bottom 2 plots), the SHG output power (top) has dropped ~15% and still not recovered yet. So, we are having the same pump iss issues again. The control voltage is now hovering again around 2V (2nd plot), which is just marginally stable. 

To get back to the 85uW pump power we've been running with (NLG~12.7), I tried several things, summarized in this trend/screenshot: 
   1. (top green trend) re-aligned pump fiber polarizations (starting w/the "! fiber pol" button on sqzt0 medm), by pico-ing waveplates before the pump fiber. this brought in-chamber fiber rejected from ~0.16 to ~0.03.
   2. (4th pink trend)   re-direct all the light after the pump aom into the fiber path with pico-waveplate
   3. (bottom gray trend)  checked SHG input alignment w/picos, most change on input pico mirror #1 in pitch. bumped SHG temperature from 36.00 to 36.05C. This SHG temp change was accepted in SDF. Combined, this all barely improved SHG output power from 47mW to 48mW. Nominal has been ~55mW, before the recent table+fan incursion to SQZT0. 

If SHG output powers go back to solidly over 50mW (sometimes has taken ~24 hours..), we should be safe from further pump ISS issues. If SHG output power drops any more, given that we are pretty marignal on the ISS now, it'll require more intervention and maybe turning down the pump power until we solve it. We'll watch how the sitation goes, and we'll consider how SQZ_MANAGER can handle pump_iss issues.

TITLE: 07/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.04 μm/s
QUICK SUMMARY:

Detector Locked and in Observing for 5hr 24min.

NUC26 both ETM cameras have been closing themselves and all cameras on that nuc changed to static a couple times each within a small timeframe. Computer has been restarted and all cameras restarted.

Today's Plans:

Planned commissioning today between noon-4 Pacific.

TITLE: 07/19 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 135Mpc
SHIFT SUMMARY: One lockloss from a nearby earthquake, but a quick recovery followed with an hour of violin damping. Range was diminished for about 2.5 hours, now fixed.

Lock #1:

• Lockloss @ 07:38 - 4.9 EQ from Nevada: alog
• Stopped OM2 heating script; it was partway through TSAMS stepping

Lock #2:

• Lock acquisition was fully automatic
• Turned on 2W violin damping @ 08:24 after DARM_TO_DC_READOUT to hopefully get a head start on the damping
  • 2W damping turned off @ 08:39 during LOWNOISE_COIL_DRIVERS
• Reached NLN @ 09:47 after 1 hour in OMC_WHITENING
• Accepted two SDF diffs to go to observing related to OM2 heating (tagging ISC, screenshot attached)
• Range dropped by ~10Mpc around 12:00, possibly SQZ ISS related
• Dropped observing from 14:30 to 14:50 to fix SQZ ISS
  • Range appears to have improved

Handing off to Tony for the day.

LOG:

Austin ran a CHARD_Y injection while we were waiting for the violin modes to be damped. The measurement could be improved at high frequency, but it's a good start. See attached plots and the fit in s-domain below of the optics plus suspension (plant)

z = [-1.89361201+5.8381431j , -1.89361201-5.8381431j ,
        -0.09640395+5.84691435j, -0.09640395-5.84691435j,
         3.20330258+4.44616445j,  3.20330258-4.44616445j,
        -0.15279235+1.84732571j, -0.15279235-1.84732571j,
        -1.26520672+0.j        , -0.02927838+0.43904034j,
        -0.02927838-0.43904034j, -0.26944611+0.j        ]
p = [-0.14766306+5.84793096j, -0.14766306-5.84793096j,
        -3.04921633+0.j        , -0.21088202+2.7609525j ,
        -0.21088202-2.7609525j , -0.07400573+2.48088453j,
        -0.07400573-2.48088453j, -0.03291084+1.03014283j,
        -0.03291084-1.03014283j, -0.0342948 +0.4742311j ,
        -0.0342948 -0.4742311j , -0.02178038+0.j        ]
k = -307334.1901230435)

State of H1: Observing at 136Mpc for 1 hour

Automatic lock acquisition following earthquake, waited in OMC_WHITENING for an hour damping violins.

Lockloss @ 07:38 UTC - 4.9 magnitude earthquake from central Nevada. The quake hit very quickly; seismon warned of it then a minute later EQ mode activated and H1 lost lock.

I've stopped the OM2 heating script on cdsws04 (tagging ISC).

TITLE: 07/19 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 127Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 5mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.04 μm/s
QUICK SUMMARY: Taking over from Austin. H1 has been locked for 3.5 hours.

• All systems look good; ground motion and wind are low
• Austin gave me the run-down on Shiela's OM2 script; I'll monitor it and accept SDFs as things change every 2 hours

TITLE: 07/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 135Mpc
SHIFT SUMMARY:

- Acquired NLN @ 23:32, OBSERVING @ 0:00 (waited in NLN w/ WHITENING off due to DCPD saturations), held in OMC WHITENING for ~45 minutes

- Sheila is running a OM2 heater script that will occassionally take us out of obseving, will note times and accepted SDFs

• Killed script due to lockloss - will rerun next lock

- EQ mode activated @ 0:30, seeing motion in ASC and in SEI overview, no alert from USGS so this might have been local ground motion

• Lockloss @ 0:32 due to this seismic activity
• 0:36 - 6.5 EQ from El Salvador

- Relocking was unaided, waiting at OMC WHITENING to damp violins

- 2:59 - inc 5.0 EQ from El Salvador - successfully rode this one out

- Acquired NLN @ 3:29/OBSERVE @ 3:34

- Restarted Sheila's OM2 test (script is running on cdsws04) @ 1373779900 - in COMMISSIONING - attached are accepted screenshots from the OM2 test

• Back to OBSERVING @ 1373780325

- The ETM cameras have both been crashing on nuc 26 - Tagging CDS

- Leaving H1 to Ryan S. going on a 3.5 hour lock stretch

LOG:

No log for this shift.

Following the lockloss from an EQ, H1 is currently sitting in OMC WHITENING waiting for the violins to damp before we go back into NLN.

This time focusing on the 1.5 to 3.5 Hz band to resolve the structure around 2.6 Hz.

The noise injection ran between 1373756179 (2023/07/18 22:56 UTC) and 1373758142 (2023/07/18 23:28 UTC)

Not sure if what we see is real, but here's a fit, in s-domain, of the plant (optics plus suspension, with the controller divided out)

z = [-0.33515061+16.35437768j, -0.33515061-16.35437768j,
        -0.88008293+11.64561682j, -0.88008293-11.64561682j,
        -0.60031816 +3.15253939j, -0.60031816 -3.15253939j,
        -0.74195821 +2.5870795j , -0.74195821 -2.5870795j ,
        -0.70804008 +0.43354112j, -0.70804008 -0.43354112j]
p = [-0.57517567+17.98772839j, -0.57517567-17.98772839j,
        -0.11588748+16.31442876j, -0.11588748-16.31442876j,
        -0.55863455+15.02245062j, -0.55863455-15.02245062j,
        -0.19628544 +6.5741992j , -0.19628544 -6.5741992j ,
        -1.37239773 +2.79248047j, -1.37239773 -2.79248047j,
        -0.33923225 +2.70011481j, -0.33923225 -2.70011481j,
        -1.05551599 +0.j        , -0.12652314 +0.j        ]
k = -126469.31513966424

on cdsws04, there is a script running that will step the darm offset up and down for a few minutes, then step up the heat on om2, wait two hours for the thermal transient, and repeat this process 4 times.

The DARM offset steps will cause an SDF diff that will knock H1 out of observing, after it finishes each set of darm offset steps and move om2 the operators can take us back to observing.  the om2 heater will cause some SDF diffs which can be accepted for tonight. 

If the operators need to stop the script (if there is a reason to stand down or if H1 losses lock) you can hit control c on the terminal on cdsws04. 

This script also sets the DARM offset TRAMP to 5seconds, I've accepted this in SDF for now but it will go back to 1 second next lock.

Perhaps unsurprisingly given its previous history, the strong 1.6611 Hz comb that disappeared (alog 69791) in late May has resurfaced. It shows up clearly in Fscans; I did some additional digging and it looks like the first traces appear on June 27th in the 12:00-14:00 UTC range. This corresponds in time with some of the work described in alog 70849, but OM2 heater changes don't account for the previous disappearance of the comb; Sheila confirms that heater wasn't on earlier in May. So it's still not clear what's going on.