Displaying reports 1-20 of 89034.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 11:30, Wednesday 26 August 2026
H1 IOO
jennifer.wright@LIGO.ORG - posted 11:30, Wednesday 26 August 2026 (91689)
JAC ASC dragged away JM1 this morninng

Jennie W, Elenna C, Keita K, Ryan S, Daniel S,

 

This morning JAC lost lock and couldn't re-lock. We solved this by clearing history in the JAC ASC and using the sliders to bring back JM1 osem values to those they had before the lock loss. NB: The process should be to clear history in the four ASC filter banks and in the JM1 suspension LOCK filter banks.

Zooming in on the time when we lost lock it looks like it was mainly DOF1 Y (yaw of PSL PZT) that got pulled away by the ASC as the JAC transmitted power dropped because the PZT ran out of range at the lower end. See zoomed in image here.

Because DOF1 now had a large output signal this then meant that the wavefront sensors were not centred in yaw and so prevented us re-locking as the alignment was so bad.

Here is the long term trends showing when we lost lock, when we cleared history, and when we re-locked.

A better temperature servo should help this.

Images attached to this report
H1 AOS
betsy.weaver@LIGO.ORG - posted 10:52, Wednesday 26 August 2026 (91690)
End-X BSC9 chamber cleanroom ON

In prep for a very potential (and hopefully quick) vent tentatively scheduled for ~Sept 8th, Randy is prepping the cleanroom spaces.  He will also turn on the big chamber 16" square cleanoom.  This will raise the temp in the End-X VEA and may effect the ETMx pointing, but that is all fine with ops/commiss.

 

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 10:01, Wednesday 26 August 2026 (91688)
BSC9 Annulus Ion Pump Railed

The annulus ion pump for BSC9 just railed, about 15 minutes ago.
Nothing to do for now, but we will asses ASAP to see what is wrong with it.

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 07:36, Wednesday 26 August 2026 (91686)
Ops Day Shift Start

TITLE: 08/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 6mph Gusts, 3mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.06 μm/s 
QUICK SUMMARY: At 0412UTC the SEI_ENV state was transitioned to Maintenance, but I see no alog mentioning this. Dust at EX gone up near 1000 a few times overnight, we will need to check on that. 

No other alarms, we will continue locking commissioning today.

H1 AOS
elenna.capote@LIGO.ORG - posted 18:32, Tuesday 25 August 2026 - last comment - 09:22, Wednesday 26 August 2026(91685)
PRMI locking summary

[Keita, Louis, Elenna, with input from others]

We locked PRMI again with the stronger BS top mass damping and no oplev damping. I also raised the damping gains of PRM, PR2, SR2 to -1. They have been set to -0.5 for a while now. I have SDFed these gains to -1 to help with locking.

> Since the PRMI buildups are so ratty, I am concerned about what is moving too much. Clearly the BS is the main culprit, but given the issues with PR2 where the damping was essentially doing nothing at low gain, I think we should raise the damping gain on all HSTSs to the original setting of -1. We can evaluate the noise effects in full lock, and perhaps have a gain setting for lock acquisition versus NLN.

I had some initial trouble locking MICH, and realized that the M3 drivealign gain was incorrectly set. Once I fixed that, it was much better. We need to check the guardian to make sure this gets set correctly.

> Haven't looked into this yet, will do so today.

Using a beamsplitter damping gain of -3 for most DOFs works well. We had some excess 1 Hz motion which I tracked down to having too high gain on BS T, so I've left that dof at -1 gain. SDF 1 2

PRMI locks quickly, and it appears by camera that the BS moves a lot less in this state during locking. However, the buildups were very shaky as we sat in PRMI locked for more than 30 minutes. I looked at the signals and it appears that the largest motion in POPAIR RF18 was around 0.2 and 0.3 Hz. Jim put the beamsplitter ISI in the fully isolated state, and this help reduce the motion.

> There is still excess motion in the corner at 0.1-0.3 Hz, mainly on the BS ISI. Jim is looking into this issue. This shows up strongly in the BS oplevs, but you can also see some of it in the PR3 oplev. This explains some of the wiggly-ness in the PRMI buildup.

The rest of the movement occurring while we sit in PRMI seems to be that the BS moves a lot at 0.45 Hz. However this signal is not visible in the top mass osems, so it would probably be better if we could engage MICH ASC.

> Sheila has pointed out that we should look into length-to-angle decoupling, going to work on this today.

I had some trouble engaging the BS ASC, which should drive to M2 and M1. I checked the error signals (AS RF45 B Q), and realized it didn't make sense (> as in the signals did not cross zero when buildups maximized, etc). So I then checked the phasing by driving a MICH length line at 88 Hz. The phasing was very bad, mostly in I not Q, and I fixed it by adjusting the phase by 70 degrees for all four segments. One segment moved the opposite direction of the other three segments (as in three segments reduced phase by 70 deg, one increased phase by 70 deg), which Keita found was because the relative phase of Q3 compared to Q1, 2, and 4 was off by 180. By flipping the demod phase on Q3, all of the relative phases between the segments was zero. I SDFed these phases. (screenshots attached of measurements and SDFs).

For good measure I rephased AS A RF45, although I would want to recheck the AS RF45 phasing when we have a DARM signal. (screenshots attached of measurements and SDFs).

> We need to rephase all ASC diodes I suspect.

With the rephasing, the MICH ASC error signals looked much more reasonable. I can engage the loops, but the pitch loop runs off after a minute or two, so I might have the gain sign wrong. The guardian is still set to engage MICH ASC FALSE, so it has to be done by hand.

Conclusions from today:

- we can keep locking PRMI/DRMI with no oplev damping

- we can keep locking with high BS top mass damping

- we can have the BS ISI ST2 boost ON when locking PRMI/DRMI

> before I get too confident, let's monitor over the next few weeks as Jeff suggests in his comment. However, we relocked multiple times to PRMI yesterday without any big kicks, all locklosses were due to me messing around with the alignment, or the JAC losing lock.\

> as a final note, the oplev damping still works, so if something happens that kicks the BS too much, ramping on the oplev gain for a few seconds can quickly damp the motion down (I suspect it's very overdamped)

***

Right after posting this alog I tried again with MICH ASC.

I feel confident that MICH yaw works with a gain of 0.5. This is flipped sign and slightly larger than the gain setting in the guardian for this state.

I think MICH P works ok with -0.5 gain. I was testing it and all was well until the JAC unlocked itself for a separate reason. It can take MICH P a few minutes to fall over though, so I won't change the guardian setting yet.
However, if you run the MICH ASC, the buildups are much quieter in PRMI.

***

> Logging in this morning to add some clarifying statements to the above, since I wrote this a bit hastily last night.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:22, Wednesday 26 August 2026 (91687)GRD, ISC, SEI, SYS
Commenting with Primary Task as ISC and Tagging ISC just in case Elenna doesn't get the chance to change the main entry.

Also tagging SEI, GRD, and SYS -- to make sure they "hear" the statement "we can have the BS ISI ST2 boost ON when locking PRMI/DRMI," -- very encouraging improvement to the beam splitter's interactions with the ISI BS during lock-acquisition as a result of a larger beam splitter and lower-stage actuation. Now the ISI BS should no longer need to have to use a special state that's different that the other BSC ISIs that we've had to use for all observing runs to-date.

Let's a get a few more weeks of locking under our belt, but then *consider* simplifying the SEI guardian if the cost / benefit ratio is low.
H1 SUS (ISC)
oli.patane@LIGO.ORG - posted 18:21, Tuesday 25 August 2026 (91684)
ETMX L1 LL OSEM investigation continuation explanation

Betsy, Sheila, Camilla, Fil, Oli

The biggest conclusion from today is the concern that we might not be able to really move ETMX without creating the rubbing that seems to be the cause of our L1 LL issues.

Partway through troubleshooting today we changed the EUL2OSEM for ETMX L1 to be the tripod (coil driver switching) version. I only changed this one and not the L1 OSEM2EUL, and have purposely not SDF'd it since we don't know if this is correctly working or if we'll even be able to utilize it. We only did a quick check on whether it was working and it seemed to be super cross coupled, but we didn't look too far into it. I got this matrix from /opt/rtcds/userapps/release/isc/h1/scripts/sus/etmx_l1_out_ll.snap, which is meant to be used when needing to actuate at L1 while swapping the coil driver state for LL.

M0 L2L Transfer function
I took an ETMX M0 L2L transfer function and found that it is seeing rubbing. June 5, 2026 was the last time an M0 L2L TF was taken, and it looks perfect with no rubbing(black trace). This narrows our scope of when we believe something happened to L1 LL osem from between March 5 and August 20, 2026 to sometime between June 5 and August 20, 2026. When I first started the transfer function, LL didn't seem to really be reacting to the excitation even though the other osems on L1 were moving by at least a few hundred counts(L1 OSEMINF). Then 1.5 minutes into the measurement, the LL OSEMINF IN suddenly saw a DC change of 300 counts. At this same time, LR also dropped by ~300 counts, the upper osems saw maybe a bit of motion, and some of the osems on the M0 stage saw movement of up to a few microns as well (OSEMINF_INOSEMINF_OUT). 
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2030_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz.xml

R0 L2L Transfer function
We took a transfer function for R0 L2L and found that it also looks like it sees the rubbing. This should rule out rubbing coming from an earthquake stop on M0.
Data:  /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2125_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_noVoffset.xml

M0 and R0 height adjustments
The LF and RT (Vertical) OSEMs for both M0 and R0 are reading lower than we expect, and although they seem to have been in that configuration for a long time, we're still suspicious of them and wondered if we might be seeing touching due to them being higher than they should be (smaller OSEMINF IN value = more OSEM light occulted by flag). We tried putting Vertical offsets of +/- 200,000 counts in the M0 and/or R0 TEST banks and taking transfer functions, but all the configurations we tried still looked like there was the same amount of rubbing every time.
Some of the measurements we were seeing some 'glitching' happening on LL as well, but for the most part we still weren't seeing much other movement.

  Offset(s) Data
    M0 L2L      
M0: -200,000, R0: 0 /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2100_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml
M0: +200,000, R0: 0 /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2115_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffsetplus200000.xml
    R0 L2L  
M0: 0, R0: -200,000 /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2135_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml
M0: +200,000,
R0: -200,000
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2145_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_R0Voffset-200000_M0offset200000.xml
Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 17:56, Tuesday 25 August 2026 (91683)
HAM7 Ports Leak Check

(Travis S., Jordan V., Gerardo M.)
We connected the leak detector, Inficon UL5000, to the back the SS-500 aux cart, the leak detector was turned on and left to reach nominal operation.
We started leak checking the viewport on the -Y door, no response from the helium leak detector, but then the leak detector showed a signal when Travis sprayed the +Y door port, signal reached ~ 2.7X10-09 Torr*L/Sec, but the signal was not fast, it moved slow but with a steady upward trend, we do have a couple of D1100999 viewports, O-ring type.  Travis stopped and we decided to bag the individual ports to leak check, after bagging the ports they were sprayed with helium and no change was noted at the leak detector helium signal.
No leak was detected above the leak detector's background of 2.0X10-10 Torr*L/Sec.

Attached photo is the initial background.

Images attached to this report
H1 CAL (CAL)
anthony.sanchez@LIGO.ORG - posted 16:31, Tuesday 25 August 2026 (91681)
PCAL End X End station Measurement

Caroline and I went to End X with PS4 and followed the instruction on the DCC doc T1500062.
The Current limit red LED was lit up again. I simply adjusted the voltage down a few thousandths of a volt and the current steadied right up at 10V again
The beams were a little offset on the Apature of the RX Sphere when we arrived.  But I did not touch up the alignment this time. I may touch up alignment again next months.
Also we wore gloves this time... that was fun I guess.
 
Commands ran & subsequent output:
anthony.sanchez@cdsws32: python generate_measurement_data.py --WS PS4 --date 2026-08-24
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2026-08-24 corrected to ES temperature 299.3 K :
-4.699251194624549 -0.0002694340454223 0.00075040881877916
Copying the scripts into tD directory...
Connected to h1daqnds1
martel run
reading data at start_time:  1471716950
reading data at start_time:  1471717444
reading data at start_time:  1471717888
reading data at start_time:  1471718420
reading data at start_time:  1471719060
reading data at start_time:  1471719400
reading data at start_time:  1471719630
reading data at start_time:  1471720300
reading data at start_time:  1471720660
Ratios: -0.4615405682485709 -0.46591058962067394
writing nds2 data to files
finishing writing
Background Values:
bg1 =        8.879049; Background of TX when WS is at TX
bg2 =        5.011307; Background of WS when WS is at TX
bg3 =        8.896423; Background of TX when WS is at RX
bg4 =        5.129760; Background of WS when WS is at RX
bg5 =        8.965872; Background of TX
bg6 =        0.027675; Background of RX

The uncertainty reported below are Relative Standard Deviation in percent 

Intermediate Ratios
RatioWS_TX_it      = -0.461541;
RatioWS_TX_ot      = -0.465911;
RatioWS_TX_ir      = -0.455518;
RatioWS_TX_or      = -0.460890;
RatioWS_TX_it_unc  = 0.070028;
RatioWS_TX_ot_unc  = 0.067789;
RatioWS_TX_ir_unc  = 0.072976;
RatioWS_TX_or_unc  = 0.075331;
Optical Efficiency
OE_Inner_beam                      = 0.987476;
OE_Outer_beam                      = 0.989974;
Weighted_Optical_Efficiency        = 0.988725;

OE_Inner_beam_unc                  = 0.046927;
OE_Outer_beam_unc                  = 0.047569;
Weighted_Optical_Efficiency_unc    = 0.066821;

Martel Voltage fit:
Gradient      = 1636.904156;
Intercept     = 0.551415;


 Power Imbalance = 0.990620;

Endstation Power sensors to WS ratios::
Ratio_WS_TX                        = -1.078224;
Ratio_WS_RX                        = -1.391522;

Ratio_WS_TX_unc                    = 0.041912;
Ratio_WS_RX_unc                    = 0.038391;

=============================================================
============= Values for Force Coefficients =================
=============================================================

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

costheta     =      0.988362; Angle of incidence
c            =      299792458.000000; Speed of Light
             
End Station Values : 
TXWS         =        -1.078224; Tx to WS Rel responsivity (V/V)
sigma_TXWS   =        0.000452; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS         =        -1.391522; Rx to WS Rel responsivity (V/V)
sigma_RXWS   =        0.000534; Uncertainity of Rx to WS Rel responsivity (V/V)

e            =        0.988725; Optical Efficiency
sigma_e      =        0.000661; Uncertainity in Optical Efficiency

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

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

Force Coefficients : 
FC_TxPD          =        7.900632e-13; TxPD Force Coefficient 
FC_RxPD          =        6.191631e-13; RxPD Force Coefficient 
sigma_FC_TxPD          =        3.624112e-24; TxPD Force Coefficient 
sigma_FC_RxPD          =        2.753947e-24; RxPD Force Coefficient 
data written to ../../measurements/LHO_EndX/tD20260825/ and can be found on the gitlab here


 

 

 

Images attached to this report
Non-image files attached to this report
LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 16:30, Tuesday 25 August 2026 (91682)
OPS Day Shift Summary

TITLE: 08/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Very Busy Maintenance Day at the End Stations and the Corner Station. The biggest update is that ALSY now reliably works with WFS Converging! As such, PRMI has been locked consistently with some instability in the BBSS. Commissioners Elenna and Louis are working on improving it in various ways. 

Broken down by station

EX:

PCAL Measurement - Tony and Caroline (PCAL)

ETMX BOSEM Measurements and Troubleshooting - Oli, Fil, Betsy (SUS, EE)

EY:

UPS Access System Replacement - Fil (EE)

Beckhoff Chassis Swap, Repair ALSY WFS Demod RF Level Monitor - Marc (EE)

Corner:

Gate Valve, Leak Check and Output Tube Gauge Work (Gerardo, Jordan, Travis)

TCS Line Inspection and TCS Inventory Work (TJ, Christina, Camilla)

ITMY Optical Lever Relocated for CHETA:

CDS:

Work stations rebooted

Control Room Screens:

Vacuum Electronics Work (Patrick, Jordan, Gerardo, Travis)

CDS DAQ Restart (Dave):

IOC Container Host Cluster Update (Jonathan):

Commissioning/Ctrl Room Work - Started at 12:40 (approx.)

Other:

LOG:                                                                                                                                                                                                           

Start Time System Name Location Lazer_Haz Task Time End
15:24 FAC Kim EX N Technical Cleaning 16:26
16:19 EE Fil, Oli EX N Troubleshooting 16:47
16:23 VAC Jordan, Gerardo LVEA Y Gate valve work, Output Tube Guage 18:01
16:23 TCS TJ LVEA Y Chiller disposal, Line inspection 17:23
16:25 FAC Kim EY N Technical Cleaning 17:52
16:25 EE Marc EY N Beckhoff chassis swap 17:47
16:27 FAC Eric Wood Shop N Fire pump 16:54
16:39 TCS Jason, Camilla LVEA Y IY Oplev table move to make room for CHETA 17:17
16:41 PCAL Tony, Caroline PCAL Lab N Grabbing things for EX PCAL Measurement 16:55
16:47 EE Fil EY N UPS Access System replacement 18:58
16:57 PCAL Tony, Caroline EX Y PCAL Measurement 19:45
17:11 FAC Richard LVEA, Y-arm N Walkabout + Y-arm padding accessibility check 17:59
17:18 VAC Travis LVEA Y Gate Valve and Output Tube Guage work 18:01
17:48 TCS TJ, Christina LVEA Y Planning of diisposal of old TCS equipment 19:21
17:52 FAC Kim LVEA Y Technical Cleaning 18:38
18:01 TCS Camilla LVEA Y TCS Equipment Disposal/Removal/Recycle 19:21
18:08 EE Marc EY N Continued troubleshooting of local oscillator malfunction 18:55
18:44 VAC Gerardo, Jordan, Travis LVEA Y HAM7 Leak Checks 19:03
19:45 FAC Randy EX N Garb room curtain pack-up 22:43
19:46 PCAL Tony, Caroline PCAL Lab N Pack up PCAL equipments 19:49
20:54 PCAL Tony, Caroline PCAL Lab Local PCAL Measurements 22:37
20:57 TCS Camilla Optics Lab N Tidying 21:34
22:52 EE Marc LVEA Y HAM6 Chassis Inspection 22:59
23:12 TCS TJ LVEA Y Inventory of chiller equipment SNs and then chiller line management 01:12
23:22 SUS Sheila, Betsy EX Y Troubleshooting ETMX Issues 01:22
23:25 VAC Gerardo, Jordan EX Y Parts search 01:25
H1 CDS
david.barker@LIGO.ORG - posted 16:06, Tuesday 25 August 2026 (91680)
h1daqnds1 daqd restart related to client request volume

Jonathan found a correlation between the number of NDS requests around 15:15 this afternoon and the crash of nds1-daqd. Plot show number of processes and cpu usage against nds1-daqd uptime. Logs suggest a nds client rapidly asked for data, possibly on cdsws37.

Images attached to this report
H1 SUS
camilla.compton@LIGO.ORG - posted 15:37, Tuesday 25 August 2026 - last comment - 11:19, Wednesday 26 August 2026(91678)
ETMX L1 UL Jumped ~2000 counts twice with Earthquakes

Besty, Oli, Ibrahim, Camilla. Follow on from 91650.

Betsy said that the OSEMINF INMON channels should not change much (over last two years has been < 300 counts) but twice in the last 2 months H1:SUS-ETMX_L1_OSEMINF_UL_INMON  has jumped ~2000 counts, both at the time of large earthquakes and when the EX ISI tripped:

Strangely this is not the same quadrant that has been the non responding (91650).

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 11:19, Wednesday 26 August 2026 (91691)

Looking at both of these times, the reason why we moved so much is mostly* due to the OPTICALIGN OFFSETs being turned off.

* ETMX L1 UL DOES still shift a lot when we are in aligned before and after the earthquakes.

On June 24th, at the time where Camilla noted everyone shifting, it was because ETMX had been taken from ALIGNED to DAMPED. DAMPED turns off the OPTICALIGN OFFSETs, so this caused M0's F1, F2, F3 and all of L1's osems to shift. However, looking later on when ETMX is taken back to the ALIGNED state, everyone goes basically back to where they had been before except for L1 UL, which is now over 1900 counts shifted (flag moved out) from where it had been before.

On July 17th, a similar thing happened. ETMX was taken to SAFE, which turned off the OPTICALIGN OFFSETs. A day later it was finally put back into ALIGNED, and once that happened the only osem that read sustantially differently compared to before was L1 UL, which differed by 1100 counts (flag moved out again).

 

Why did L1 UL shift in the same direction so much both times? Is this related to LL? Find out next time (hopefully)

Images attached to this comment
H1 CDS (CDS, VE)
patrick.thomas@LIGO.ORG - posted 14:44, Tuesday 25 August 2026 (91676)
PT180 changed to BCG 552, PT140, PT191, PT192, PT193 removed
WP 13532.

Dave, Gerardo, Jordan, Patrick

The EtherCAT configuration and PLC code on h0vaclx have been updated to change the PT180 gauge on BSC8 from a BCG 450 to a BCG 552. In the process I found out that PT140 had been removed in the past month or so, so I also removed it from the configuration and code. I also had errors from PT193, and learned that it was potentially broken, and along with PT191 and PT192 was slated for removal. I therefore asked Jordan to disconnect these from the EtherCAT hub, and removed them from the EtherCAT configuration and PLC code as well.

When I tried to take the system to OP, the second section of the CU1128 EtherCAT hub kept going into an error state. I eventually tracked it down to what I think was a mismatch between the vendor id of the hub in the TwinCAT solution and that of the actual hardware. Oddly I don't remember this being an issue in the past. I could find no indication of what the vendor id was in the solution, other than what the error was reporting, or how to change my script to make it match. I found a way around this by selecting and choosing 'change to compatible type' for each of the three parts of the hub in the generated solution, rescanning the IO tree, and when it showed mismatches in the version numbering, used the dialog box to change what was configured to what was found by the scan. This seemed to fix the problem.

Dave restored the PID and other settings from SDF. The channels have been updated in the DAQ. The tripped high voltages have been turned back on. I have closed the work permit.
H1 TCS
thomas.shaffer@LIGO.ORG - posted 13:52, Tuesday 25 August 2026 (91675)
TCS chiller lines inspection

FAMIS (no number atm)

This morning I inspected the lines starting from the chillers and then went to each table. Everything looked good: no leaks, stress on pipes, etc.

I did have a scare when I saw liquid pooling around the Leak Detection Dixie Cup (LDDC) on the mech room mezzanine. Turns out it was glycol from the HEPI lines and it just happened to land next to the LDDC after dripping down an extention cord, dripping down two pipes and finally resting next to the cup. Jim was notified, picture sent.

H1 SEI
jim.warner@LIGO.ORG - posted 13:50, Tuesday 25 August 2026 (91674)
CS HEPI Plumbing leak on Mezzanine

TJ reported this morning that he found glycol from the CS HEPI plumbing on the mechanical room mezzanine this morning. I went and looked, there is a large puddle where the the pump station manifolds are joined to the LVEA piping by some thick rubber hose clamped by pipe clamps. The supply line seems to have a very slow seep that has been dripping onto the mezzanine deck for an unknown period of time. Puddle is in the first image, the leaking connection is the lower yellow boot on the stainless pipe in the second image. I put down a bunch of pads to soak up the glycol and cinched down the hose clamp on the side of the boot that is leaking about 1/4 turn. I will come back and clean up more of the glycol and try to put some clean padding down to try to help with assessing how bad the leak is or if tightening the hose clamp fixes the leak. If this needs replaced it will be a huge mess and probably require shutting HEPI down for an extended time. If that is the case, we can probably lock all the HEPI's in the corner (like LLO does). I would prefer sealing the seep with epoxy if possible.

Images attached to this report
H1 ISC
marc.pirello@LIGO.ORG - posted 13:50, Tuesday 25 August 2026 (91672)
ALSY WFS Demod Repair Complete

WP13548

Intiially Fil replaced the ALSY WFSA Quad Demod S1001021 with one of our new spares S2600094 due to bad readbacks.  These bad readbacks were caused by corrisoin and shorting due to mouse urine, see first image.  We cleaned up the malfunctioning unit and it tested good.

The spare that was installed exhibited some of the same characteristics, bad readbacks, so troubleshooting lead us to replace the Beckhoff modules.  This did not solve the issue, so we went back to look at the connections, and found that the spare exhibited bad LO and RF monitor channels when a 6k resistor was placed on the bad channels, absent the Beckhoff.  This lead us to believe there was an issue with the chassis, so we swapped back the original WFSA Quad Demod S1001021 and investigated the sprae S2600094.  Visual inspection lead us to these poorly installed zero ohm resistors, see second image, that are positioned right before the final DB9 on the IQ Demod board.  We are now investigating all of the new Quad Demods for the same issue.

Marc P, Fil C, Keita K.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 13:26, Tuesday 25 August 2026 - last comment - 15:22, Tuesday 25 August 2026(91671)
CDS Maintenance Summary: Tuesday 25th August 2026

WP13536 SUS BS additional fast channels

Oli, Dave:

We installed Oli's latest h1susbs which added 13 new fast DQ channels, most at 2k, some at 256Hz. h1susbs model was restarted at 12:37 and the DAQ soon after.

WP13535 Add DAQSTAT channels to DAQ

Dave:

The new DAQSTAT's non-string records were added to the DAQ as EDC channels.

WP13542 Remove h1daqscript0 epics-load-mon channels from DAQ

Dave:

A new H1EPICS_CDSMON.ini was generated sans DAQSCRIPT0 channels. DAQ restart was needed

WP13532 Upgrade VAC LX Beckhoff and IOC, update PT180, remove obsolete gauges.

Patrick, Dave:

Patrick installed the latest VAC LX code and I installed its new INI file into the DAQ. 

Gauges removed: PT140, PT191, PT192, PT193.

PT180 was modified, some channels removed, some added, some stayed the same name.

Note that PT180's MOD1 and MOD2 gauges have been reversed

  Before Today Now
MOD1 Had been BSC8 gauge, recently has been reading zero reads ~900
MOD2 Had been reading ~740 Now is BSC8 gauge, reading 7e-08 Torr

DAQ Restart

Jonathan, Dave

We did a DAQ restart, 1-leg and EDC at 12:39, 0-leg at 12:41. Frame writers (which are not restarted with the new code) had caught up with the new run number and were writing identical full frames at 12:44.

Comments related to this report
david.barker@LIGO.ORG - 15:22, Tuesday 25 August 2026 (91677)

At 15:16 NDS1 restarted itself. Jonathan is investigating.

H1 SEI
shoshana.apple@LIGO.ORG - posted 13:03, Tuesday 25 August 2026 - last comment - 15:54, Tuesday 25 August 2026(91582)
HAM3 CRS Noise Budget

Started making a new HAM3 noise budget with the CRS included

CRS out of loop measurement (1470454819) : Witnesses the table rotation. Looks how we expect it, with the CRS tilt measured more or less matching the predicted noise cure below 1Hz and matching the GS13. (Figure 2)

CRS in loop measurement (1470458418): Figure 3 shows the RY blends on HAM3 with the CRS in loop (i.e. with a bandpass filter),

Figure 4 shows the Noise Budget for the platform, with the GS13 and CRS tilt measurements, the predicted tilt, and the noise contribution from each sensor. The CRS measured tilt falls a bit below the predicted tilt, but this might be from the various sensor noise estimates (most likely CRS) being a bit higher than realitly, or the ground tilt estimate being inaccurate at low frequencies. 

Figure 5 and 6 shows the CRS noise contributions to the CPS and GS13 respectfully

Figure 7 shows the CRS noise budget

These are still a little rough and I'll keep working on them. In particular, I'm slightly confused on why the CRS noise contribution is so dominate in for the GS13.

Images attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 15:54, Tuesday 25 August 2026 (91679)

Thanks for adding the in-loop crs functionality to the noise budget, this looks great. Note, the base infrastructure for this noise budget is described here: https://dcc.ligo.org/LIGO-G2100779

Since the orange curve on Figure 4 is the predicted residulal motion, we don't necessarily expect the measured in-loop CRS to match it. The in-loop sensor signal might be low, but still impress some of it's own (or other blended sensors) noise into real platform motion.

This new predicted residual platform tilt noise (crs in loop) is probably a good enough proxy to be used as an input to the horizontal loop to help design new X blend filters.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 10:05, Tuesday 11 February 2025 - last comment - 12:38, Wednesday 26 August 2026(82740)
table of PR2 spot position vs measured power in ghost beam

Mayank, Sheila

We now have a number of power measurements at the HAM3 viewport, with corresponding estimates of the beam spot position on PR2 (from  July 2024 78878, yesterday's measurement of 8mW at PR3 yaw -74 urad 82722)

date range PR3 yaw slider value Y2L coefficient spot position on PR2 (in the plus Y direction from the center of the optic) power measured at HAM3 viewport [mW]
July 2018 until July 2024, except for a few days 152 -7.4 14.9 47  
July 5 2024 132     28
July 5 2024 110     19
July 5 2024 100     17
July 2024- Feb 6 2025 100 -6.25 12.588    
May 21st 2024, and Feb 6th- Feb 10th 2025 -74 -3 6 8  
Feb 10 2025 -230 to be measured   to be measured

We used Elenna's new calibration of PRC power 8724 to estimate that we have 2.53kW of power in the PRC beam.

Comments related to this report
sheila.dwyer@LIGO.ORG - 12:38, Wednesday 26 August 2026 (91692)

Louis, Sheila

with PR3 yaw slider at -230, the A2L coefficient was measured as 0.15, 82788.  power at the viewport was logged by Jennie Wright in 82793

Displaying reports 1-20 of 89034.Go to page 1 2 3 4 5 6 7 8 9 10 End