Naoki, Sheila, Vicky remotely

We looked through the SQZ slow controls channels and saw that there were 30 unmonitored channels in the observe.snap, we've monitored many of them.  The two attached screenshots show the before and after list of unmonitored channels.  We've left unmonitored the sqz angle, and various channels that will be different lock to lock.  

This means that now, if the OPO pump ISS is turned off as it was last night (71497, 71493) we will be knocked out of observing.  Oli has also added a diag main message for this situation (71509), so the operators will get a notification of what has happened.  

In general, this problem may be caused by some issue that needs to be solved, like those that Vicky looked into this morning.  In general, the problem is that there is less light available for the pump than the ISS is trying to servo to, so we can get back to observing by reducing the power requested, following instructions in 70050.  This will require accepting some SDF diffs, and will probably result in a lower level of sqz than if the ISS was working correctly at it's normal power.  

For now, let's try this approach to this problem, that we get knocked out of observing, the operator gets a message from diag main, and tries to follow the instructions to reset the ISS and go back to observing.  The next day someone can look at what happened with the green power. 

Last night and this morning, we've turned the OM2 heater back on.  Our range didn't improve, however.  We still had in place the AS36Q yaw offset from last Thursday (alog 71309).  At the start of our Wed commissioning period, I turned that offset off.  This improved our range back to ~140 Mpc according to CAL-DELTAL on the wall, but our range is still not back to where it was the last time we had OM2 hot. We may need to think about more alignment changes / checks.

I added a message to DIAG_MAIN (see attached highlighted) that will tell us if the squeezing ISS pump is off. References this alog (70050), which has instructions on what to do if this occurs.

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.

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.

We were adding a new filter module for annular CO2 heating to the TCS simulation model. Both filter modules are added to the substrate diopter calculation, but their inputs are switched using the CO2 mask. For now the same filter as for central heating has been loaded. This needs to be updated.

The calibration factors are -11uD/W and -13uD/W for ITMX and ITMY annular heating, respectively, see alog 66617.

We also noticed that the filter module name for H1:TCS-SIM_ITMX_SUB_DEFOCUS_FULL_SINGLE_PASS was too long and shortened it to H1:TCS-SIM_ITMX_SUB_DEFOCUS_FULL_SGL_PASS. However, we added the following EPICS channels H1:TCS-SIM_ITMX_SUB_DEFOCUS_FULL_SINGLE_PASS_OUTPUT and H1:TCS-SIM_ITMX_SUB_DEFOCUS_FULL_SINGLE_OUT16 back in so medm screens and trend will stay unchanged.

The following 2 lines have been added to the CDS_CA_COPY guardian list:

• H1:TCS-SIM_ITMX_SUB_CO2_MASK_SEL H1:TCS-ITMX_CO2_FLIP1MON
• H1:TCS-SIM_ITMY_SUB_CO2_MASK_SEL H1:TCS-ITMY_CO2_FLIP1MON

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.