Closes FAMIS26298

Laser Status:
    NPRO output power is 1.824W (nominal ~2W)
    AMP1 output power is 64.37W (nominal ~70W)
    AMP2 output power is 137.4W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 23 days, 21 hr 37 minutes
    Reflected power = 22.08W
    Transmitted power = 104.2W
    PowerSum = 126.3W

FSS:
    It has been locked for 0 days 11 hr and 13 min
    TPD[V] = 0.804V

ISS:
    The diffracted power is around 2.2%
    Last saturation event was 0 days 11 hours and 13 minutes ago

Possible Issues:
    AMP1 power is low, there was a step down about 47 days ago.
    PMC reflected power is high, it appears to have been rising for the past >2 months.

TITLE: 09/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

• We've been locked for 9:45
• The wind has calmed down, we survived an earthquake 3 hours ago (5.2 from Tonga)

TITLE: 09/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: High winds this evening which possibly contributed to the one lockloss. Relocking was automated and otherwise a quiet shift.

• 22:59 - H1 starts observing
• 23:33 - Dropped observing from SQZ PMC unlocking from PZT volts bottoming out (tagging SQZ)
  • Guardian brought everything back automatically
• 23:36 - Resumed observing
• 03:53 - Lockloss - alog80202
• 04:49 - Resumed observing

LOG:

No log for this shift.

Lockloss @ 03:53 UTC - link to lockloss tool

No extremely obvious cause, but seeing as winds have recently gusted up to over 30mph and multiple suspensions seem to have started shaking about a second before the lockloss, my initial assumption is that this was wind-related.

Range had also started dropping for about 30 minutes prior to the lockloss, possibly due to the higher winds? (trend attached)

TITLE: 09/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Three lock losses during my shift. Two of them are unknown. All reacquisitions have been fully auto. SR3 oplev sums are low since the SR3 move last week. Plans to fix this next maintenance day.
LOG:

• 1530 Out of Observing for calibration
• 1600 Starting commissioning
• 1809 Lock loss
  • Full auto, no initial alignment reacquisition
• 1953 Lock loss
  • ALS Y had some odd glitches caused a few lock losses. Tens of minutes later, the polarization of ALS Y and X started to change drastically. This caused the guardian to turn on the controller and adjust it. No idea why the polarization would act like this (screenshot attached). Eventually, after some lock losses at PRMI, everything worked itself out and the IFO made it up. I never touched anything, this was all fully auto without an initial alignment.
• 2201 Lock loss
  • Full auto relock
• 2259 Observing

Samantha Callos, Robert Schofield

We identified 3 peaks (26.4 Hz, 27 Hz, and 29.5 Hz) in DARM resulting from HVAC systems and the CS Chiller; 1 peak between 26.4 Hz and 27 Hz remains unidentified. See Fig. 1.

The first peak at 26.4 Hz's source has been found to be the office HVAC system, as shown in Fig. 2. There are two gaps corresponding to when Robert shut down the HVAC system (from alog 79888). Fig. 3 shows the peak at 26.4 Hz disappears in DARM for when the office HVAC is off vs when it is on.

The second peak varies between 26.5 Hz and ~26.7 Hz. It has yet to be identified, but we do know:

• It has a fundamental harmonic at 13.3 Hz.
• Its strongest, higher harmonics are its 3rd (53.2 Hz) and 6th (133 Hz) harmonic.
• It turns off and on all the time.
• It is seen by both accelerometers and microphones.
• It is seen everywhere.
• Places to look for it next include:
  • LSB
  • LExC
  • Elsewhere?

The third (27 Hz) peak's source is the mini splits HVACs controlled by the downstairs thermostat of the CER, as shown in Fig. 4 when the CER HVAC was shut down (alog 80049). It also shows the second round of shut downs of the office HVAC from alog 79888 which reconfirms the first peak. Fig. 5 shows the peak in the mics disappearing when the "downstairs" bank of the mini splits in the CER were turned off.

The fourth peak's source is the CS main chiller unit, Fig. 6, at 29.5 Hz. This shut down was done by Robert on June 29th, 2024 (alog 78749). A microphone placed across the road from the chiller pads showed that the 29.5 Hz peak seen in the permanent microphones is much louder near the chillers (see Fig. 7).

Finally, in Fig. 8, the coherence between DARM and floor accelerometers is shown for the peaks mentioned above.

FAMIS27798

I ended up not adding any water to either of the chillers since they both looked near the top of their range. The filters looked good, both the mesh and socks. The dixie cup was dry. Sheet updated.

TITLE: 09/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY: H1 just made it back to observing minutes before the start of my shift following what sounds like a straightforward reacquisition.

• Wind and ground motion low
• All other systems nominal

Closes FAMIS 26009

Nothing looks out of the ordinary/weird and measurements are comprable to the last weekly check done (alog 80081)

1410818533

This one has our normal ETMX glitch and a slight DARM wiggle, but we still have no idea why.

Vicky, Camilla, Naoki, Sheila

After our first trial of running ADS for OMC 3 MHz to align ZM5+6 (80114), we came up with a hypothesis of why this didn't maximize squeezing.  We are trying to maximize the 3MHz Q signal, while the I signal is servo's.  Changing the demod phase of the 6MHz rotates the IQ ellipse, in general anti-squeezing is at the demod phase where Q is maximized and squeezing is near the phase where Q is minimized, but because the 3MHz is off resonaonce in the OPO the best squeezing is slightly away from the minimum. 

If alignment changes didn't change the squeezing angle (for a fixed demod phase), then running ADS to maximize the 3MHz Q signal should be increasing the throughput of 3MHz, which would mean that the OPO is better aligned to the OMC.  But, we see that changing the alignment changes the squeezing angle.  This means that moving the alignment to maximize RF3 would only work as an alignment servo if the RF3 demod phase were updated to keep the squeezing angle constant.

So our plan for today was to run the ADF servo to feed back to RF6 demod phase and keep the squeezing angle correct while we run ADS to adjust the alignment of ZM5+6.  The servos worked fine, but again didn't give us good squeezing.  We think this is because the ADF servo didn't actually do a good job of keeping the squeezing angle set to minimize shot noise.

We ran ADS for 3MHz Q to ZM5+6 and the ADF servo to adjust RF3 demod phase based on H1:SQZ-ADF_OMC_TRANS_SQZ_ANG, which moved ZM5 pitch by -19, ZM5 Y by +3urad, ZM6 P by -135 urad, and ZM6 Y by -5 urad, and moved H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG by -45 degrees.  After this finished we ran SCAN_SQZANG to readjust the squeezing angle (RF6 MHz) to minimize shot noise at 300 Hz, which indicated that the demod phase change we needed to compensate for the alignment shift was actually only 25 degrees.  So, thinking about ZM6 P, we see that an alignment would require a 0.2 degree shift in demod phase, and also causes a similar sized error in the squeezing angle read out by the ADF. 

After all this, we went back to our best squeezing by running scan alignment and scan sqz angle, then moved ZM6 by -100 urad and re-ran scan sqz angle, we needed to shift the 6MHz demod angle by -16.4 degrees.

The line heights of some of the PCAL lines in the cleaned channel have been much higher than actual at the begining of todays' locks (attachment 1). The relock yesterday didn't have it (attachment 2). Looks like this was potentially fixed a month ago - alog79558, but perhaps the locks from today are too short?

No obvious cause for the 1410810810 lock loss. The lock lost tool tagged FSS oscillations, which do seem present, but the lock loss was very fast. There was no DARM wiggle as we often see, or movement in the ETMX.

-Mattia, Sheila

We have written a python script to compute the full matrix of power spectral densities and cross-power spectral densities between a given channel, i.e., DARM, and a set of auxiliary channels. The code can be find at this repository https://git.ligo.org/mattia.emma/cross_psd  which includes a README file describing how to run it.

The main arguments the user has to pass are the start time (in GPS time) and length of the data to retrieve from gwpy, a list of channel names and the starting frequency for the strain plots.

The code creates five different types of plots using the coherence and cross-power spectral density matrix. The final result of the code is a coefficient for each frequency value expressing the algebraic sum of the contributions of all the auxiliary channels to DARM considering the cross-power spectral density terms. It also computes the coherence between the single auxiliary channels and the DARM channel, which are the diagonal terms in the cross-power spectral density matrix.

The five kinds of plots are:

1. The cumulative coherence. The sum of the coherence coefficients of the single auxiliary channels with DARM. As we add more and more channels to the sum, one can notice from the plot that the value of the cumulative coherence goes above one, which is unphysical. This motivates the inclusion of the cross-power spectral density terms to account for the correlation between the auxiliary channels.
2. The cumulative strain contribution. Plot of the DARM strain and the iterative contribution of the selected set of channels to the strain. For example 3_<Channel_name> means that the strain contribution was computed using three auxiliary channels and the added channel compared to the previous plot (2_<Channel_name>) is <Channel_name>. This plot has only two lines.
3. Strain_<number>.   Similar to 2 but with as many lines as in <number> plus the DARM strain to show how increasing the number of included channels saturates the DARM strain.
4. Strain_comparison_<channel_name_1>_<channel_name_2>. Similar to 2 but including  the DARM strain and only two lines. One showing the cumulative contribution to the strain until <channel_name_1> and one adding to this <channel_name_2>.
5. Single_coherence_<channel_name>. A plot of the coherence between the DARM channel and the <channel_name>.

All of these plots can also be created using as a main channel any auxiliary channel instead of DARM, e.g., if one would like to study the correlation between auxiliary channels. Each plot name also includes the start and end GPS time of the data used for them.

Comments are welcome. As a next step we would like to implement interactive plots to allow the user to include/exclude lines from the plots.

J. Kissel, O. Patane

A follow-up from yesterday's work on installing the infrastructure of the upgrades to the ETM and TMS watchdog systems, in this aLOG I cover with what I've filled out the infrastructure in order to obtain the calibrated BLRMS that forms the trigger signal for the user watchdog.

Remember, any sensible BLRMS system should 
    (1) Take a signal, and filter with with a (frequency) band-limiting filter, then
    (2) Take the square, then the average, then square root, i.e. the RMS, then
    (3) Low-pass the RMS signal, since only the "DC" portion of the RMS has interesting frequency content.

As a bonus, if your signal is not calibrated, then you can add 
    (0) Take the input to the band limiting filter, and calibrate it
(and through the power of linear algebra, it doesn't really matter whether you band-limit first and *then* calibrate)

This screenshot shows the watchdog overview screen conveying this BLRMS system.

Here're the details of the BANDLIM and RMSLP filters for each of the above steps:
    (0) H1:SUS-ETMX_??_WD_OSEMAC_BANDLIM_?? 
             FM6 ("10:0.4") and FM10 ("to_um") are exact copies of the calibration filters that are, and have "always been" in the OSEMINF banks. These are highlighted in the first attachment in yellow. 
             FM6  :: ("10:0.4") :: zpk([10],[0.4],1,"n")    :: inverting the frequency response of the OSEM satellite amp frequency response
      FM10 :: ("to_um")  :: zpk([],[],0.0233333,"n") :: converting [ADC counts] into [um] assuming an ideal OSEM which has a response of 95 [uA / mm], differentially readout with 242 kOhm transimpednance and digitized with a 2^16 / 40 [ct / V] ADC.

    In addition, I also copied over the GAIN from the OSEMINF banks and copied these over as well such that each OSEM trigger signal remains "normalized" to an ideal 95 [uA / mm] OSEM. These are highlighted in dark green in the first attachment.


    (1) H1:SUS-ETMX_??_WD_OSEMAC_BANDLIM_?? 
             FM1  :: ("acBandLim") :: zpk([0;8192;-8192],[0.1;9.99999;9.99999],10.1002,"n") :: 0.1 to 10 Hz band-pass

    (2) This is a major part of the upgrade -- the front-end code that does the RMS was changed from the nonsense "cdsRms" block (see LHO:1265) to a "cdsTrueRMS" block (see LHO:19658)

    (3) H1:SUS-ETMX_??_WD_OSEMAC_RMSLP_??
             FM1  :: ("10secLP") :: butter("LowPass",4,0.1) ::  4th order butterworth filter with a corner frequency at 0.1 Hz, i.e. a 10 second Low Pass.
        This is highlighted in magneta in the second attachment. These are direct copies from other newer suspension models that had this infrastructure in place.
           

I've committed the filter files to the userapps repo,
    /opt/rtcds/userapps/release/sus/h1/filterfiles/
        H1SUSETMX.txt
        H1SUSETMY.txt
        H1SUSETMXPI.txt
        H1SUSETMYPI.txt
        H1SUSTMSX.txt
        H1SUSTMSY.txt
are all committed as of rev 27217.

All of these settings were captured in each model's safe.snap. I've not yet accepted them in the OBSERVE.snaps.