WP 12675
WP 12676
ECR E2400330
Drawing D0901284-v5
Modified List T2500232

The following SUS SAT Amps were upgraded per ECR E2400330. Modification improves the whitening stage to reduce ADC noise from 0.05 to 10 Hz. The EX PUM SAT Amp was NOT upgraded. 

F. Clara,  J. Kissel

I wrote this state at the end of 2023, to automate the relocking of the PLL through turning on the Beckoff autolocker and inputting crystal frequency values to search around. These frequencies it uses to search are assuming the values will be close to zero, so it assumes there isn't an offset alog81425.

We've been going into this fault state more often recently. This state is more of a band-aid for this issue than an actual fix to whatever's happening with the PLLs. ALS-Y sees this issue more frequently than ALS-X, each arm is locking at a different frequency these days, around 0 Hz for Xarm and around 100 for Yarm. Yarm seems more dynamic than Xarm for its' frequency, it has been changing more than Xarm over the past year.

I've updated the code today to use a dictionary with a list for each arm from the single list it was using so hopefully it will make it a little faster.

I'm writing some code with Tonys' statecounter to see exactly how many times we are going into this state for each arm over the past months, and years.

FAMIS tasks 31305 and 31320, WP 12682

Procedure checklist for both stations completed.  No issues were identified at this time.

MX: Scroll pump hours: 228.5
       Turbo pump hours: 140
       Crash bearings: 100%

EX: Scroll pump hours: 7155.9
       Turbo pump hours: 1108
       Crash bearings: 100%

This morning I performed an on-table alignment of the FSS RefCav beam, since yesterday's T.O.O. remote alignment tweak did not get the cavity transmission back above 0.8 V.  As usual, I began with a power budget of the FSS beam, and left the ISS ON to keep the power in the FSS path stable:

• FSS In: 277.5 mW
• AOM In: 276.8 mW
• AOM Out, Single Pass: 196.5 mW
  • Single Pass Diffraction Efficiency: 71.0%
• AOM Out, Double Pass: 53.3 mW (135.3 mW)
  • Double Pass Diffraction Efficiency: 27.1 % (68.9%)
• EOM Out: (136.0 mW)

Immediately it looks like the beam alignment through the AOM in its second pass is way off, but I've never seen the double pass diffraction efficiency this low so I decided to check alignment through the components in the beam path from the AOM to the RefCav before I started making adjustments.  Sure enough, the beam was being clipped by the iris that sits between M22 and L11 (this iris block the undesired orders output from the AOM).  I opened the iris and measured the power again, this is the number in parenthesis in the above bullets.  So the diffraction efficiencies look around normal, but the beam was not well aligned to the iris.  This was also seen in the EOM, as it was off alignment as well (but not enough that it was clipping the beam).  I went ahead and slightly adjusted the AOM to maximize the single pass diffraction efficiency, and M21 to maximize the double pass diffraction efficiency, with the following results:

• AOM Out, Single Pass: 200.1 mW
  • Single Pass Diffraction Efficiency: 72.3%
• AOM Out, Double Pass: 137.5 mW
  • Double Pass Diffraction Efficiency: 68.7%

At this point, I adjusted the iris position to center it horizontally, and then adjusted M22 to get the beam a bit better centered vertically (iris is on a fixed mount with no vertical adjustment, and I didn't want to go too far and cause problems downstream; not super important that the beam be centered, as the iris is left open enough to pass the desired beam while blocked the others).  This done, I opened the iris just enough to let the desired beam pass while still blocking the others.  The EOM alignment was adjusted until the beam was centered on both the input and output EOM apertures; I measured 137.3 mW transmitted through the EOM, so free of clipping (the slight difference in double pass AOM Out and EOM Out is normal, the power meter never reads exactly the same).  I then manually adjusted the picomotor equipped mounts (M32 and M47) to recenter the beam on the front and back of the RefCav input iris, then locked the RefCav.  It locked without issue, so I proceeded to use the picomotors to fine tune the beam alignment into the RefCav.

• Initial RefCav TPD: 0.719 V
• Final RefCav TPD: 0.816 V

To end the work in the enclosure I unlocked the RefCav, aligned the reflected beam onto the RFPD, then relocked the RefCav and calculated the visibility:

• Unlocked: 1.150 V
• Locked: 0.207 V
• Visibility: 82.0%

I then turned the ISS OFF (so it's not actuating on the beam power while the enclosure is returning to thermal equilibrium after the incursion), cleaned up equipment I had used, placed the enclosure into Science Mode, and left the LVEA.  I checked on the PSL after about 45 minutes and things appeared to have settled out, so I did one final remote beam alignment of both the PMC (to account for any alignment changes during the incursion) and the RefCav.  The PMC alignment was done with the ISS OFF, I then turned the ISS ON (RefSignal of -1.99 V, diffracted power moving between ~3.6% and ~4.0%) to record the final PMC Trans and Refl values and tweak the RefCav alignment.  Results:

• PMC
  • Initial (ISS OFF)
    • Trans: ~104.9 W
    • Refl: ~23.4 W
  • After Alignment (ISS OFF)
    • Trans: ~105.9 W
    • Refl: ~22.7 W
  • Final (ISS ON)
    • Trans: ~106.0 W
    • Refl: ~22.8 W
• RefCav (ISS ON)
  • Initial TPD: ~0.836 V
  • Final TPD: ~0.838 V

This ended the RefCav tune up for today.  I'm not sure why the iris was clipping the beam, I have not seen that in the time I've been working on the PSL.  Best guess I have is drift of mirror M22 due to slow temperature changes, since the diffraction efficiencies of the AOM were still pretty good and this is the only mirror between the AOM and the iris (could also be the PBS cube PBS01, but I don't think so as there was not an increase in the power of the rejected polarization beam).  We will continue to monitor this as we usually do, but things are in decent shape right now.  This closes LHO WP 12683.

This morning I used a new method of testing airflow and found one power supply in the corner that we missed with thermal testing.

Mezzanine:
C5-U30-RHS Stuck Fan, -24V Digital, S1201957.  Current draw is <1A, no overheating detected, it could have been like this for a while.
This supply services H1-SUS-R5 ISC SC Digital.  This is paired with the +24V in this rack.

All remaining supplies, good temperature, good airflow, no oscillations.

EX:
All supplies, good temperature, good airflow, no oscillations.

EY:
All supplies, good temperature, good airflow, no oscillations.

Tue Jul 15 10:07:36 2025 INFO: Fill completed in 7min 32secs

Gerardo confirmed a good fill curbside.

This morning, I completed the quarterly maintenance of the air handler at the FCES. There were no deficiencies noted. I also completed the thermal imaging of the circuit breaker panels at the end stations. Similarly, there were no deficiencies noted. At both end stations, the panels dedicated to CDS equipment had breakers that showed slightly elevated temperatures, but this is normal. No breakers were observed to be over 30 C.

TITLE: 07/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY: We've only been at low noise for 20 min, but magnetic injections are running now. Maintenance day today.

Workstations were updated and rebooted. This was an OS packages update.  Conda packages were not updated.

IFO is in ENGAGE_ASC_FOR_FULL_IFO and LOCKING

Got called at 2:30 AM after guardian failed to lock ALS during 30mph wind gusts (which seems to have been the cause of the lockloss itself) The cause for the call itself was that ISC_LOCK had stalled after a few attempts in which I simply unstalled it. However, DRMI was still having issues locking and alignment looked poor. A 5.7 EQ (+ aftershock) delayed my running initial alignment but it ran automatically after the EQ passed. Locking is so far fully automatic and DRMI locked with a much better signal. The lockloss stalling issue doesnt seem to have recurred while relocking.

TITLE: 07/15 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Lockloss at the beginning of the shift, high winds made relocking a struggle till they calmed down in the last 1.5 hours. We've been locked for about an hour as of 05:00 UTC.
LOG:

• 00:11 UTC Observing

• 00:23 UTC lockloss after only 15 minutes

  • The winds are teetering around 30-40 mph for gusts and 20-30 mph for the 3 minute avg

  • We've lost lock in the same spot twice during CARM_OFFSET_REDUCTION with a large DHARD oscillation and a "Low recycling gain" warning. Potentially meaning alignment is off somewhere?

  • 02:39 - 02:57 UTC Initial Alignment

  • 04:08 UTC Observing

Originally, the suspensions who have already had their satamps swapped for ECR E2400330 had their compensation filters updated to a generic 5.31:0.0969 zp filter that would get put in using my script /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_generic_filterupdate_ECR_E2400330.py (r12449).

However, Jeff went through the entire set of new satamps and tested each channel to determine the actual transimpedance and frequency response of each channel. We can use the measured frequency response to replace the generic filter with more precise compensation filters, so I have made a script that does just that -  it updates the compensation filters in OSEMINF FM1 for whichever suspension you want with the more accurate zero and pole values for each channel. This script can be found at /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py (r12449).

I have used this script to update the compensation filters for the suspensions that have already had their satamps swapped (see txt file): SR3, SRM, BS, PRM, PR3, ITMX, ITMY, SR2. These new filters have all been loaded in.

Running the Best Possible Filter Update Script

This script can be found at /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py. To run it, all you need to do is:

• Make sure the txt measurement files exist for that optic in /ligo/svncommon/SusSVN/sus/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Results/
• In the PythonTools directory, do python3 satampswap_bestpossible_filterupdate_ECR_E2400330.py -o (or --opt), followed by the name of the optic or optics. If updating for multiple optics at once, put a space between each
• Once the txt filter file has been updated, you must then go to the suspension's GDS screen to check the filter diffs and load in the new filters. Before loading in the new filters, make sure we are in DOWN and put the suspension into SAFE

Examples:

python3 /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py --opt SR2

Or to update multiple suspensions at once:

python3 /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py -o SR2 ITMX PRM

Running the Generic Filter Update Script

In case the measurements aren't done but you would like to update the compensation filters, you can use the generic filter script, satampswap_generic_filterupdate_ECR_E2400330.py. To run this script:

• In the PythonTools directory, do python3 satampswap_bestpossible_filterupdate_ECR_E2400330.py -o (or --opt), followed by the name of the optic or optics. If updating for multiple optics at once, put a space between each
• Once the txt filter file has been updated, you must then go to the suspension's GDS screen to check the filter diffs and load in the new filters. Before loading in the new filters, make sure we are in DOWN and put the suspension into SAFE

00:23 UTC lockloss

Ivey,

When fitting transfer functions for the OSEM estimator, I tested several transfer function fitting programs to find one that is both accurate and efficient.

A brief side note: In the 6/24 M1-to-M1 dataset that Oli took, we observed an unexpected right-hand zero near 1.2 Hz (see attached plot), where we had expected a left-hand zero. After comparing with the 4/15 and 4/18 datasets, we found no corresponding right-hand zero, suggesting the 6/24 zero is likely due to noise.

I wrote a document highlighting the pros and cons of each of the fitting programs here:
TF Fitting Comparison (Google Doc)

The programs include:

Vectfit3 (I recommend using this with strong inverse weighting): Uses vector fitting. Created by Bjorn Gustavsen. Not built into MATLAB. Performs nearly identically to Vectfit4, but has more documentation.

Rational: Built-in MATLAB function. Uses the AAA algorithm.

Spectrumest: Built-in MATLAB function. Chooses an internal algorithm based on the data.

Rationalfit: Built-in MATLAB function. Uses vector fitting.

Generally, these programs fit poles and end behavior well, but often compromise the accuracy of the fit in the zero regions. In these cases, we often have to manually refine the fit in the zero regions. However, Vectfit3 performs very well on the 6/24 M1-to-M1 and SusPoint-to-M1 datasets when used with strong inverse weighting. We were able to produce better fits than manual methods, and expect this approach to be more efficient for future use.

Example plots are available here:
Plot Comparison Slides (Google Slides)

Attached is the MATLAB code used for the M1-to-M1 fits.
To use vectfit3, you must download the package
here.
All other functions used are built into MATLAB's toolboxes.

Measurement file paths:

 /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-06-24_1700_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_L_to_Y_0p02to50Hz.xml 
 
 /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/2025-06-24_1900_H1SUSSR3_M1_WhiteNoise_L_to_Y_0p02to50Hz.xml 

Lockloss @ 21:56 UTC after almost 2 hours locked - link to lockloss tool

This appeared to line up with an incoming M5.8 EQ from Japan, but the R-waves hadn't fully arrived and the ground wasn't moving all the much at the time. Also, the first errant thing happening I can see is a hit on DARM, which seems unusual.

I previously noted a glitch about 30 seconds before lockloss in LOWNOISE ASC, 85685. However, we had two more locklosses from this state last night and I do not see such a glitch so that is a random coincidence. One of those locklosses appears to be caused by an earthquake. However, since 6/11, we have had 9 locklosses in this state that occurred exactly 47 seconds into the state, which seems suspicious, one of those occurred last night, and the lockloss with the glitch was the same.

This seems to be coincident with the engagement of a few DHARD P filters:

2025-07-14_14:26:54.641531Z ISC_LOCK executing state: LOWNOISE_ASC (522)
2025-07-14_14:26:54.642230Z ISC_LOCK [LOWNOISE_ASC.enter]
2025-07-14_14:26:54.655894Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656325Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656732Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657043Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657438Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657892Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.658134Z ISC_LOCK [LOWNOISE_ASC.main] timer['LoopShapeRamp'] = 5
2025-07-14_14:26:54.658367Z ISC_LOCK [LOWNOISE_ASC.main] timer['pwr'] = 0.125
2025-07-14_14:26:54.783581Z ISC_LOCK [LOWNOISE_ASC.run] timer['pwr'] done
2025-07-14_14:26:59.658298Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:26:59.719537Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_GAIN => 200
2025-07-14_14:26:59.720456Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW1 => 256
2025-07-14_14:26:59.846249Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW2 => 20
2025-07-14_14:26:59.971686Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y => ON: FM3, FM8, FM9
2025-07-14_14:26:59.972384Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW1 => 5392
2025-07-14_14:27:00.098073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW2 => 4
2025-07-14_14:27:00.223528Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y => ON: FM1, FM3, FM4, FM5, FM8
2025-07-14_14:27:00.224135Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224497Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224868Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225188Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225433Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:10.225728Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:10.281803Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_TRAMP => 5
2025-07-14_14:27:10.408120Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 16
2025-07-14_14:27:10.533563Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => OFF: FM9
2025-07-14_14:27:10.534285Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW1 => 256
2025-07-14_14:27:10.660088Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 4
2025-07-14_14:27:10.785453Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => ON: FM3, FM8
2025-07-14_14:27:10.786315Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_GAIN => 208
2025-07-14_14:27:10.786535Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:15.786858Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:15.847152Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_TRAMP => 5
2025-07-14_14:27:15.847580Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_GAIN => 5
2025-07-14_14:27:15.848666Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_GAIN => 5
2025-07-14_14:27:15.848917Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:20.849050Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:20.906577Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907206Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907700Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.908422Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.908830Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909148Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909562Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909789Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:30.910055Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:30.968166Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_P_GAIN => -0.2
2025-07-14_14:27:30.968527Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_Y_GAIN => -0.2
2025-07-14_14:27:30.968806Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_L_GAIN => -0.2
2025-07-14_14:27:30.969073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_R_GAIN => -0.2
2025-07-14_14:27:30.969343Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_T_GAIN => -0.2
2025-07-14_14:27:30.969606Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_V_GAIN => -0.2
2025-07-14_14:27:30.969838Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:40.970003Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:40.972085Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW1 => 1024
2025-07-14_14:27:41.097962Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW2 => 4
2025-07-14_14:27:41.223313Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P => ON: FM4, FM8
2025-07-14_14:27:41.223637Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:41.593743Z ISC_LOCK [LOWNOISE_ASC.run] Unstalling IMC_LOCK
2025-07-14_14:27:41.765955Z ISC_LOCK JUMP target: LOCKLOSS

I will take a look and see if there is anything unstable about these filters. Whatever is occurring seems to be too fast to be seen in the ASC signals themselves, and at first glance I don't see anything strange in the suspension channels either.

DHARD FM4 is engaged with a 10 second ramp- this is a change I made on 6/11: 84973 because we had lost lock on that day twice in the same spot. Two of the locklosses at 47 seconds occurred before that change. Then, later that day on 6/11 I reengaged a boost in DHARD P, which only has a 5 second ramp, 84980. Engaging that boost shouldn't be unstable, but maybe something bas occurrs when they ramp at different times. I'm lengthing the ramp to 10 seconds.

Randy moved the 3IFO ISS PD array (S1202968) crate from MY storage to the OSB yesterday (WP). I opened the crate, moved the transport/storage container to the vacuum lab and optics lab to inspect. It was in a good shape except that some upgrade parts weren't there. Since I'm already forgetting what happened to other units, here's the summary.

First about parts.

• 3 of 4 units require replacement of the new PD array plate (D1300322), but we (are supposed to) have parts. I'm not sure which units were meant to be ready for installation, but if we replace the PD array plate, realignment must be done.
• None had the QPD tilt but we have enough parts for this.
• 1 of 4 units had the low QPD, i.e. QPD plane is much closer to the PSL than array PDs. No parts were located for this, and mostly for this reason we'll have to live with just two spares for 3 instruments instead of 1 spare per each instrument.
• Blue glass beam dump plates were only found for two units. The remaining two don't have these. This might be OK, the optics are easy to transplant when we pull the in-chamber unit.

Next, the summary per unit.

• Good spare S1202965 already has all upgrades. It's the only one with an updated PD array plate already installed upon initial inspection. Also see alog 83077.
• Second apare S1202966 will be OK (PD array plate will be replaced, QPD will be tilted, will use parts from the damaged unit of parts from the damaged unit S1202967 for some other things) except that blue glass beam dump optics aren't found. Also see alog 85019.
• 3IFO S1202968 will be OK (PD array plate will be replaced, QPD will be tilted).
• Damaged spare S1202967 cannot be restored in short order as that would mean locating or making/procuring new parts to make QPD higher (because the dirty parts from this unit will be reused for the second spare), C&B all new and existing metal parts, cleaning and reinstalling all optics, inspecting the surface of all 8 PDs to find particulates AND realigning the entire unit, which will be extremely time and labor intensive. Because of this, we'll only have 2 spares for three IFOs (H1, L1 and 3IFO) at least for now. Also see 82731.

Here's the thing about the PD array plate D1300322 (see attached). The updated version has a wider 100deg conical bore for larger beam clearance because it was found at some point (ECR E1400231) that the clearance was too small for the original bore and the reflection of some PDs will hit the bore wall at an glazing angle instead of hitting the beam dump. It's also easy to imagine that if you fiddle with the alignment for the production unit in chamber, INPUT light on some PDs will hit the bore wall first before hitting the PD surface.