WP12755 TW1 offload

Jonathan, Dave:

The offload of the past 6 months of raw minute trend data from h1daqtw1 SSD-RAID to spinning media is complete. Today I restarted daqd on nds1 to reconfigure the latest trend path and Jonathan made this change permanent in puppet. I deleted to old files from nds1 starting at 13:12 in nice mode. It completed at 15:14 (2hr 2min).

Earlier (86446) I updated the OSEM calibration for PR3, so now that that is looking better, I wanted to take the measurements that are needed to get the estimator fits.

Measurement settings:
- HEALTH_CHECK with the damping loops on
- ISI and HEPI in ISOLATED
- New OSEMINF gains (since those are now permanent)
- New DAMP compensation gains in FM7 (since those are also now permanent)

PR3 Pitch:
- Set DAMP P gain to -0.2
SUSPOINT to M1 with DAMP P gain at -0.2
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/Common/Data/2025-08-19_1745_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_{L,T,V,R,P,Y}_0p02to50Hz.xml
    r12607
Regular TFs with damping on for P with gain at -0.2
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/2025-08-19_1815_H1SUSPR3_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    r12605

PR3 Yaw:
- Set DAMP Y gain to -0.2 (DAMP P gain back at nominal of -1)
SUSPOINT to M1 with DAMP Y gain at -0.2
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/Common/Data/2025-08-19_1645_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_{L,T,V,R,P,Y}_0p02to50Hz.xml
    r12606
Regular TFs with damping on for Y with gain at -0.2
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/2025-08-19_1715_H1SUSPR3_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
    r12604

For the past three years I have been working on a branch of OMC_scan on the ligo/gitcommon/labutils repository in order to fit single boucne scans carried out with no sidebands on. In order to do this I made another function in the OMC scan class called identify_C02()

This uses the TM01 and TM02 peaks as fitting parameters to fit the non-linearity of the PZT, normally we use the 45MHz sidebands for this but when the sidebands are off we can't and so one needs to change the following variables to say which of the modes (arrange in reverse height order) are the TM01 and TM02 carrier peaks in the scan.

first_order = np.argsort(self.peak_heights)[-4]

second_order = np.argsort(self.peak_heights)[-3]

the first variable denotes the TM01 peak and the index specifies that this is the 4th highest peak in whichever scan we are looking at. The next line denotes the TM02 peak which was the 3rd highest peak in the scan we were looking at.

To specify for the code to use this C02 function, you need to call the code with the -s flag which tells the code that the sidebands were off when the scan was taken.

It is also good to run the -o flag set to 2 as this only uses a polynomial of order 2 to fit the data, otherwise it will not get a good estimate of the pzt hysteresis with only three data points (carrier, first and second order) for the fit.

As part of this merge I accidentally merged in a bunch of old files from my branch and so I have removed them.

I still have some changes to propagate to fit_peak.py and fit_two_peaks.py although since our current OMC does not have enough astigmatism to see a double peak at TM02 this is less urgent.

Tony S, Francisco L [Miriam R]

[Editors note: Added scan of procedure with notes included (there's no scanner at the ES), and the "What was done differently?" section. Also added links to some of the references.]

Measurement summary

By running es_meas.sh, we completed the measurement procedure T1500062. Measurement went ok. Results are attached in LHO_EndX_PD_ReportV5, values are within 0.10% of previous measurements, which is good for an initial review. Beams at Rx side look centered (see attached images of the power sensor, PS_BEFORE and PS_AFTER).

What was done differently for this procedure?

By design, the Pcal team follows procedure T1500062 to run an end station measurement. Recently, Miriam worked on running a shell script to acquire and save the GPS times that are requested in the procedure. This with the purpose of saving time to the user and to be less prone to user error when (1) reading and copying ten-digit long numbers from machine into paper, then (2) reading and copying ten-digit long numbers from paper into machine.

A week ago, Joe and Miriam successfully tested the shell script at LLO (L1:78065) when making the most recent Pcal ES measurement. Thus, we proceeded in testing that the program is interferometer independent.

Additionally, I decided to use ndscope instead of StripTool, since I feel more comfortable and familiar with the functions included in ndscope. The one thing we lose from StripTool is monitoring the actual value of the plotted channels -- ndscope cannot enable the cross-hair function during live plotting -- but we solved that by using the caget command in the terminal. The scope I used is saved at:

There were no issues while running the shell program. The results, as mentioned in the summary section, agree with previous measurements. The key takeaway is that the processing of data is easily done at the end station, saving us hours of work. Today's outcome, however, does not mean that a printout is not necessary. The printout can become a option for a fail-safe, in case the ES computers become compromised, and use the terminal method as default. We will have to go through at least a couple more iterations of this new program before making a final decision.

Terminal output from generate_measurement_data.py

(pcal_env) francisco.llamas@cdsdell425:/ligo/gitcommon/Calibration/pcal/O4/ES/scripts/pcalEndstationPy$ python generate_measurement_data.py
 --WS PS4 --date 2025-07-21                                                                                                                
/ligo/gitcommon/Calibration/pcal/O4/ES/scripts/pcalEndstationPy/generate_measurement_data.py:52: SyntaxWarning: invalid escape sequence '\R
'                                                                                                                                          
  log_entry = f"{current_time} {command} \Results found here\: {results_path}\n"                                                           
Reading in config file from python file in scripts                                                                                         
../../../Common/O4PSparams.yaml                                                                                                            
PS4 rho, kappa, u_rel on 2025-07-21 corrected to ES temperature 299.2 K :                                                                  
-4.702207423037734 -0.0002694340454223 3.166921849830658e-05                                                                               
Copying the scripts into tD directory...                                                                                                   
Connected to nds.ligo-wa.caltech.edu                                                                                                       
martel run                                                                                                                                 
reading data at start_time:  1439656235                                                                                                    
reading data at start_time:  1439656787                                                                                                    
reading data at start_time:  1439657190                                                                                                    
reading data at start_time:  1439657604                                                                                                    
reading data at start_time:  1439658060                                                                                                    
reading data at start_time:  1439658393                                                                                                    
reading data at start_time:  1439658575                                                                                                    
reading data at start_time:  1439659259                                                                                                    
reading data at start_time:  1439659634                                                                                                    
Ratios: -0.4616287378386522 -0.466497509893687                                                                                             
writing nds2 data to files                                                                                                                 
finishing writing                                                                                                                          
Background Values:                                                                                                                         
bg1 =        9.088424; Background of TX when WS is at TX                                                                                   
bg2 =        4.841436; Background of WS when WS is at TX                                                                                   
bg3 =        8.973841; Background of TX when WS is at RX                                                                                   
bg4 =        4.915986; Background of WS when WS is at RX                                                                                   
bg5 =        9.091218; Background of TX                                                                                                    
bg6 =        0.432428; Background of RX                                                                                                    

The uncertainty reported below are Relative Standard Deviation in percent
                                                                                                                                   [34/528]
Intermediate Ratios                                                  
RatioWS_TX_it      = -0.461629;                                      
RatioWS_TX_ot      = -0.466498;                                      
RatioWS_TX_ir      = -0.455998;                                      
RatioWS_TX_or      = -0.461669;                                      
RatioWS_TX_it_unc  = 0.077366;                                       
RatioWS_TX_ot_unc  = 0.075967;                                       
RatioWS_TX_ir_unc  = 0.068272;                                       
RatioWS_TX_or_unc  = 0.080853;                                       
Optical Efficiency                
OE_Inner_beam                      = 0.987787;                                                                                             
OE_Outer_beam                      = 0.989670;                                                                                             
Weighted_Optical_Efficiency        = 0.988728;                                                                                             

OE_Inner_beam_unc                  = 0.048451;                                                                                             
OE_Outer_beam_unc                  = 0.051954;                                                                                             
Weighted_Optical_Efficiency_unc    = 0.071040;                                                                                             

Martel Voltage fit:                                                  
Gradient      = 1636.889155;                                         
Intercept     = 0.253680;                                            

 Power Imbalance = 0.989563;                                         

Endstation Power sensors to WS ratios::                                                                                                    
Ratio_WS_TX                        = -1.077440;                                                                                            
Ratio_WS_RX                        = -1.391188;                                                                                            

Ratio_WS_TX_unc                    = 0.046697;                                                                                             
Ratio_WS_RX_unc                    = 0.038795;                                                                                             

=============================================================                                                                       [1/528]
============= Values for Force Coefficients =================                                                                              
=============================================================                                                                              

Key Pcal Values :                 
GS           =      -5.135100; Gold Standard Value in (V/W)                                                                                
WS           =      -4.702207; Working Standard Value                                                                                      

costheta     =      0.988362; Angle of incidence                                                                                           
c            =      299792458.000000; Speed of Light                                                                                       
                                  
End Station Values :                                                 
TXWS         =        -1.077440; Tx to WS Rel responsivity (V/V)                                                                           
sigma_TXWS   =        0.000503; Uncertainity of Tx to WS Rel responsivity (V/V)                                                            
RXWS         =        -1.391188; Rx to WS Rel responsivity (V/V)                                                                           
sigma_RXWS   =        0.000540; Uncertainity of Rx to WS Rel responsivity (V/V)                                                            

e            =        0.988728; Optical Efficiency                                                                                         
sigma_e      =        0.000702; Uncertainity in Optical Efficiency                                                                         

Martel Voltage fit :                                                 
Martel_gradient         =        1636.889155; Martel to output channel (C/V)                                                               
Martel_intercept   =        0.253680; Intercept of fit of     Martel to output (C/V)                                                       

Power Loss Apportion :                                               
beta          =        0.998895; Ratio between input and output (Beta)                                                                     
E_T          =        0.993799; TX Optical efficiency                                                                                      
sigma_E_T          =        0.000353; Uncertainity in TX Optical efficiency                                                                
E_R          =        0.994898; RX Optical Efficiency                                                                                      
sigma_E_R          =        0.000353; Uncertainity in RX Optical efficiency                                                                

Force Coefficients :                                                 
FC_TxPD          =        7.901498e-13; TxPD Force Coefficient                                                                             
FC_RxPD          =        6.189270e-13; RxPD Force Coefficient                                                                             
sigma_FC_TxPD          =        4.661048e-16; TxPD Force Coefficient                                                                       
sigma_FC_RxPD          =        3.277513e-16; RxPD Force Coefficient                                                                       
data written to ../../measurements/LHO_EndX/tD20250819/                    

Note: The data for this measurement, and this alog [first edition], were all done at EX!

I was able to get some testing in on the SR3 P and Y estimators today with the most up to date estimator and blend filters. There were still some filter issues at first, but thanks to all the hard work from Brian, Edgard, and Ivey, we were able to get everything working!

Each test was done with the other estimator off, so as if the other damping degrees of freedom were just their normal -0.5 gain damping.

SR3 Y Estimator
We had tested the SR3 Y estimator twice before (85615, 86319), but this should be the best case of everything for the Y estimator. Each test was 30 minutes.
Estimator filters: Clean_fits_H1SR3_Y_2025-08-05.mat (86366)
Blend filters: Estimator_blend_skinnynotch_SR3yaw_20250723.m (86265)
Tests
DAMP Y -0.1
    2025-08-19 18:22:06 - 18:52:06 UTC
DAMP Y -0.1 and OSEM Y -0.4
    2025-08-19 17:22:05 - 17:52:17 UTC
DAMP Y -0.1 and EST Y -0.4
    2025-08-19 17:52:23 - 18:22:00 UTC
Preliminary results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/Estimator/SR3_Y_EstTest_2025-08-19.xml r12603
The tests gave really nice results!

SR3 P Estimator
We have never tested the SR3 P estimator, but the Stanford peeps were able to get all the filters needed just in time for me to get a short (~7-10 mins each) set of estimator measurements.
Estimator filters: Clean_fits_H1SR3_P-08-05.mat (86430)
Blend filters: blend_SR3_pitchv1.m (86452)
Tests
DAMP P -0.1
    2025-08-19 19:17:05 - 19:25:10 UTC
DAMP P -0.1 and OSEM P -0.4
    2025-08-19 19:44:45 - 19:54:45 UTC
DAMP P -0.1 and EST P -0.4
    2025-08-19 19:33:01 - 19:44:27 UTC
Preliminary results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/Estimator/SR3_P_EstTest_2025-08-19.xml r12603
These tests don't have as high of a bin width or number of averages as the Y estimator did, but the results still show a decent decrease in noise in ADD_P_TOTAL, besides a new peak that popped up at 3.5 Hz.

Next steps:

Both P and Y estimator tests are looking pretty good, so the next steps are to test them both out while we are locked. On Thursday I'll be doing that for at least SR3 Y and P if there is time. To make sure we can transition from the regular OSEM damping to the estimator damping, I have both SR3 P and Y set to their 'DAMP P/Y -0.1 and OSEM P/Y -0.4' settings. This means -0.1 of their DAMP gains are in the DAMP filter bank, and -0.4 of their gains are in the EST_{P,Y}_DAMP_OSEM filter bank, which give us the same amount and type of damping as -0.5 gain of normal DAMP damping would give us.
On Thursday I will be able to test out the estimator by swapping the -0.4 DAMP_OSEM gain to -0.4 DAMP_EST gain.

These damping settings have been accepted in sdf

FAMIS 26546, last checked in alog86417

The script reports BSC high frequency noise is elevated for the following sensors:

ETMX_ST1_CPSINF_V2

TJ, Ryan S, Elenna

Today we (once again) took some time to try to commission the PRM ASC loop in PRMI ASC.

We locked PRMI, and I engaged the beamsplitter ASC. I was able to see by moving PRM pitch around, and watching the buildups, that the "old" error signal, REFL A RF9 I, was a great error signal and only required a sign flip.

However, PRM yaw was harder. I checked REFL A and B RF9 I and neither signal worked. I checked POP X I next, and saw that the signal worked just fine. This doesn't make a lot of sense, but it works. I updated the guardian accordingly.

To test that the guardian changes work, we brought the ISC_DRMI guardian down, which unlocked PRMI, and re-requested PRMI ASC. We fixed a few guardian errors and tried again. It worked fine.

These are the changes made:

• edited the input matrix for PRC1 pitch and yaw as stated above
• edited the PREP PRMI state to engaged DC centering on POP (DC6)
• edited LSCparams to have PRC1 set to True in PRMI ASC

Loaded and tested!

WP 12767

The EX roof weather station wind speed has been near zero since May 2025, alog 85792. The anemometer was replaced this morning.

D. Barker, F. Clara, R. McCarthy

I've made v1 of of a blend for the SR3 Pitch Estimator. It is in the SUS SVN as described below

Design 
This time I designed the OSEM path and set the MODEL path to be 1-OSEM_path.
This design is very simple to implement, hopefully it will work well and we can use this approach for other suspensions.
I designed a basic low-pass for the OSEM so that the DC position is maintained (same as yaw). This is probably not necessary because the damping filters are AC coupled, however it was useful to be able to compare the time traces when we were doing the development here, so I've included it for in the new one also. It may also be useful in case we try to do something more interesting than just AC coupled damping. The low-pass is a zero-pole pair so that it levels off to a transmission of 0.1. This is so the gap between the two resonant peaks will be well behaved. Those will cross at about 180 degrees of phase shift and make a sharp zero, and deep zeros seemed to be causing numerical issues when Oli was implementing the yaw blends. The flat bottom at 0.1 prevents that.

The next thing is to include OSEM signal at the pitch peaks. This is to help deal with errors in the models and with unmodeled inputs. At this point, the models Ivey has done for Oli's data look remarkably clean and tight, so the unmodeled inputs are my main concern. The various TFs of SR3 show that there are really just 2 modes which are mostly Pitch and those are the ones I've targeted. These blends are all based on the fits by Ivey (LHO log: 86430) and the data from Oli (LHO log 86203)

Figure 1: pitch blend filters

Figure 2: zoom in on pitch blend filters, the dashed lines are peaks of the 2 modes we are letting the OSEMs damp directly

Figure 3: OSEM path vs. the M1 plant, showing the overlap of the narrow peaks in the OSEM path with the lightly damped pitch plant modes

Figure 4: MODEL path vs. the M1 plant, showing the overlap of the very narrow notches in the MODEL path with the lightly damped pitch plant modes

Figure 5: Fit for the OSEM pitch Response of M1 to OSEM drive of pitch. The length damping is nominal (gain of 0.5) and the Pitch damping is set to 'light damping', ie 0.2 of nominal (0.1 overall)

figure 5 shows there are 4 modes visible in the M1 pitch -> pitch TFs. The first 2 are pretty well damped by the length damping control, so I'm going to let the estimator get those. I'm hoping that any unmodeled inputs will be damped by the length control, and any plant errors are small because of the length damping.

I've attached a pdf with a few other plots for reference.

Design script: blend_SR3_pitchv1.m 
in the SUS_svn at  .../HLTS/Common/FilterDesign/Estimator/   (revision 12601)

make_SR3_Pitch_blend.m: run this script to install the filters into the foton file for SR3.
This is a modification of the script make_SR3_yaw_blend.m

some other notes:

modes of the L/P plant for SR3, there are 2 combined modes, 2 mostly Pitch, and 2 mostly Length
L damping at nominal (0.5 overall)
P damping at 'light' (0.1 overall)
(Aug 5, 2025, Oli Pantane) 

for the M1 L drive to M1 L OSEM, 4 peaks are visible
black looks like the nominal damped 
peak #
1: 0.617
2: 0.734
3: 1.585
4: 2.977

in the M1 Pitch drive to M1 pitch OSEM, (L damping nominal, P 'light damping')
(to the fit)
1: 0.649  (data peak closer to 0.641)
2: 0.749  (data closer to 0.75)
3: 2.09
3: 3.44

The poles and zeros for the blend filters. Some of the Q's are pretty high, but our conversion to foton seems to be fine.

>> blend_SR3_pitchv1;
 
The OSEM filter is
 poles:
ans =
  -0.3142 + 0.0000i
  -0.4377 +13.1246i
  -0.4377 -13.1246i
  -0.3602 +21.6112i
  -0.3602 -21.6112i
 
 zeros:
ans =
  -2.0779 +20.2143i
  -2.0779 -20.2143i
  -3.6907 + 0.0000i
  -4.0312 +12.2400i
  -4.0312 -12.2400i
 
The MODEL filter is
 poles:
ans =
  -0.3142 + 0.0000i
  -0.4377 +13.1246i
  -0.4377 -13.1246i
  -0.3602 +21.6112i
  -0.3602 -21.6112i
 
 zeros:
ans =
   0.0000 + 0.0000i
  -0.0803 +21.5959i
  -0.0803 -21.5959i
  -0.0970 +13.1319i
  -0.0970 -13.1319i

I added the BS M1 Pit integrator turning on to the gen_PREP_MICH_ALIGN state of ALIGN_IFO, so that it gets turned on for both initial alignment as well as if we use CHECK_MICH_FRINGES during the full lock acquisition sequence. Hopefully during init align right now after maintenance we'll see that it's working well.

Leo, Jennie, Camilla

Followed setup instructions from 80010, with 75mW injected in the SEED beam, we had 1mW on OPO_IR_PD_DC slightly lower than last time. Also took SQZ_FC to FC_MISALIGNED.  And opened SQZ beam divertor and fast shutter. Have counts of ~60 on ASC-AS_A and B and 7e-4 on ASC-OMC-A and B NSUMs. Jennie took the OMC PZT down to zero to start and then ran a template userapps/../omc/h1/templates/OMC_scan_sqz_beam.xml.

Repeated mode scans with different ZM PSAMs offsets, the DC centering loops could account for the pitch change for PSAMs, for the extreme PSAMS values, I increased the servo limiter from 85 to 95. 

• nominal: ZM4 6.0V strain, ZM5 -0.4V strain. 
• ZM4 9.5V strain, ZM5 -0.6V strain. 
• ZM4 6.0V strain, ZM5 -4.5V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 6.0V strain, ZM5 -5.3V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 9.0V strain, ZM5 2.0V strain
• ZM4 3.0V strain, ZM5 2.0V strain
• ZM4 8.0V strain, ZM5 -2.0V strain. Note that the OMC Pitch QPDs were off around -0.1
• ZM4 4.0V strain, ZM5 -2.0V strain. 
• ZM4 9.5V strain, ZM5 -5.0V strain. Realized OMC ASC had been off before this measurement (we had turned it on but them changed OMC GRD which turned it off again)
• Repeat of ZM4 9.5V strain, ZM5 -0.6V strain with OMC ASC on.

Jennie and Leo have the data to analyze. 

Like we did with SR3 (86070), I've updated the OSEM calibration for PR3. The updated OSEMINF values, along with the compensation gains that get put into the DAMP filter bank were calculated and put in (86222). Today I updated the PR3 OSEMINF gains and put the compensation gains into FM7 in the DAMP filter bank and turned them on. I've accepted these in the safe sdf.

The update to the OSEMINF calibration means that it will look like there is a change in alignment for PR3, but this is not real. Here is what the alignment change looks like: ndscope. These changes were made at 2025-08-19 16:27:57 UTC

OSEMINF changes

The compensation gains put in in the DAMP filter bank are in FM7, and they are the following:

L: 0.596
T: 0.648
V: 0.617
R: 0.617
P: 0.670
Y: 0.596

Tue Aug 19 10:07:37 2025 INFO: Fill completed in 7min 33secs

Gerardo confirmed a good fill curbside. He also knocked some ice from the end of the discharge line.

I moved DM10 to the working platform on the +X+Y corner of BSC2 so we can get some dust readings up at that level in preparation for dome removal post O4. I was hoping to get it further away from the edge of the clean room, but the RS232 cable was stretched to its max. I velcrostripped and zip tied the unit as well as the cabled to keep things from falling off and to relieve stress. I also verified that the unit was still getting 2.8L/min since I had to disconnect and reconnect the vacuum hose. It looks to be running well and we can connect to it in epics.

Ops: Please note if this monitor starts to alarm.

WP12755 TW1 offload.

TJ, Erik, Dave:

Following the file copy to permanant storage last week, this morning at 08:15 (inbetween PEM mag injection and PCAL work) I restarted nds1 with its new daqdrc file. It is now no longer using the files on TW1 which frees them for deletion.

TJ tested the script which restarts the FOM ndscope processes, as previously reported we found that the nuc25 and nuc26 restarts did not work. Doing the restarts manually on the operator machines does work, running the full script on opslogin0 also works, investigation continues.

An attempt was made to swap the split whitening chassis that is currently used for the ASC-AS_C QPD (serial S1101627 in slot U26) with a standard whitening chassis. The current chassis is a split whitening chassis that needs to be modified back to a standard whitening chassis in support of BHD/JAC. While swapping the chassis, I noticed that cable ISC_445 was connected to old OMC PD inputs. I seem to have forgotten that one of these channels is now used for the OMC-REFL PD. The new whitening chassis cannot accommodate this without a new custom cable, so the changes were reverted. However, the new standard whitening chassis, serial S2101199, is now mounted in slot U26, whereas the split whitening has moved to slot U29.

This morning a 6.2 magnitude earthquake near Vanuatu happened during the commissioning window, so we tested the asc gain reversion scripts Elenna came up with in this alog. It took a little longer than I would have liked to get the scripts working, so we didn't actually transition until basically the peak ground velocities, but the transition went pretty smoothly. I think this eq is tied for the biggest  we stayed locked through for all of O4.

Attached image shows ground velocities on the top row (both peakmon and the ITMY Z STS 30-100mhz blrms, second row is the ISC_LOCK state, third and fourth show channels related to the asc transition. Fourth row is the first gain changed by the script CHARD Y, the third row is the SRCL FF gain, which is the last thing changed in the script. The dashed white vertical lines on the CHARD trace and the top row ground traces show the time the transition took to complete.

Even if the transition was a little late I think that this test likely still saved the lock, I have often seen on eqs like this that the IFO stays locked through the peak ground motion, but loses lock some time shortly after, while the eq is still ringing down.

There is still a lot of work to be done as the transition is currently handled by a couple of scripts on the ISI_CONFIG overview medm and the transition will knock us out of Observe, still unclear what the best way to automate this would be, but still a pretty good test.

Similar to alog 86227, the BTRP adapter flange and GV were installed on Tuesday at the MY station.  Leak checking was completed today with no signal seen above the ~e-12 torrL/s background of the leak detector.  

Pumping on this volume will continue until next Tuesday, so some additional noise may be seen by DetChar.  This volume is valved out of the main volume, so the pressure readings from the PT-243 gauges can be ignored until further notice.  

In the past few weeks have seen rocky performance out of the Calibration pipeline and its IFO-tracking capabilities. Much, but not all, of this is due to [my] user error.

Tuesday's bad calibration state is a result of my mishandling of the recent drivealign L2L gain changes for the ETMX TST stage (LHO:78403,
LHO:78425, LHO:78555, LHO:79841).

The current practice adopted by LHO with respect to these gain changes is the following:

1. Identify that KAPPA_TST has drifted from 1 by some appreciable amount (1.5-3%), presumably due to ESD charging effects.
2. Calculate the necessary DRIVEALIGN gain adjustment to cancel out the change in ESD actuation strength. This is done in the DRIVEALIGN bank so that it's downstream enough to only affect the control signal being sent to the ESD. It's also placed downstream of the calibration TST excitation point.
3. Adjust the DRIVEALIGN gain by the calculated amount (if kappaTST has drifted +1% then this would correspond to a -1% change in the DRIVEALIGN gain).
3a. Do not propagate the new drivealign gain to CAL-CS.
3b. Do not propagate the new drivealign gain to the pyDARM ini model.

After step 3 above it should be as if the IFO is back to the state it was in when the last calibration update took place. I.e. no ESD charging has taken place (since it's being canceled out by the DRIVEALIGN gain adjustments). 
It's also worth noting that after these adjustments the SUS-ETMX drivealign gain and the CAL-CS ETMX drivealign will no longer be the copies of each other (see image below). 

The reasoning behind 3a and 3b above is that by using these adjustments to counteract IFO changes (in this case ESD drift) from when it was last calibrated, operators and commissioners in the control room could comfortably take care of performing these changes without having to invoke the entire calibration pipeline. The other approach, adopted by LLO, is to propagate the gain changes to both CAL-CS and pyDARM each time it is done and follow up with a fresh calibration push. This approach leaves less to 'be remembered' as CAL-CS, SUS, and pyDARM will always be in sync but comes at the cost of having to turn a larger crank each time there is a change.


 
Somewhere along the way I updated the TST drivealign gain parameter in the pyDARM model even though I shouldn't have. At this point, I don't recall if I was confused because the two sites operate differently or if I was just running a test and left this parameter changed in the model template file by accident and subsequently forgot about it. In any case, the drivealign gain parameter change made its way through along with the actuation delay adjustments I made to compensate for both the new ETMX DACs and for residual phase delays that haven't been properly compensated for recently (LHO:80270). This happened in commit 0e8fad of the H1 ifo repo. I should have caught this when inspecting the diff before pushing the commit but I didn't. I have since reverted this change (H1 ifo commit 41c516).

During the maintenance period on Tuesday, I took advantage of the fact that the IFO was down to update the calibration pipeline to account for all of the residual delays in the actuation path we hadn't been properly compensating for (LHO:80270). This is something that I've done several times before; a combination of the fact that the calibration pipeline has been working so well in O4 and that the phase delay changes I was instituting were minor contributed to my expectation that we would come back online to a better calibrated instrument. This was wrong. What I'd actually done was install a calibration configuration in which the CAL-CS drivealign gain and the pyDARM model's drivealign gain parameter were different. This is bad because pyDARM generates FIR filters that are used by the downstream GDS pipeline; those filters are embedded with knowledge of what's in CAL-CS by way of the parameters in the model file. In short, CAL-CS was doing one thing and GDS was correcting for another. 

-- 

Where do we stand?

At the next available opportunity, we will be taking another calibration measurement suite and using it reset the calibration one more time now that we know what went wrong and how to fix it. I've uploaded a comparison of a few broadband pcal measurements (image link). The blue curve is the current state of the calibration error. The red curve was the calibration state during the high profile event earlier this week. The brown curve is from last week's Thursday calibration measurement suite, taken as part of the regularly scheduled measurements.

--
Moving forward, I and others in the Cal group will need to adhere more strictly to the procedures we've already had in place: 
1. double check that any changes include only what we intend at each step
2. commit all changes to any report in place immediately and include a useful log message (we also need to fix our internal tools to handle the report git repos properly)
3. only update calibration while there is a thermalized ifo that can be used to confirm that things will back properly, or if done while IFO is down, require Cal group sign-off before going to observing