WP 11742

Field cabling to SQZT8 is reconnected.

Mon Mar 04 10:09:19 2024 INFO: Fill completed in 9min 15secs

Travis confirmed a good fill curbside.

FAMIS 20018

PSL incursion last Tuesday (alog76002) explains several abnormal trends happening on that day, including the rarely-done increase in pump diode currents in AMP2.

For FAMIS #26287:  All looks mostly for the last week for all site HVAC fans (see attached trends).

TITLE: 03/04 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: EARTHQUAKE
    Wind: 15mph Gusts, 14mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

• SEI_ENV Guardian node went into error March 3 at 17:43 when transitioning to EARTHQUAKE (tagging SEI)
• PSL101 dust monitor reports that levels haven't changed; likely needs a power cycle
• Tentative plan for arm gate valves to open today along with other IFO recovery activities

The air handling units at the corner station have been operating with many functions in a manual setting. This has taken automatic control away from the DDC system and made for inefficiencies throughout the system. After discussing with Richard, we have given automatic control back to the supply air temperature set point function as well as to the dampers to see what effect this has in terms of efficiency and temperature control of the LVEA. Because the dampers will now modulate more frequently, this will cause fluctuations in the vibrometers that will be evident in the trends. These changes in control will be evaluated over the next couple days to determine effectiveness.  

Trent, Georgia, and Craig

We came in to take OMC scans to determine the finesse. We wanted to take scans with the 9 and 45 MHz sidebands on and off. 

Setup:
- Took the IMC offline and ran the dark offset scripts [/opt/rtcds/userapps/release/isc/h1/scripts/dark_offsets/dark_offsets_exe.py]
- Turned on DC3 and DC4 by turning on the inputs (left on during measurements)
- Turned on the OMC ASC by changing the master gain from 0 to 0.025 (left on during measurements)
- Turned off the offset on OMC PZT2
- Ran an OMC scan [/ligo/home/trent.gayer/OMC_scans/2023_03_03_single_bounce_omc_scan.xml]

Analysis:
- Analyzed the scan with the following command [python3 /ligo/gitcommon/labutils/omc_scan/OMCscan.py 1393538828 95 "2W single bounce side bands nominal (45 @ 27.0dB, 9 @ 23.4dB)" "single bounce" --verbose --make_plots]. The data looks strange on the log scale because the signal goes negative. This script generated the first attached plot.
- Added a dodgey little offset (0.001) to OMC-dcpd_sum to fix the negative numbers
- We changed the duration time from 95 to 80 so that we only included 2 carrier peaks instead of 3. This helped with the peak identification which can be seen in the second attached plot. We also changed the gps time seen in the following command [python3 OMCscan.py 1393542033 80 "2W single bounce side bands nominal (45 @ 27.0dB, 9 @ 23.4dB)" "single bounce" --verbose --make_plots]

What's the finesse:
- To calculate the finesse we ran the file [/ligo/gitcommon/labutils/omc_scan/fit_peak.py]. We had to change variables gps_start, duration, description, mode, and num_fsr since those were hard-coded in. 
- We got the third attached plot from this code.
- This plot gives two HWHM's, one from the data at 0.341 MHz and one from the lorentzian fit at 0.327 MHz. This gives two finesses: 388 using the data, 405 using the fit. We think that the fit is more trustworthy than the data because it uses more of the linewidth.
- The variance given by curve_fit within the code is 1.16E-08. Take the square root to get the standard deviation. We estimated the error to be 0.04

No Sidebands:
- We tried to find the button that turns off the 9 and 45 MHz sidebands were unsuccessful. In the meantime, we decided to just change the RF set for both sidebands to 4dBm. This is the lowest the sliders could go.
- The fourth attached plot shows the signal with and without the sidebands

Sun Mar 03 10:08:56 2024 INFO: Fill completed in 8min 52secs

Following up the recent measurement (alog75927) the dip in the middle of the SHG sinc function seems real. SHG was locked when the data was saved and the dip in the ndscope wasn't a result of data averaging. I'm taking another set of measurements with more data points to confirm. The measurement will take about 5 hours. The start time was ~00:20.

This morning's usual conda update, which runs at 1200 UTC, seems to have uninstalled all packages from the CDS conda environment (the default environment) on opslogin0.

A re-run of the update process at 1800 UTC restored the packages. 

The reason for the uninstall isn't known, and the update process reported no errors.

After a recent update to opslogin0, mentioned in this alog, some users had frequent session lock ups when changing focus or pasting text into the nomachine client.

On Friday at 2030 UTC, we reimaged opslogin0 back to Debian11 and reinstalled software.

Opslogin0 was brought back into service at about 2330 UTC.

Sat Mar 02 10:08:57 2024 INFO: Fill completed in 8min 54secs

The pressures:
HAM7: ~4.55E-7 Torr
HAM8: ~1.1E-6 Torr
Corner: ~1.0E-7 Torr
EX: ~1.3E-8 Torr

Today's activities:
- EX RGA was done, and it was found satisfactory
- EX large ion pump (IP12) was valved in, and the pressure immediately fell to 1.3E-8 Torr from 2.2E-8
- EX further schedule: Turbo pump valve-out: 3-4; RGA scan #2: 3-4; GV20 open: 3-4

- The HAM8 RGA bakeout was ramped up, will be on throughout the weekend
- The HAM7 RGA bakeout was also ramped up, and similarly stays on throughout the weekend - the bake will be finished on Monday morning
- Corner & Filter cavity further schedule: Turbo pumps valve-out: 3-4; RGA scan #2: 3-4; GV5 & GV7 open: 3-4; HAM7 and HAM8 valve-in: ~3-6. Note: the bottleneck is the stabilization of the large ion-pumps. If that doesn't happen until 3-4, the opening of the GVs needs to be shifted later
- GV7 all metal valve was opened, the AIP was already able to take over the pumping

Post EX Vent PCAL EndX Station Measurement
A rare Non Tuesday PCAL End station measurement was done on leap day Feb 29th 2024, the PCAL team(    
Francisco L., Julian G, & Tony S.) went to EndX with Working Standard Hanford aka WSH(PS4) and took an End station measurements.
The EndX Station Measurement was 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 11:45 am.
Note:
After the normal measurement.

Measurement Log

First thing we did is take a picture of the beam spot before anything is touched!
We expected the beams to move due to the the vent, and it does seem like both beams have moved. It may be neccisary for us to adjuct the beams. I believe the distance between the holes on this target is 5mm center on center.

Martel:
Martel Voltage source applies voltage into the PCAL Chassis's Input 1 channel. We record the GPStimes that a -4.000V, -2.000V and a 0.000V voltage was applied to the Channel. This can be seen in Martel_Voltage_Test.png. 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.

Plots while the Working Standard(PS4) is in the Transmitter Module during Inner beam being blocked, then the outer beam being block, followed by the background measurment: WS_at_TX.png.

The Inner, outer, and background measurement while WS in the Receiver Module: WS_at_RX.png.

The Inner, outer, and background measurement while RX Sphere is in the RX enclosure, which is our nominal set up without the WS in the beam path at all.:  TX_RX.png.

The last picture is of the Beam spots after we had finished the measurement. I did not attempt to adjust the beam positions.

All of this data is then used to generate LHO_EndX_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.

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

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

Obligitory BackFront PS4/PS5 Responsivity Ratio:
PCAL Lab Responsivity Ratio Measurement:
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

Alphatrends

This adventure has been brought to you by Francisco, Julian, & Tony Sanchez.

TITLE: 03/01 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

OMC measurements ongoing. RGA work throughout site today. Gate valves set to open Monday morning.
LOG:                                                                                                                                                                                                                                                                                 

I made a LOCK_PMC state in SQZ_MANAGER guardian. The LOCK_PMC state is between LOCK_TTFSS and LOCK_SHG states. The LOCK_PMC state is copied from LOCK_SHG state, but I commented out the PZT checker because the PMC_PZT_OK function is not defined now.  

[Sheila, Jennie, Elenna]

Here are some notes about how we by-hand improved the OMC alignment

• Sheila centered the beam on AS_C using SR2 movements by hand
• Sheila ran AS centering loops for WFS A and B until the beam was centered, then turned them off
• we noticed half the range on the OMC suspension is in use on T2 and T3, so Jennie moved OMC sus in pitch to reduce the drive
• Jennie used OM2 for QPD B alignment, use OM3 for QPD A alignment- centered the beams on each QPD by walking the suspensions in pitch and yaw
• Sheila quote to explain the process further: "this is a screenshot I took after I moved OM2 yaw to center OMC QPD B and OM3 yaw for OMC QPD A, with the OMC suspension offsets small. This means that we are off center on the AS WFS DC, but I put offsets into them so that we could close the AS centering loops. Turning on the AS centering loops didn't suppress the 0.5 Hz motion much. Even though the QPDs are fairly close now before turning on the ASC loops, the OMC suspension still saturates in pitch when we turn them on."
• with sensor correction on, things improved because there was less movement overall in the beam
• the results of these movements are shown in the attached screenshot (this is the screenshot referenced in the quote above)
• Sheila successfully ran the OMC ASC and they converged without saturation
• Second screenshot shows the results of running OMC ASC
• I next pico-motored to center the beam on AS A and B in pitch and yaw
• Once I centered the beam, I engaged the DC3 and DC4 loops to check they would run without any issues. They ran just fine so I again turned them off and disabled the picomotor

As a final check I turned on both OMC ASC and AS WFS centering and the loops converged appropriately.

J. Kissel, L. Dartez

%%%%% Executive Summary %%%%%%
Remeasured OMC DCPD electronics chain electronics, including compensation, post Jan/Feb OMC swap. There's a small, 0.3% drop in magnitude below 25 Hz. The first line of suspicion is that the environmental or electrical conditions surrounding the new style of transimpedance amplifier, even though the circuit and enclosure itself hasn't changed, but the investigation has just started.

%%%%% More Info %%%%%%

As y'all know, we swapped out the OMC in Jan / Feb 2024 (see highlights in LHO:75529). 
That means we have brand new gravitational wave DCPDs. However, it's *only* the DCPDs that have changed in the GW path. Remember, as of O4, the PD's transimpedance amplifier (TIA) is now inside a separate podded electronics box () that encloses a brand-new style of TIA (see T1900676 and G2200551). This need not -- and hasn't -- changed with the swap, where it used to need be changed because the TIA was built in to DCPDs in pre-O4 OMCs. 

So, in principle, we've "just" disconnected the old PDs, and reconnected the new PDs, to the same electronics. As such we don't *expect* the frequency response of the signal paths to change.

However, Keita reports, for the first time in history, that there're no electrical issues with the OMC sensors after the OMC swap in January (LHO:75684). While there have not been issues with the DCPDs themselves, per se, recall, for example, problems in the past including issues with shorts to electrical ground of the OMC's PZTs (IIET:12445). Keita did report that, during this Jan/Feb 2024 vent that he found and mitigated some grounding issues with the preamp though -- the 3 MHz SQZ side-band pick off of the gravitational wave DCPDs had shown some signs of electrical short to ground. Quoted from LHO:75684:
    Inside the chamber on the in-vac preamp, the DB25 shell is connected to the preamp body (which is isolated from the ISI via PEEK spacer). At first DB25 shell and the preamp body was shorted to the ISI table, but this turns out to be via 3MHz cable ultimately connected to the in-air chassis. As soon as both of the 3MHz cables were discunnected from the in-air chassis, preamp body as well as the DB25 shell weren't conducting to the ISI table any more.
I interpret this to mean that there's a *potential* that the electrical grounding on board the OMC and in the GW signal path of the TIA *has* changed from "there used to be an issue" to "now there is no issue."

So with uber-careful, precision calibration group hat on, I repeated the remote, full-chain measurements of the OMC DCPD GW path -- including the digital compensation for their frequency response -- that I took on July 11 2023 -- see LHO:71225.

Attached are the results -- the magnitude of the transfer function -- for DCPD A and DCPD B. There are three traces:
    - The former measurement with the previous OMC DCPDs, on 2023 Jul 11.
    - The first measurement with the new OMC DCPDs connected, on 2024 Feb 22 (last week Thursday)
    - The second measurement with the new OMC DCPDs connected, on 2024 Feb 26 (yesterday, 4 days later)

We do see some small change ([3.05e6 / 3.04e6 - 1]*100 = 0.3% reduction) in the magnitude below about 25 [Hz].

Preliminary investigations cover a few things that might cause this. Because of where the "wiggle of change" is happening at 25 [Hz] -- right at the RLC complex poles, I immediately suspect the environmental sensitivity of giant ~2.4 [Henry] inductors and/or the electrical grounding situation surrounding the TIA. 

Regarding the environmental situation:
    - The OMC and HAM6 are back mostly at ultra high vacuum (~1e-6 [Torr], when its typically 1e-7 [Torr]) :: (so, any physical distortions of the enclosure that would change the geometry of inductor should be similar) 
    - The TIA has been powered on for several days even prior to the 2024 Feb 22 measurement :: (so the dominant thermal load on the circuit -- the bias voltage -- should have had time to thermalize), and 
    - LVEA temperatures are stable, albiet 2 [deg C] cooler  :: (I'm not sure if a 2 [deg C] in the external environment will have such an impact on the PDs)

Of course, it's an odd coincidence that both DCPDs chain response changed in the same direction and magnitude -- maybe this is a clue.
The fact that the 2024-Feb-22 and 2024-Feb-26 measurements agree indicate that:
    - The change is stable across a few days, implying that
    - The TIA circuit has been on for a while, and circuit is thermalized

Also attached are trends of these environmental conditions during the 2023-Jul-11 and both 2024-Feb measurements.

Also also attached are the two relevant MEDM screens showing the OMC DCPD A0 filter bank configuration during the DCPD A measurement (OMC DCPD B0 is the same), and the Beckhoff switch states for the excitation relay in the TIA and the whitening gain relay in the whitening chassis.

%%%%% What's next? %%%%%%
    (1) Ask Keita / Koji / Ali some details about the DCPD chain that I've missed having been out.
        (a) Are you sure you plugged in the transmitted PD into DCPD A and the reflected PD into DCPD B, the configuration we'd had with the previous OMC?
        (b) When were the electronics powered on?
        (c) Can you confirm that other than the DCPDs and the cable connecting them to the TIA, no electronics have changed?

    (2) Using the same remote measurement, configure the system to measure the TIA response by itself to see if there's a change and if so if it matches this overall chain change.

    (3) If (2) doesn't work, use the remote measurement tool to measure the TIA and the Whitening together, take the ratio of (3)/(2) to see if the whitening chassis response has somehow changed.

    (4) If the answers to (1), (2), or (3) don't solve the mystery, or provide a path forward, then we ask "does this *matter*?" A reminder -- any change in the frequency dependence of the OMC DCPD GW path electronics that's not compensated is immediate and direct systematic error in the overall DARM calibration if not accounted for. So the question is does 0.3% error below 25Hz matter, or is it beneath the uncertainty on the systematic error in calibration that's present already for other reasons? To answer this question, we'll resurrect code from G2200551, LHO:67018, and LHO:67114 which creates an estimate of the impact on the calibration's *response* function systematic error, i.e. creating an "eta_R." 

    (5) If the resulting estimate of eta_R is big compared with the rest of systematic error budget, then it matters, and we're left no other course of action than to out to the HAM6 ISC racks with our trusty SR785, remeasure the analog electronics from scratch, fit the data, and update the compensation filters a la LHO:68167.