Sheila, Daniel, Vicky

Given our squeezer ASC offloading issues, Sheila and I have guardianized our SQZ ASC offloading in SQZ_FC and SQZ_MANAGER. See updated graphs; currently offloading states are only selectable when ASC is not running, but this is subject to change as we go. Guardians tested while IFO was down from an earthquake, and the following states work to offload and clear ASCs. Working guardians with offloading checked into svn version 25670.

• SQZ_FC - from "DOWN", can request "FC_ASC_OFFLOADED". When FC-ASC is not running, this will first offload the FC ASC to FC1/2, ZM3 sliders, then clear history on ASC filter banks.
• SQZ_MANAGER - from "SQZ_READY_IFO" can request "SQZ_ASC_OFFLOADED". When SQZ-ASC is not running, this will offload SQZ-IFO ASC (AS42) to ZM5/6 sliders, then clear history on ASC filter banks.

I also cleaned up SQZ_MANAGER a little; now only relevant states for observing are requestable in the drop-down menu. In addition, today Daniel has LHO:69732 which makes it so we only need to accept FC1/2 + ZM slider values in SDF models once after offloading, and it saves it to both observe and safe.snaps.

Ryan, Jane, Adrian, Anamaria, Robert

We have completed the main program of PEM injections. The more than 130 hand-tuned injections are detailed in the attached spreadsheet, which, along with the automated injections, will be analyzed in the comming days. We did not find troubling magnetic coupling, but we did find certain areas, particularly EX and the PSL, where ambinet vibration levels can produce noise in DARM. For some of the sensitive frequencies we found, e.g. 4Hz, and 10Hz, the ambient vibration level is dominated by the HVAC, particularly, turbulence in the turbine plenums and in the chilled water pipes. Tomorrow, I plan to experiment with the turbine flows and the pump VFDs to see if we can reduce vibration levels at the sensitive locations and frequencies with reasonable changes in the air and water flows. 

IFO lost lock at 2:06 for unkown reasons. After doing an IA, I tried relocking only to be delayed by a 7.7 EQ in New Caledonia...holding in DOWN while we ride it out.

We had a GC outage around 6:15pm PDT (1:15 UTC).  During this time we moved the network connection to a new router.

The network is looking good.  We will monitor for a day or two before we close the work permit.

DQ Shifter: Derek Davis

Summary:

• The "observing mode flag" DMT-ANALYSIS_READY was incorrectly defined during May 10-12 
  • This problem did not impact the definition of GDS-CALIB_STATE_VECTOR
• PEM week started; injections picked up by numerous Detchar tools, including HVeto
• The potential source of 4.1 Hz glitching was identified: (69578)
• Observing mode is engaged consistently overnight
• Mid-frequency glitching from 50-100 Hz overnight on multiple days
  • Attached plots show glitching on May 8 and May 13
  • May be related to nearby construction

The full report can be found here.

J. Kissel

We're finally to the point where we are able to review the results of the online measures of the systematic error (the new-to-O4 PCALX lines at the below listed frequencies), and we're finding that we need more SNR, (increased coherence, decreased uncertainty). 

Recall, we first set these heights blindly in July 2022 (LHO:64214), but live front-end processing of the data didn't appear until May 03 2023 (LHO:69285) -- from which the data is stored "in the frames" via EPICs channels, which means we can look at, and trend the results and compare against other IFO channels with all the usual tools.
This week, we've begun reviewing those results as the *modeled* systematic error (ldas-jobs.ligo-wa.caltech.edu/~cal/) starts to become trust worthy (post yesterday's calibration pipeline update; LHO:69696), and we're trying to validate the "grafana" live processing of these lines (calibration-monitoring).

I've increased three of the four the line height amplitudes by a factor of 3 and one by 4, as indicated below:

PCAL                    CAL-CS DEMOD    Frequency    Amplitude     Amplitude    Ratio 
OSC Number              Number          (Hz)         New (ct)      Old (ct)     (New/Old)
  PCALX_PCALOSC4        LINE5           33.34        40     10           4.0x
  PCALX_PCALOSC5        LINE6           53.67        30     10           3.0x 
  PCALX_PCALOSC6        LINE7           77.73        30     10           3.0x
  PCALX_PCALOSC7        LINE8          102.13        60     20           3.0x

These changes have been in place as of the NOMINAL_LOW_NOISE segment that started on 2023-05-18 22:30 UTC.

Attachments:
2023-05-18_PCALX_LineHeight_Increase.png 
    This shows the change in amplitude of these four lines. 
        - RED -- the new H1 amplitudes
        - BLUE -- the corresponding L1 amplitudes (they have better noise at the lower frequency end, so they don't need to drive as hard to achieve the same SNR, or coherence, or uncertainty)
        - MAGENTA -- the old H1 amplitudes

2023-05-18_PCALX_LineHeight_Increase_12hourtrend.png
    This shows how the measurement of the systematic error, and its corresponding uncertainty has improved.
    The lowest panel shows that the uncertainty on the above mentioned DEMOD output has decreased from 4-5% to 1-1.5%. as expected.
    One can see by the magnitude (top) and phase (middle) plots that one can much more clearly read off the value of the trend of the systematic error.

2023-05-18_PCALX_LineHeight_Increase_SDFAccept.png
    This shows that not only have I SDF accepted the values of the new SINGAIN in the PCALX SDF system (not shown), I've also matched the amplitude increase DEMOD LO gains in the CALCS model (shown).

Here's the latest list of calibration lines:
Freq (Hz)   Actuator               Purpose                      Channel that defines Freq             Changes Since Last Update (LHO:69555)
15.6        ETMX UIM (L1) SUS      \kappa_UIM excitation        H1:SUS-ETMY_L1_CAL_LINE_FREQ          No change
16.4        ETMX PUM (L2) SUS      \kappa_PUM excitation        H1:SUS-ETMY_L2_CAL_LINE_FREQ          No change
17.1        PCALY                  actuator kappa reference     H1:CAL-PCALY_PCALOSC1_OSC_FREQ        No change
17.6        ETMX TST (L3) SUS      \kappa_TST excitation        H1:SUS-ETMY_L3_CAL_LINE_FREQ          No change
33.43       PCALX                  Systematic error lines       H1:CAL-PCALX_PCALOSC4_OSC_FREQ        Amplitude Change; THIS ALOG
53.67         |                        |                        H1:CAL-PCALX_PCALOSC5_OSC_FREQ        Amplitude Change; THIS ALOG
77.73         |                        |                        H1:CAL-PCALX_PCALOSC6_OSC_FREQ        Amplitude Change; THIS ALOG
102.13        |                        |                        H1:CAL-PCALX_PCALOSC7_OSC_FREQ        Amplitude Change; THIS ALOG
283.91        V                        V                        H1:CAL-PCALX_PCALOSC8_OSC_FREQ        No change
284.01      PCALY                  PCALXY comparison            H1:CAL-PCALY_PCALOSC4_OSC_FREQ        No Change
410.3       PCALY                  f_cc and kappa_C             H1:CAL-PCALY_PCALOSC2_OSC_FREQ        No Change
1083.7      PCALY                  f_cc and kappa_C monitor     H1:CAL-PCALY_PCALOSC3_OSC_FREQ        No Change
n*500+1.3   PCALX                  Systematic error lines       H1:CAL-PCALX_PCALOSC1_OSC_FREQ        No Change (n=[2,3,4,5,6,7,8])

On Tuesday, there was a swap from Fan 1 to Fan 2 at End-X (alog 69635) in attempt to reduce the vibration levels at EX, and in turn prevent 4.1. Hz noise from appearing. Looking for periods of 4.1 Hz noise after this swap, there appears to be few, if any, cases of 4.1. Hz noise in the last 2 days. An example daily spectrogram is attached showing the 4.1 Hz noise before the swap. I've also included a daily spectrogram from today, which shows one time period that may have weak 4.1. Hz noise still present. 

More data is still needed to understand the full effect of this swap, but preliminary checks suggest that even if the 4.1. Hz isn't gone completely, the rate is lower compared to previous days in ER15. 

TITLE: 05/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
SHIFT SUMMARY:

PEM Week Continues

GC Network outtage at 6pm PT tonight.
LOG:

• 1554 H1 out of OBSERVING due to Squeezer
• 1554 PEM Team Take Over until 9pm
• 1632-1653 Checking failed back-up chiller at EX (bubba)
• 1650-1700 DiagMain work (tj)
• 1736-1742 PEM equip trip to lvea (robert)
• 1755 MX PEM set up (robert)
  • 1906 Back out (robert)
• 1750 GDS calibration pipeline restart (jamie)
• 1809 Nuc30's DARM needed to be restarted due to crashing again. 
• 1819 Cleaning of H2 room (kim)
• 1902 Y-arm jog (eadie)
• ~1922 Out to LVEA & then FCES (robert.anamaria.maryjane)
• 1925 lockloss (there were OMC overvflows & also PEM team was heading to LVEA/FCES)
  • LOCK#1:  1927 start
  • Had PLL Error with beat note out of range error for the X-arm (symptom:  Error note for ALS + on ndscope the TRX channel was very noisy & no showing the usual flashes)
  • With Camilla we saw Austin's alog and made a few changes on ALS_CUST_LASER_LOCKING.adl for X-arm:
    • reverted Beatnote RF min to -15.0 (from -10.0)
    • Took Crystal Frequency to -200
    • After this it eventually locked.
    • Then ALS_XARM continued with INCREASE_FLASHES
  • DRMI:  looked dead and off in yaw.  Moved PRM off in -Yaw to help a little, but ended up going to PRMI.
  • PRMI:  tiny locks, small adjustments made to PRM in yaw and then moved to BS in -yaw direction.  Then PRM locked.
  • 2059 Lockloss at OMC WHITENING (Lockloss tool failed for this one, and for this one PEM team was moving shaker equipment from EX to EY)
  • LOCK#2:  2100 start
  • No intervention
  • 2142 Lockloss (for no obvious reason) at TRANSITION FROM ETMX
  • LOCK#3:  2146 start
  • No intervention
  • Saw several "GDS/DAQ glitches" on DARM FOM
  • Stuck in OMC WHITENING (at 30min and counting)
  • 2305 Handed off to Austin
• 2001-2043 Sqz script work (Camilla)
• 2022 Moving PEM/shaker equip from EX to EY (anamaria,robert)
• 2130 Increasing PCal lines (jeff)
• 2147 Hepta pump photos at mid station (gerardo)
• 2212 DiagExc work (tj)
• 2232 & 2234 Scary GDS/DAQ glitch seen on DARM FOM in Control Room!  (just as we were at last steps before NLN)

TITLE: 05/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s 
QUICK SUMMARY:

- IFO is stuck at OMC_WHITENING while violins are damping

- CDS/SEI ok

- PEM injections are currently ongoing

Script saved as /ligo/home/camilla.compton/Documents/sqz/squeezing-measurements/ script_for_no_sqz_fis_fds.py Run using 'python script_for_no_sqz_fis_fds.py -s 1368477220' where 1368477220 is gpstime to start script. Starts in No_SQZ, then goes FIS for 0, +90 +180,-90, FDS for 0, +90 +180,-90, No_SQZ, back to nominal.

Things that should be updated: nominal_clf should be the H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG we want to script to go back to at the end (current sqz angle). Now we have increased NLG, the sqz_angles should be re-found as in alog 69625.

We want 0deg (sqz) 180deg (anti-sqz) and +/-90deg (middle-sqz):

#sqz_angles = [0, +90 +180,-90] # change to SQZ-CLF_REFL_RF6_PHASE_PHASEDEG angles
sqz_angles = [[0, 161], [0, 225], [1, 97], [0, 60]] # [CLF_sign, CLF_angle]

Anamaria and I further improved the range BLRMs from alog 69619. They could be improved more but we lost lock.

• Adding 102, 177, 283Hz notches to H1:OAF-RANGE_RBP_5
• Moved the H1:OAF-RANGE_RBP_1 band stop from 19-23 to 14-18Hz. 
• Adding a slot 6 AwgLines filter for BLRMS#1,2 for to notch the CAL_AWG_LINES guardians temporary 8.825, 11.475, 15.175, 24.4Hz lines. sdf accepted.

Famis 21121
 

When I walked up to the TCSX chiller the Ruler was on the ground. But judging by the remnants of the adheisive and the Max Level sticker I'd wager that the water level was greater than 30.

I also went back to clean up the old adhesives and apply some new double sided tape to the ruler. So it should stop falling now.  

ENDY Station Measurement:
During the Tuesday maintenace, the PCAL team (Jennie W. and I) went to ENDY with WSH (PS4) and took an End station measurement.
The ENDY Station Measurement was Mostly carried out according to the procedure outlined in Document LIGO-T1500062-v15. Except for the very last measurment. Rick and I have spoken about trying to reduce the light entering the Rx Sphere during a background measurement similar to measurment #9 by placing the normal PCAL enclosure covers back on before the start of the background. I somehow misinterpreted his suggestions and put the covers on for measurement #9. This change was hand written in to the measurment document LIGO-T1500062-v15 and is attached. Once we started to do the analysis I realized that Putting the covers on for Measurement #9 was a blunder because; only the measurement #9 was covered with pannels. Which means we won't be subtracting enough light from the rest of the measurements #7 and #8. Effectively ruining this measurement. So this needs to be it's own measurement on future attempts to take backgrounds with the covers on.

Before I touched anything, I took a pictures of the beam spot.

Martel:
We started by setting up a Martel Voltage source to apply some voltage into the PCAL Chassis's Input 1 channel and we record the times that a -4.000V, -2.000V and a 0.000V signal was sent to the Chassis. The analysis code that we run after we return uses the GPS times, grabs the data and created the 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 document.

There was also another error in the data when we were at the end station taking the measurement. Which lead to the BadTimeEy.pdf which is attached. A number of the plots during the time marked on the Document either had no data or had some "disturbance" during the time indicated on the document for measurment #2. We able to "salvage" some of this data by reducing the duration of our measurements from 240 seconds to 78 seconds and change the gpstime on measurment #2 to get usable data for all plots.
New Measurement #2 GPSstart time is now: 1368291685.

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

Next steps include: 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.

All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_ENDY/

This morning, H1 was not in Observing because the squeezer was not injecting squeezing.  I requested the Sqz_manager to DOWN, then FREQ_DEP_SQZ.  That worked, and the IFO automatically flipped to Observing.

After the calibration update this morning, I need to retrain the NonSENS noise cleaning.  However, the NDS team is still in progress on understanding why we can't get past GDS-CALIB_STRAIN channels right now.  Once we can get that past data, I should be able to retrain.  Until then, the NOISE_EST is zeros, so GDS-CALIB_STRAIN_CLEAN will be the same as GDS-CALIB_STRAIN_NOLINES.

Jennie, Sheila

Sheila and I looked at the steps Elenna changed the DARM offset through, the last time the contrast defect measurement was taken (see LHO #69361). To get an idea of how much light seen at the anti-symmetric port (calibrated in terms of power into HAM6) is insensitive to DARM motion I plotted the scaling of the light at ASC-AS_C_NSUM_OUTPUT with DARM offset changing (OMC-DCPD_SUM_OUTPUT).

Attached is the plot (pdf) of total power into HAM 6 versus the power that gets through the OMC.

The uncertainty in the AS measurement is was estimated using the y cursors on ndscope (shown in png).

0.837W of power is predicted for no DARM offset, and 82% of the light coming into HAM 6 is sensed by the OMC DCPDs.

We also tried to use the total power on OMC REFL to do a similar calculation of the light rejected from the OMC that is insensitive to DARM motion but due the noise on this signal we made need bigger DARM offset steps to see a clear trend.

Since this measurement, whitening has been implemented on the OMC REFL PD by Daniel.

Code is Plot_OMC_REFL_2023-05-12.ipynb in /ligo/home/jennifer.wright/git/OMC_mode_matching/

Figure is in /ligo/home/jennifer.wright/git/OMC_mode_matching/figures

Ryan S, TJ S

Ryan and I looked into all of the symlinks for the safe and observe files as read from the target area for all of the models that are in our SDF Revert scheme. Column 4, and a bit of 5, of this table shows the awkward web that we've created over the years with some safes linked to observes and some to downs, and one the other way around. These are only a small fraction of all of the models, while we haven't gone into all of the others, I imagine the web is equally as tangled. Since we've been locking decently well and seem to have a working system, I don't think it's worth the effort and potential fallout to clean this all up, but I worry that we could definitely confused ourselves further with this inconsistent linking.

All of this stemmed from some diffs in the ISC_EX and ISC_EY (h1syseyiscsdf) that had their observes linked to their safes. I've now unlinked the safe and observe for the for these and made a new link to an observe.snap that was a copy of the safe. I then accepted the differences when we got to low noise.

Adrian, Camilla, Gabriele, Fil, Richard

While trying to track down the source of the 4 Hz bumps in DARM, Richard noticed the cosmic ray photomultiplier tube (PMT) power supply voltage display numbers were jumping around. When he reset the dial, we noticed the 4 Hz oscillations in H1:PEM-ADC_5_29_2K_OUT_DQ disappeared for a few minutes. We unplugged the power supply to the PMTs at 19:05:00 UTC and have not seen 4 Hz features in the ADC channel or DARM since. Plots of the change in ADC channel timeseries behavior when Richard first touched the power supply knobs as well as the ADC channel behavior after the power supply was unplugged are attached. A spectrum comparing the ADC power supply plugged in (blue) and unplugged (red) is attached. We had about 40 minutes to watch DARM before some commissioning tasks started and we didn't see any more bumps. Another plot is forthcoming for this...

(edit for spelling...)

Yesterday and today I made measurements of our soft yaw loops to determine why they are causing us such trouble at high power. I think our overall goal is to get to a point where we can turn them off, but in the meantime we need to stabilize them.

Both soft yaw loops are engaged at Power 25W. Yesterday we used a CSOFT Y gain of 5, but today our lock stability at 60W is thanks to a CSOFT Y gain of 20. All of these measurements were made with the new CHARD Y loop.

I have attached plots of the open loop gain of CSOFT Y and DSOFT Y at 25W, 50W and 60W. The gain for DSOFT was 100 for every measurement. These plots show that with increasing power, the peak of the loop shifts to lower frequency, and the phase slowly degrades. This is similar to the effect of high power in the soft pitch loops.

Also, the 25W and 50W measurements were made at the high bandwidth ASC state, while the 60W measurement was made at low bandwidth. It would probably have very little effect on these loops, but the amount of gain in the CHARD Y loop at 0.45 Hz changes.

Stefan and I looked at the current control filter, and have considered changing the zero at 0.3 Hz to 0.1 Hz. The resulting change to the filter can be shown here (we scaled the gain of the new filter to match at 10Hz): comparison plot. This would give us ~20 deg more phase and only 2 dB of gain difference at 0.45 Hz.

It might be worth making this change in all soft loop control filters. We will test this change after the next lockloss.

I have also copied my measurement templates over to userapps, into asc/H1/templates/ into the respective ASC dof folder. These were broadband excitation olg measurements.