JoeB, M. Wade, A. Viets, L. Dartez

Maddie pointed out an issue with the computation of the kappa_TST starting since 10/13. After looking into it a bit further, Aaron found a noisy peak at 17.7 Hz just above the kappa_TST line (which is very close at 17.6 Hz). It turns out that the peak has been there for a while, but it got louder on 10/13 and has been interfering with the kappa_TST calculation since then. 

For a quick reference take a look at the top left plot on the calibration summary pages for October 12 and October 13. Taking a look at the DARM spectra for those days, JoeB, noticed a near 17.7Hz on 10/12 at about 23:30 UTC (darm_spect_oct12_2023.png). Interestingly, he noted that it looks like the 17.7Hz line, which was present before the glitch, got louder after the glitch (darm_spect_oct13_2023.png). 

I've attached an ndscope screenshot of the moment that the glitch happens (darm_17p7hz_glitch_kappaTST_uncertainty.png). Indeed, there is a glitch at around 23:30 on 10/12 and it is seen in by the KappaTST line and the line's uncertainty. Interestingly, after the glitch the TST line uncertainty stayed high by about 0.6% compared to its value before the glitch occurred. This 0.6% increase pushed the mean KappaTST line uncertainty above 1%, which is also the threshold applied by the GDS pipeline to determine when to begin gating that metric (see comment LHO:72944 for more info on the threshold itself).

It's not clear to us what caused the glitch or why the uncertainty stayed higher afterwards. I noticed that the glitch at 23:30 was preceded by a smaller glitch by a few hours. Oddly, the mean KappaTST uncertainty also increased (and stayed that way) then too. There are three distinct "steps" in the kappaTST uncertainty shown in the ndscope I attached. 

I'll note that I initially looked for changes to the 17.7Hz line before and after the TCS changes on 10/13 (LHO:73445) but did not find any evidence that the two are related.

==
Until we identify what is causing the 17.7Hz line and fix it, we'll need to do something to help the kappaTST estimation. I'd like to see if I can slightly increase the kappaTST line height in DARM to compensate for the presence of this noisy peak and improve the coherence of the L3 sus line TF to DARM.

Between 1383589977 and 1383590038 I adjusted the OMC 3MHz demod phase from 132 degrees to 147 degrees.  The OPO lost lock (PZT at 110V) at around 18:00:39 UTC, the squeezer relocked itself but took a few tries to get the FC handoff to IR.  After that we went back to observing but the squeezing was poor, so I adjusted the SQZ angle in lock.  

I don't understand why the sqz angle should be different after that relock.

Closes FAMIS 20000

The only thing to note that I noticed is that the FSS, PMC relock count and ISS sat count was reset on 11/04.

TITLE: 11/09 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.51 μm/s
QUICK SUMMARY:

Observing and have been Locked for 17.5 hours. Secondary useism has been going up over the past 12 hours.

TITLE: 11/09 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 164Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

Busy start to the shift with commissioning finishing immediately followed by calibration measurements, going to observing and then Robert running some fan-OFF tests while in Observing.  Then after that it was a fairly nice & quiet shift.  The range is much better tonight than last night!
LOG:

• 2357 Commissioning ends
• 0000-0036 Calibration measurement
• 0037 Back to OBSERVING
• 0101-0132 Turning OFF Corner station Axial/turbine fan tests (Robert)
  • Did (2) ~10min OFF-tests
  • 0102 FMCS Reheat Zone 3A alarm (111.77degF)
  • 0121 FMCS Reheat Zone 3A alarm (111.48degF)
  • 0122 PSL Dust Alarm (340counts at 300nm)
  • 0131 VacPrep Dust Alarm (3300 counts for 300nm)

H1's been locked the whole shift thus far (or ~11hrs). 

Robert ran tests of turning off Corner Station fans. LVEA temperatures are oscillating in recovery of this and will continue to do so on multi-hour timescale (see attached photo for temps of the last 5hrs in the LVEA).

This evening, in the on-going program to evaluate noise produced by the HVAC, I shut down just the 5 operating CS turbines, in AH1,2,3. The figure shows the range increase (about 4 Mpc), DARM spectra (decrease between 20 and 200 Hz), and vibration spectra.

Start shutting down: 1:00 UTC Nov 9

Start  turning on: 1:10

Start shutting down: 1:20

Start turning on: 1:30

During commissioning today I swept low frequencies (10-60 Hz) with the large speaker in the input arm, with the shaker on the PSL table, and with the shaker on the IMC tube, searching for how the CER ACs couple. More later.

Immediately after commissioning work, jumped into running calibration measurements (broadband [~5min] + simullines [~25min]) from roughly 0000-0036utc.

• Following instructions (link)
• 0000 ISC LOCK to NLN_CAL_MEAS
  • Screenshot not taken
• 0006 - 0011 Broadband measurement run
  • Measurement at:  /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231109T000527Z.xml
• 0013 - 0035 Simullines measurement
  • gps start time:  GPS: 1383524041.078507 (perhaps a second or two before this time)
  • gps end time:  GPS: 1383525357.891477
  • Files writtten to (5) subfolders here:  /ligo/groups/cal/H1/measurements

TITLE: 11/09 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 6mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY:

• Walked in as Commissioning by Jenne/Camilla was finishing up.
• TJ mentioned to keep an eye on LVEA temperatures due to variations in the last 6hrs.
• Immediately jumped into running a calibration measurement when Commissioning ended!  (Corey, remember to not hit "CTRL C"!!!  This was apparently my issue last time I ran one.)
• After Calibration, went back into Observing (and then Robert did a Corner Station Axial Fan-OFF test).

Jenne, Naoki

Today we tried to measure the AS36 and AS72 sensing matrix to see if we could replace the AS36 sensing with AS72 for MICH ASC. Currently, we use AS36 for MICH, AS45 for DHARD, AS72 for SRC1, but the AS RFPDs are tuned for RF36/45, not for RF72 and the AS72 does not have good SNR for SRC1. If we could replace the AS36 with AS72 for MICH, we can tune the AS RFPDs for RF45/72 to have good SNR for both MICH/SRC1.

We tried to measure the AS36 and AS72 sensing matrix by injecting a 8.125 Hz line in MICH P. To avoid the ASC loop suppression, first we tried to turn on the notch filters at 8.125Hz in all ASC. There is a script to turn on/off the notch filters of all ASC in userapps/asc/h1/scripts/notch_8Hz_ON_OFF.py. We tried to run the script in the terminal, but the terminal does not recognize the ezca, so we moved to the guardian shell by typing guardian -i ISC_LOCK. In the guardian shell, we copied line 1-26 in the notch_8Hz_ON_OFF.py to turn on notch filters.

Then we started to inject a 8.125 Hz line in MICH_P_EXC with awggui. As shown in the attached figure, we set the amplitude 0.001 and kept increasing the overall gain to 10000. We clearly saw the 8 Hz line in AS36 sensors, but not in AS72. Since the 8 Hz excitation seems not to have a good SNR for AS72, we will excite the MICH/SRC1 in DC and see the response of AS36/72 sensors next time.

After the measurement, we copied line 29-49 in the notch_8Hz_ON_OFF.py to turn off the notch filters.

Naoki, Sheila, Camilla

In alog74059, it was pointed that the 80Hz BLRMS increased by 1.5dB after FC2 centering on October 27th, and this could be due to FC detuning change caused by the FC2 centering. Today we changed the FC detuning by +- 20 Hz from the nominal -28 Hz, but the nominal detuning seems already optimal as shown in the attached figure. We left the FC detuning at nominal value -28 Hz.

I went back and forth (~5 mins each) with the BS M2 coil drivers between their nominal low noise state, and their higher noise higher range state. 

When in the higher noise state (state 2), there seems to be consistently higher noise between about 55 Hz up to 100 Hz. In the attached plot the blue / green is the nominal low noise state, while red / pink is the high noise state.

I'll work on making this an actual noise projection that we can include in the noise budget, using Craig's code for quad PUM noise as a guide.

We were in the high noise state 2 from 20:56:45 - 21:04:00.  Then in low noise state from 21:06:10 - 21:11:15 (there's a glitch during this time).  Back to high noise from 21:13:20 - 21:19:40 (there's a small glitch during this time).  Back to low noise from 21:21:50 - 21:28:00.  All times UTC on 8 Nov 2023.  After this I handed back to Robert.

Oli Patane, Jeff Kissel

Continuing through our plan(T2300376) for the new O5 A+ suspensions (HRTS, HATS, and BBSS), we have finished, compiled, and installed the Simulink models for HRTS and BBSS onto the Triples and BSC teststands respectively. The models that we installed can be found in /opt/rtcds/userapps/release/sus/x1/models/x1sus{bs,lo1}.mdl.

Also, we are close to done creating the medm suspension overview screens for HATS and HRTS (/opt/rtcds/userapps/release/sus/common/medm/hxts/SUS_CUST_{HRTS,HATS}_OVERVIEW.adl). They still need some editing, but here are the current state of the medm screens for the HRTS and the HATS.

Naoki, Camilla

Last Friday 73773 Nov 3 (black trace, IFO locked 6h30), Naoki found the MICH FF had degraded since measured on Oct 27 (pink trace IFO locked 23h). Today we measured the MICH FF using /lsc/h1/scripts/feedforward/MICH_excitation_comparison.xml after the IFO had been locked 3 hours  (yellow trace) and 7 hours (grey trace). See attached.

MICH FF effectiveness improves as the IFO thermalizes (compare yellow to grey) but also seems to be degrading over ~days (compare grey to black). MICH FF last tuned Oct 12 73420.

Double EndY Station Measurement!
We did the Same Measurement twice in the same configuration to determine if there would be any changes from one hour to the next.   

First ENDY Station Measurement:
During the Tuesday maintenace, the PCAL team(Rick Savage & Tony Sanchez) went to ENDY with Working Standard Hanford aka WSH(PS4) and took End station measurements.
The ENDY Station Measurements were carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by 10:30 am.
First Measurement Log
 

First thing we did is take a picture of the beam spot before anything is touched!

Martel votlage injection into the DAQ:
Martel_Voltage_Test.png graph. We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the above document.

After the Martel measurement the procedure walks us through the steps required to make a series of plots while the Working Standard(PS4) is in the Transmitter Module. These plots are shown in WS_at_TX.png.

Next steps include: The WS in the Receiver Module, These plots are shown in WS_at_RX.png.

Followed by TX_RX.png which are plots of the Tranmitter module and the receiver module operation without the WS in the beam path at all.
The last picture is of the Beam spot after we had finished the measurement.
All of this data is then used to generate LHO_ENDY_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.
Note: both measurements are on this Report.

NONE of this data and Analysis has been commited to the SVN as I have been Locked out of the SVN.
But it would have gone here: https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_ENDY/

Then we did the measurement again,
Second Measurement Log
Martel plot
WS @ TX
WS @ RX
TX & RX
LHO EY PD Report V2 for the Second measurement
Final Beam Spot

PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf

NONE of this lab data and Analysis has been commited to the SVN.

Obligitory BackFront PS4/PS5 Responsivity Ratio:
A WSH/GSHL (PS4/PS5)BF Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages2.pdf
avg_voltages2.pdf
raw_ratios2.pdf
avg_ratios2.pdf

PS4_PS5 AlphaPrime Lab Trends

This adventure has been brought to you by Rick Savage & Tony Sanchez.

TITLE: 11/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 7 hours. We've been commissioning since 12PT (20UTC), that is now wrapping up but we are going to run a calibration measurement.
LOG:

• 1710 Observing
• 2000 Out if observing for 4 hours of commissioning

The lock-loss-alert system is now running the old, non-Twilio code. Twilio is not able to send text messages until we verify our 'brand' with The Campaign Registry. Today was a registration deadline, so their verification service is very busy.

This means that we are back to using the cell phone providers (Verizon, ATT, etc) to send the SMS texts. I would recommend everyone who depends upon alert texts to send a test message before their shift starts.

This also means that unfortunately voice calling is not available, email and texts only.

Once Twilio is able to send our texts again, I'll switch back to the new software.

I'm not yet sure why, but we have abnormally high coherence with MICH ASC today.  I wonder if this is related to our low PRG, and the fact that the power recycling gain seems to be about 3x more wobbly than normal.

I disabled 1Hz LPF which was somehow present in the SUM (not NSUM) of the QPDs and WFS DCs that are used for normalization of PIT and YAW. These LPFs ruin the rejection of the intensity noise for QPDs and WFS DCs even at 1Hz.

Here's a list of the filter modules where the 1Hz LPF (all FM1) was disabled: H1:ASC-OMC_[AB]_SUM, H1:ASC-REFL_[AB]_DC_SUM, H1:ASC-AS_[AB]_DC_SUM, H1:ASC-AS_C_SUM, H1:ASC-POP_[AB]_SUM, H1:ASC-[XY]_TR_[AB]_SUM.

Note: Without LPF, when large clipping action is going on and SUM goes very small, I can imagine that PIT and YAW become somehow worse than with LPF. If that ever becomes a problem, enable 1Hz LPF.

Note 2: Green WFS DCs and QPDs don't have the BPF for SUM.