Displaying reports 261-280 of 84299.Go to page Start 10 11 12 13 14 15 16 17 18 End
Reports until 17:13, Thursday 21 August 2025
LHO General
corey.gray@LIGO.ORG - posted 17:13, Thursday 21 August 2025 (86509)
LIGO Teamspeak Servers Appear To Be Down...In Meantime, Using Virgo Teamspeak Server

At the beginning of this shift, Tony noticed that we had errors for the LHO Control Room Teamspeak.  He mentioned this to Jonathan, and they found out that all the LIGO/MIT Teamspeak servers are down and that we should use the Virgo server to maintain communications.  So---You can find the "LHO Control Room" teamspeak account at:

Of course you can always phone the Control Room as well.

LHO General
corey.gray@LIGO.ORG - posted 17:02, Thursday 21 August 2025 (86505)
Thurs EVE Ops Transition

TITLE: 08/21 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 12mph Gusts, 6mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY:

H1's been locked 3.25+hrs.  TJ passed on what he needed to do for relocking earlier (I've not had to lock H1 for any of my last 6-evening shifts in a row this week...we'll see how tonight goes for my last (7th EVE) shift of the week!).  Environmentally, we had a small EQ from Japan roll through, winds are low, and µseism has slowly popped above the 50th percentile in the last 24hrs.

LHO General
thomas.shaffer@LIGO.ORG - posted 16:34, Thursday 21 August 2025 (86490)
Ops Day Shift End

TITLE: 08/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 3 hours. We had one lock loss during commissioning today, which had an automated relock. The SR3 OSEM esitmators are running now, but that is the only notable change to the IFO. There have been many trips out to the OSB vertex area to escort contractors, mark utilities, and search for a valve out in the hydrant area. Times in the log.
LOG:

Start Time System Name Location Lazer_Haz Task Time End
15:01 SPI Jeff Opt Lab n Inventory 15:31
15:15 FAC Kim Opt Lab n Tech clean 15:38
15:52 VAC Travis MY n Craning and prepping for pump 17:50
16:22 FAC Tyler, Watts Vertex n Hydrant inspect and plan 17:25
16:28 FAC Richard Vertex n Metal detecting the shutoff valve 18:55
16:48 FAC Kim H2 build n Tech clean 17:13
17:25 FAC Kim MY n Tech clean 18:07
17:33 CAL Rick, Tony PCal Lab Local Measurements 18:34
17:41 CDS Fil, Marc MY N Parts delivery/pickup 18:18
19:41 FAC Randy MX n Equipment check 20:06
20:48 FAC Tyler, contractor vertex n Marking hydrant 21:14
21:55 FAC Richard, Fil, Tyler Vertex n Hydrant searchign 22:00
22:17 FAC Tyler FCES n Taking picutres outside the building (2223-2224UTC at building) 22:29
LHO VE
jordan.vanosky@LIGO.ORG - posted 16:33, Thursday 21 August 2025 (86506)
BSC1 Annulus Ion Pump

The annulus ion pump for BSC1 has railed again, this morning at ~3am PDT. There was no change in the internal pressure measured at PT120B (BSC2).

Gerardo and I had swapped the pump controller, see alog 85975, after it had railed previously.

We will continue to monitor and troubleshoot during the next Tuesday maintenance. Pump likely needs replacement.

Images attached to this report
H1 SUS (ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 15:41, Thursday 21 August 2025 (86503)
H1 SUS SR3 M1 Pitch and Yaw Estimator: Local Performance Metrics
J. Kissel, O. Patane

We tested both the P and Y GS13 state-space estimator's sensor correction to the OSEM damping loops for the M1 stage of H1SUSSR3 this morning. See LHO:86491. Here're some of the local metrics showcasing the performance differences between "P and Y estimators OFF" and "P and Y estimators ON."
Images attached to this report
H1 CAL (CAL)
joseph.betzwieser@LIGO.ORG - posted 13:52, Thursday 21 August 2025 (86502)
Note on calibration immediately after re-locking for GPS 1422964623
This alog is intended as record keeping for a quick investigation into an out of observing mode data request for GPS time 1422964623 (Feb 7, 2025), when the LHO interferometer had just relocked, but calibration had not settled.

Relevant monitoring lines and kappa value trend can be seen on the calibration  LHO grafana page.

I picked a period 15 minutes after the gps time as well settled (although Kappa_C was trending up with thermalization) to create an estimated calibration model closer to what I think should have been applied at the GPS time.  I then took the ratio of that model's response function over the response function of the actually applied calibration model which was using the clearly frozen time dependent correction factors right after reaching low noise.

The attached plot of that ratio shows the ratio has a maximum deviation in magnitude of about 12% and 8 degrees.  I don't think this is exactly right, due to the clear trend in the kappa_C on the grafana page, but its close enough that I'd certainly be comfortable with a flat +/- 20%/20 degrees uncertainty statement.
Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 11:27, Thursday 21 August 2025 - last comment - 13:17, Thursday 21 August 2025(86500)
Lock loss 1825UTC

Caused by comissioning activities.

Comments related to this report
thomas.shaffer@LIGO.ORG - 13:17, Thursday 21 August 2025 (86501)

Back to observing at 2014UTC. Automated relock that needed an initial alignment. We got the OK to run with the SR3 OSEM esitmators on, so I accepted those SDFs in Observing and Safe.

Images attached to this comment
H1 TCS
thomas.shaffer@LIGO.ORG - posted 11:07, Thursday 21 August 2025 (86499)
TCS Chiller Water Level Top-Off - Biweekly

FAMIS27822

No water added to either of the chillers, all filters looked good. There was no water in the leak detection Dixie cup, but there was a water stain at the bottom that I hadn't noticed before. Looks like it had been there a bit though since there was some dust within. I'll keep an eye on it.

H1 CAL
thomas.shaffer@LIGO.ORG - posted 11:03, Thursday 21 August 2025 (86493)
Calibration Sweep 1650UTC

Started the calibration 2hr 50min after power up, kappa C looked mostly leveled out by this point.

Simulines start:

PDT: 2025-08-21 09:56:40.367802 PDT
UTC: 2025-08-21 16:56:40.367802 UTC
GPS: 1439830618.367802

Simulines end:

PDT: 2025-08-21 10:19:54.348840 PDT
UTC: 2025-08-21 17:19:54.348840 UTC
GPS: 1439832012.348840

Files:

2025-08-21 17:19:54,197 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250821
T165641Z.hdf5
2025-08-21 17:19:54,204 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20
250821T165641Z.hdf5
2025-08-21 17:19:54,209 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20
250821T165641Z.hdf5
2025-08-21 17:19:54,213 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20
250821T165641Z.hdf5
2025-08-21 17:19:54,218 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20
250821T165641Z.hdf5
 

Images attached to this report
Non-image files attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:31, Thursday 21 August 2025 (86497)
Thu CP1 Fill

Thu Aug 21 10:08:44 2025 INFO: Fill completed in 8min 41secs

 

Images attached to this report
H1 SUS (ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 10:12, Thursday 21 August 2025 - last comment - 10:39, Thursday 21 August 2025(86491)
H1 SUS SR3 M1 Pitch and Yaw Estimator Tested in Nominal Low Noise; Setup and Test Configurations
J. Kissel, O. Patane

2025-08-21 15:34 UTC    Ramped over from using OSEM-only to using GS13 Y Estimator and "light" OSEM damping. 
2025-08-21 16:05 UTC    Turned OFF yaw estimator (back to ), turned ON P estimator. 
2025-08-21 16:36 UTC    Turned ON yaw estimator, P estimator remains ON. Woo!
2025-08-21 16:50 UTC    Both estimators turned OFF (and immediately, calibration measurements start)

- IFO reached nominal low noise at 14:10 UTC (so IFO is ~1.25 hours into thermalization, which we typically quote to be 3.0 hours "done" [not 1/e time constant])
- EQ band is low at 0.02 [um/s]_RMS (most recent EQ was 4.5 [hr] ago; 5.8 [mag] just north of Japan)
- uSeism band is medium (for LHO summer) at 0.1 [um/s]_RMS
- Wind is less than 5-10 [mph]

2025-07-01 These are in use are after the M1 OSEMs have had their satamps upgraded (LHO:85463, 
2025-07-14 The upgraded satamp response was perfectly compensated with measured z:p's from testing in the EE lab LHO:85746)
2025-07-29 These are in use after the M1 OSEMs have had their absolute calibration improved (LHO:86070)
           After the above, HAM5 / SR3 estimator design was informed by the following measurements 
    - 2025-07-29 (In the presence SR3 SUSPOINT Basis ISI EXC; (ISI GS13s projected to SR3 SUSPOINT Y) to (SR3 M1 DAMP Y) LHO:86075, 
    - 2025-08-05 M1 to M1 LHO:86202, 
    - 2025-08-05 (In the presence SR3 SUSPOINT Basis ISI EXC; (ISI GS13s projected to SR3 SUSPOINT P) to (SR3 M1 DAMP P) LHO:86203
    - 2025-08-05 M1 to M1 LHO:86203
Design of estimator and blend filter aLOGs are quoted below by each filter
2025-08-19 Oli installed / configured these estimators this past Tuesday (LHO:86455)


::: PIT FILTERS :::
Design aLOG: LHO:86430
M1_EST_P_FUSION_MODL_SUSP_P_2GAP      "ISI_fit"    FM1      EPICS Gain: +1.0
sos(-0.001012906275385808, [-2.0001366554573741; 1.000136668010563; 
                            -1.999948594076947; 0.99994860612347214; 
                            -1.999955359352324; 0.99995565554604537; 
                            -1.999976011494571; 0.99997638571005953; 
                            -2.000046972353724; 1.0000477507088701; 
                            -1.9999816676161819; 0.99998231095588275; 
                            -1.999807905043806; 0.9998079477319114; 
                            -1.9999858561539881; 0.9999859195985662; 
                            -1.999989374293667; 0.99998949933234416; 
                            -1.9999885936664199; 0.99998867482680542; 
                            -1.9999967240112111; 0.99999852427171887; 
                            -1.9999908757192211; 0.99999261046439736])
                                                   "to_um/nm"   FM2           
zpk([],[],1.000000000000000,"n")                                             %% Yes, this is a gain of 1.0 and thus is not doing anything. This is vestigial. Calibration has been absorbed into the "ISI_fit."

M1_EST_P_FUSION_MODL_DRV_P_2GAP      "M1_fit"     FM1      EPICS Gain: +1.0
sos(6.9937614616314464e-08, [1.9999999999998279; 0.99999999999995282; 
                             -1.9999796747664531; 0.99998031671408905; 
                             -1.9999989658263551; 0.99999907355206619; 
                             -1.999984525961469; 0.99998458794634182; 
                             -1.999972378962787; 0.99997245232369414; 
                             -1.999986427026998; 0.99998650968797875; 
                             -1.9999982894453341; 0.99999986582789491; 
                             -1.9999908361882079; 0.99999257469114344])

                                                   "to_um/cts"   FM2           
zpk([],[],1.000000000000000,"n")                                             %% Yes, this is a gain of 1.0 and thus is not doing anything. This is vestigial. Calibration has been absorbed into the "M1_fit."

Design aLOG: LHO:86452
M1_EST_P_FUSION_MEAS_BP    "pit_v1"     FM1       EPICS Gain: +1.0
sos(0.1000427204344847, [-0.99977476062437198; 0; 
                         -0.99998082542398548; 0; 
                         -1.999507407187904; 0.99950802568624952; 
                         -1.9999459253790719; 0.99994656777201008; 
                         -1.9997448445054919; 0.99974638260765558; 
                         -1.9999542865584909; 0.99995602687005281])

M1_EST_P_FUSION_MODL_BP    "pit_v1"      FM1      EPICS Gain: +1.0
sos(0.8999572795655153, [-1; 0; 
                         -0.99998082542398548; 0; 
                         -1.999987516253469; 0.99998815869468505;
                         -1.9999459253790719; 0.99994656777201008; 
                         -1.9999884578241209; 0.99999019525631272;
                         -1.9999542865584909; 0.99995602687005281])

Copies of M1_DAMP_P: (EPICS Gain: -0.1)
P_DAMP_OSEM      EPICS Gain: -0.4
P_DAMP_FUSION    EPICS Gain: -0.4

The filters ON in each of these damping loop controller filter banks
rolloff_P    soft roll-off of sensor noise                 zpk([0;2;5],[20;20;30;30],0.005,"n")
boost_P      extra gain at first Y resonance               zpk([0.415914+i*0.587721;0.415914-i*0.587721;0.67;0.77],[0.246255+i*0.676579;0.246255-i*0.676579;0.131518+i*0.707886;0.131518-i*0.707886],1,"n")
norm_P       nominal unit conversion from um to ADC ct     zpk([],[],43.478,"n")
x0.628       gain adjustment from absolute calibration     gain(0.628)
bounceRoll   highest V and R mode notch tailored for SR3   ellip("BandStop",4,1,60,27.5,28.0)ellip("BandStop",4,1,60,45.0,45.5)gain(1.25893)
ellip_P      aggressive roll-off of sensor noise           zpk([0.64975+i*9.7463;0.64975-i*9.7463],[1.22183+i*5.87428;1.22183-i*5.87428;2.7978],1,"n")

(total OSEM gain or OSEM+Estimator gain of -0.5 for P, the prior-to-estimator "nominal" gain we'd been running since Aug 15 2023 LHO:72249)


::: YAW FILTERS :::
Design aLOG: LHO:86233
M1_EST_Y_FUSION_MODL_SUSP_Y_2GAP      "ISI_fit"     FM1     EPICS Gain: +1.0
sos(-0.00097333255316384561, [-2; 0.99999999999999989; 
                              -1.999987505826812; 0.99998828408658169;
                              -1.9999917387445989; 0.99999222786356268; 
                              -1.999991053658418; 0.99999120602937952;
                              -1.9999951079581699; 0.99999667180704854; 
                              -1.9999907068801011; 0.99999239185345823])

                                                   "to_um/nm"   FM2           
zpk([],[],1.000000000000000,"n")                                             %% Yes, this is a gain of 1.0 and thus is not doing anything. This is vestigial. Calibration has been absorbed into the "ISI_fit."

M1_EST_Y_FUSION_MODL_DRV_Y_2GAP      "M1_fit"     FM1       EPICS Gain: +1.0
sos(1.1347068995497109e-08, [2.000000000001652; 0.99999999999677247; 
                             -1.9999881576357379; 0.99998893434766245; 
                             -1.999998372312229; 0.99999974909962519; 
                             -1.99998928164089; 0.99999097015263916; 
                             -1.999998867104356; 0.99999912434806359; 
                             -1.99999256126361; 0.99999271377731203])

                                                   "to_um/cts"   FM2           
zpk([],[],1.000000000000000,"n")                                             %% Yes, this is a gain of 1.0 and thus is not doing anything. This is vestigial. Calibration has been absorbed into the "M1_fit."

Design aLOG: LHO:86265
M1_EST_Y_FUSION_MEAS_BP      "SKY_notch"      FM1      EPICS Gain: +1.0
sos(0.000183409288171444, [1; 0; 
                           -0.99996165121563274; 0; 
                           -1.999942013670952; 0.99994237961280041;
                           -1.999812801308257; 0.99981448778963355; 
                           -1.9999004183717279; 0.99990166730434937;
                           -1.999852310365053; 0.99985308742131895; 
                           -1.9999736341441301; 0.99997367996470554;
                           -1.9999216555380299; 0.99992180839221256])


M1_EST_Y_FUSION_MODL_BP             "SKY_notch"        FM1       EPICS Gain: +1.0 
sos(0.9998165907118286, [-1.0000000000000011; 0; 
                         -0.99996165121563274; 0; 
                         -1.999961208202631; 0.99996289480915956; 
                         -1.999812801308257; 0.99981448778963355; 
                         -1.9999698386597631; 0.99997061576169488; 
                         -1.9998523103650541; 0.9998530874213194; 
                         -1.9999842083331081; 0.99998436119207135; 
                         -1.9999216555380299; 0.99992180839221256])


Copies of M1_DAMP_Y: (EPICS Gain: -0.1)
Y_DAMP_OSEM      EPICS Gain: -0.4
Y_DAMP_FUSION    EPICS Gain: -0.4

rolloff_Y    soft roll-off of sensor noise                 zpk([0;1],[20;30;30],0.01,"n")
boost_Y      extra gain at first Y resonance               zpk([0.9;1.1],[0.173648+i*0.984808;0.173648-i*0.984808],1,"n")
norm_Y       nominal unit conversion from um to ADC ct     zpk([],[],43.478,"n")
x0.757       gain adjustment from absolute calibration     gain(0.757)
bounceRoll   highest V and R mode notch tailored for SR3   ellip("BandStop",4,1,60,27.5,28.0)ellip("BandStop",4,1,60,45.0,45.5)gain(1.25893)
ellip_Y      aggressive roll-off of sensor noise           zpk([0.97195+i*9.7195;0.97195-i*9.7195],[1.0264+i*4.9347;1.0264-i*4.9347;2.7978],1,"n")

(total OSEM gain or OSEM+Estimator gain of -0.5 for Y, the prior-to-estimator "nominal" gain we'd been running since Aug 15 2023 LHO:72249)
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:39, Thursday 21 August 2025 (86498)
Also, the H1SUSSR3.txt filter file that includes all of this goodness is
    /opt/rtcds/lho/h1/chans/filter_archive/h1sussr3/H1SUSSR3_1439664560.txt
which was auto-committed without message to the userapps repo location 
    /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSSR3.txt        rev 32818
on 2025-08-20.
H1 CDS
david.barker@LIGO.ORG - posted 08:53, Thursday 21 August 2025 (86492)
VACSTAT: increased HAM1 delta-trip to reduce false positives on sensor glitches

Following Tuesday night's false positive alarm for HAM1 PT100_MOD2 due to a sensor glitch (alog 86472) this morning I increased the delta-trip values for this gauge from 1.0e-07 to 3.0e-07 Torr for all three lookbacks.

The Tuesday alarm was due to the delta-p glitching up to 2.0e-07, the slope channels only reached 50% of their trip values.

VACSTAT was restarted at 08:37 with these new values.

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 07:33, Thursday 21 August 2025 (86489)
Ops Day Shift Start

TITLE: 08/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 1mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY: Locked for 25 minutes after an earthquake knocked us out and it recovered all on its own. No alarms. Planned calibration and commissioning today, though with us being unthermalized at the start, we will need to rearrange a few items.

LHO General
corey.gray@LIGO.ORG - posted 22:13, Wednesday 20 August 2025 (86488)
Wed EVE Ops Summary

TITLE: 08/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 46Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Smooth and uneventful shift with H1 locked entire shift and currently at 6.75hrs.
LOG:  n/a

H1 CDS
david.barker@LIGO.ORG - posted 08:08, Saturday 16 August 2025 - last comment - 15:38, Thursday 21 August 2025(86394)
h1susex back up and running.

Marc replaced the bad 18bit DAC, system was powered back up 07:57

I can see all the cards in the IO Chassis, h1iopsusex started with no problems, followed by the user models.

I reset the SWWD on SUS and SEI.

HWWD had not tripped overnight.

Marc is heading out of EX, Ryan is untripping the user model watchdogs and preparing for IFO recovery.

Comments related to this report
marc.pirello@LIGO.ORG - 08:21, Saturday 16 August 2025 (86396)

Old 18 bit DAC removed SN: 110425-48
New 18 bit DAC card installed SN:110425-32

david.barker@LIGO.ORG - 08:48, Saturday 16 August 2025 (86397)
marc.pirello@LIGO.ORG - 15:38, Thursday 21 August 2025 (86504)

Everyone keeps asking so I figure it might as well be in the ALOG.  Be aware, there is a big spider at EX, we think it is a big wolf spider.  I estimate the size to be 5" or 13cm leg to leg.  Its body seemed to be 3" length and 1" in diameter at its widest.  Here are the pictures.

Images attached to this comment
H1 ISC
jennifer.wright@LIGO.ORG - posted 14:22, Monday 04 August 2025 - last comment - 10:29, Thursday 21 August 2025(86175)
Attempt at measuring HO modes in OMC reflected port

Jennie W, Sheila D

 

Summary: tried to use ETMX injection to tag light coming from the arms at the REFL port as we step the darm offset, didn't get a full measurement as we lost lock - seems unrelated.

 

During the commissioning period and while Robert as doing shaker i jections, I tuned a line at 74.37 Hz on the SUS-ETMX_L3_CAL_EXC. This is the same point at which the ETMX CAL line input goes in (where the calibration exc for ETMX is injected into the DRIVEALIGN matrix). The psds shown were measured about a minute before lost lock and it can be seen that the rms motion in the upper left of the ETMX bottom mass is not reaching its limit.

The settings I used in AWG are shown in this photo.

After checking the height of the line in DARM, OMC REFL and the rms on the upper left ESD readout, I tried to take a darm offsert step measurement using autodarmpoffsetstep.py (using the ETMX line instead of the PCAL lines to readout the optical gain). To do this I comment out the setup_pcal_for_darm_offset_step and restore_pcal functions in autodarmoffsetstep.py before running it.

I had to the stop the measurement twice to trurn off the OMC ASC and put the X0 offset back to what it was before the measurement. One step into this measurement set we then lost lock (around 2 minutes into the final attempted DARM offset measurement). We can't see any evidence so far as this was the causer of lockloss as the line had been running for 40 minutes or so without breaking the lock.

 

Data is saved in an xml in /ligo/gitcommon/jennifer.wright/git/DARM_OFFSET

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 10:29, Thursday 21 August 2025 (86496)

Got the folder reference wrong for the xml file, its actually in /ligo/home/jennifer.wright/git/2025/DARM_OFFSET.

H1 SUS
oli.patane@LIGO.ORG - posted 13:53, Tuesday 29 July 2025 - last comment - 10:08, Thursday 21 August 2025(86075)
SR3 SUSPOINT and OLTFs taken for estimator fit

As the next step in fine-tuning the SR3 Y estimator, we needed to retake the SUSPOINT to M1 measurements as well as OLTFs so they could be used to calculate the filter modules for the suspoint and drive estimators. I took those measurements today.

General setup:
- in HEALTH_CHECK (but damping back on)
    - damping for Y changed from -0.5 to -0.1
- OSEMINF gains and DAMP FM7 turned on (and left on afterwards 86070)

SUSPOINT to M1:
Data for those measurements can be found in /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-07-29_1730_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_{L,T,V,R,P,Y}_0p02to50Hz.xml  r12492

M1 to M1 (OLTFs):
After this, the next steps are to take regular transfer functions with the above setup of Y having -0.1 damping
That data is in /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/2025-07-29_1830_H1SUSSR3_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OpenLoopGainTF.xml  r12493
Reminder that these open loop transfer functions were taken with the damping Y gain of -0.1, so they should not be taken as 'nominal' OLTFs.

Comments related to this report
oli.patane@LIGO.ORG - 10:08, Thursday 21 August 2025 (86495)

The M1 to M1 TFs were supposed to be regular TFs so here is the alog for those: 86202

H1 CAL
louis.dartez@LIGO.ORG - posted 11:16, Thursday 26 September 2024 - last comment - 10:18, Monday 25 August 2025(80291)
Procedural issues in LHO Calibration this week
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
Images attached to this report
Comments related to this report
vladimir.bossilkov@LIGO.ORG - 15:30, Tuesday 19 August 2025 (86460)CAL

Posting here for historical reference.
The propagation of the correction of incorrect calibration was in an email thread between myself, Joseph Betzwieser, Aaron Zimmerman, Colm Talbot.

I had produced a calibration uncertainty with necessary correction that would account for the effects of this issue attached here as a text file, and as an image showing how it compares against our ideal model (blue dashed) and the readouts of the calibration monitoring lines at the time (red pentagons).

Ultimately the PE team used the inverse of what I post here, since as a result of this incident it was discovered that PE was ingesting uncertainly in an inverted fashion up to this point.

Images attached to this comment
Non-image files attached to this comment
joseph.betzwieser@LIGO.ORG - 10:29, Thursday 21 August 2025 (86494)
I am also posting the original correction transfer function (the blue dashed line in Vlad's comment's plot) here from Vlad for completeness.

It was created by calculating the modeled response of the interferometer that we intended to use at the time (R_corrected), over the response of the interferometer that was running live at the time (R_original) corrected for online correction (i.e. time dependent correction factors such as Kappa_C, Kappa_TST, etc).

So to correct, one would take the calibrated data stream at the time:
bad_h(t) = R_original (t) * DARM_error(t)

and correct it via:
corrected_h(t) = R_original(t) * DARM_error(t) * R_corrected / R_original(t)
Non-image files attached to this comment
joseph.betzwieser@LIGO.ORG - 10:18, Monday 25 August 2025 (86547)
So our understanding of what was wrong with the calibration around September 25th, 2024 00:00 UTC has improved significantly since then.  We had 4 issues in total.

1) The above mentioned drivealign gain mismatch issue between model, h1calcs, the interferometer and GDS calibration pipeline.

2) The ETMX L1 stage rolloff change that was not in our model (see LHO alog 82804)

3) LHO was not applying the measured SRC detuning to the front end calibration pipeline - we started pushing it in February 2025 (see LHO alog 83088).

4) The fact that pydarm doesn't automatically hit the load filters button for newly updated filters means sometimes humans forget to push that button (see for example LHO alog 85974).  Turns out that night the optical gain filter in the H1:CAL-DARM_ERR filter bank had not been updated.  Oddly enough, the cavity pole frequency filter bank had been updated, but I'm guessing the individual load button was pressed 

In the filter archive (/opt/rtcds/lho/h1/chans/filter_archive/h1calcs/), specifically H1CALCS_1411242933.txt has an inverse optical gain filter of 2.9083e-07, which is the same value as the previous file's gain.  However, the model optical gains did change (3438377 in the 20240330T211519Z report, and 3554208 in the bad report that was pushed, 20240919T153719Z).  The epics for the kappa generation were updated, so we had a mismatch between the kappa_C value that was calculated, and to what optical gain it applied - similar to the actuation issue we had.  It should have changed by a factor of 0.9674 (3554208/3438377).

This resulted in the monitoring lines showing ~3.5% error at the 410.3 Hz line during this bad calibration period. It also explains why there's a mistmatch between monitoring lines and the correction TFs we provided that night at high frequency.  Normally the ratio between PCAL and GDS is 1.0 at 410.3 Hz since the PCAL line itself is used to calculated kappa_C at that frequency and thus matches the sensing at that frequency to the line. See the grafana calibration monitoring line page.

I've combined all this information to create an improved TF correction factor and uncertainty plot, as well as more normal calibration uncertainty budgets.
So the "calibration_uncertainty_H1_1411261218.png" is a normal uncertainty budget plot, with a correction TF from the above fixes applied.
The "calibration_uncertainty_H1_1411261218.txt" is the associated text file with the same data.

"H1_uncertainty_systematic_correction.txt" is the TF correction factor that I applied, calculated with the above fixes.
Lastly, "H1_uncertainty_systematic_correction_sensing_L1rolloff_drivealign.pdf", is the same style plot Vlad made earlier, again with the above fixes.

I'll note the calibration uncertainty plot and text file was created on the LHO cluster, with /home/cal/conda/pydarm conda environment, using command: 
IFO=H1 INFLUX_USERNAME=lhocalib INFLUX_PASSWORD=calibrator CAL_ROOT=/home/cal/archive/H1/ CAL_DATA_ROOT=/home/cal/svncommon/aligocalibration/trunk/ python3 -m pydarm uncertainty 1411261218 -o ~/public_html/O4b/GW240925C00/ --scald-config ~cal/monitoring/scald_config.yml -s 1234 -c /home/joseph.betzwieser/H1_uncertainty_systematic_correction.txt
I had to modify the code slightly to expand out the plotting range - it was much larger than the calibration group usually assumes.

All these issues were fixed in the C01 version of the regenerated calibration frames.
Images attached to this comment
Non-image files attached to this comment
Displaying reports 261-280 of 84299.Go to page Start 10 11 12 13 14 15 16 17 18 End