Displaying reports 1-20 of 89098.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 17:47, Monday 31 August 2026
H1 General
oli.patane@LIGO.ORG - posted 17:47, Monday 31 August 2026 (91759)
Ops EVE Shift End

TITLE: 09/01 Eve Shift: 2330-0045 UTC (1630-1745 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioning ended early today. Not much luck with IR DIFF today. Camilla did the transition to laser safe this afternoon so the LVEA is in LASER SAFE and ready for tomorrow's activities.
LOG:

Start Time System Name Location Lazer_Haz Task Time End
22:23 TCS Camilla, Jackie CHETA Lab n Popping in 22:35
23:43 SAF Camilla LVEA Y->n Transitioning LVEA to laser SAFE 00:01
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:34, Monday 31 August 2026 (91755)
trying to locking ALS DIFF on ETMY

Louis, Sheila, TJ, Camilla, Oli

We have been working on changes to lock ALS DIFF on ETMY.  

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 16:31, Monday 31 August 2026 (91742)
Ops Day Shift Start

TITLE: 08/31 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

LOG:

Start Time System Name Location Lazer_Haz Task Time End
15:30 FAC Kim MY, MX n Tech clean 17:00
17:01 FAC Kim FCES n Tech clean 18:20
17:20 CDS Fil EY n ESD troubleshooting 18:09
19:25 FAC Chris FCES n Saving a snake 19:26
20:52 CDS Jackie Mech Room n BDH chassis install on mezz 22:14
21:47 VAC Gerardo, Jordan EY, EX n EY annulus ion pump troubleshooting, then to EX to prep for TMDS 22:34
22:23 TCS Camilla, Jackie CHETA Lab n Popping in 22:35
H1 GRD (SEI, SPI)
thomas.shaffer@LIGO.ORG - posted 15:32, Monday 31 August 2026 (91757)
Started two new Guardian nodes - CRS_HAM3, SPIH23_STAT

CRS_HAM3 and SPIH23_STAT have been enabled and started. There will be a DAQ restart tomorrow to get their freshly created channels.

CRS_HAM3 - Shoshana had written the start of this node earlier, I started it up and made a few edits to get it to work. Jim and I will be making changes to a few of the tests and testing it over the coming weeks.

SPIH23_STAT - A status node to inform of the state of the SPI system. This node is currently empty but will be filled in as person power and time become available.

Both of these nodes have been added to the overview (see top right corner with other STAT nodes), and the alphabetical overview has also been updated.

 

H1 SPI
jim.warner@LIGO.ORG - posted 15:31, Monday 31 August 2026 (91754)
SPI QPDA & QPDB pitch and yaw calibration measurements

It took a couple tries last week, but I have taken HAM2&3 calibration transfer functions for SPI QPA and QPDB for pitch and yaw. I did this by using the  excitation in awggui that we have used for the CRS calibration using amplitudes similar to what Huyen used recently, located at /ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM3/CRS/Templates/dtt/ryexc2.txt. For RY I used an amplitude of 7e3, for RZ I used an amplitude of 10e3. Isolation loops were engaged on both ISI's and they were running nominal blends (no crs on HAM3), but sensor correction and cps diff were both off.  For each measurement I've saved the excitation and relevant sensors timeseries into mat files that I am adding to SeiSVN/seismic/Common/SPI/DATA, as well as scripts for each excitation to get the data, save the timeseries structure and plot the tfs.

The four attach plots are the tfs for each excitation in the order HAM2 RY, HAM2 RZ, HAM3 RY, HAM3 RZ. For each tf, the SPI and CPS seem to agree very well over a few mhz to ~.2hz, the gs13s go a bit higher in frequency, but aren't good witnesses much below .1hz. On each plot I've indicated amplitude  of the spi to cps tf at one frequency point, I think the calibration should be the inverse of these values. I don't remember the units of the QPD channels, it's not cts. 

From those numbers I get:

HAM2 pitch calibration for QPDB is 19829 nrad/?

HAM2 yaw calibration for QPDB is 20400 nrad/?

HAM3 pitch calibration for QPDA is 231430 nrad/?

HAM3 yaw calibration for QPDA is 237700 nrad?

I think the HAM3 pit calibration is roughly inline with the one Arnaud calculated.

Excitations were all ~40minutes long. The timestamps for each injection are:

HAM2 RY: aug 28 2026 0:29:55 utc

HAM2 RZ: aug 28 2026 1:07:29 utc

HAM3 RY: aug 28 2026 2:00:00 utc

HAM3 RZ: aug 28 2026 2:49:14 utc

Images attached to this report
H1 SUS
oli.patane@LIGO.ORG - posted 14:21, Monday 31 August 2026 (91609)
Rest of test results for HAM-A ECR E2400048 chassis

 Jackie, Oli

Jackie finished retesting the modified HAM-A coil driver chassis that had failed (91418), and they all pass now. Four of the chassis (S1200608, S1201155, S1201162, and S1201165) have the C6 and C20 capacitors as 2.2nF instead of their nominal values, which explains why they deviate from the ideal model at higher frequencies.

S/N Latest date tested Output Impedance (kOhm) SUS Stage OSEMs Rack - Height OSEM Type Looking good? Results saved? Comments
Installed for BHD
S2001178 2026-08-18 1p2 AM2 M1 SUS-M2, U34 BOSEM 2026/08/18: Looking good;
2026/02/02: maybe? CH4 bad above 3000Hz
y Capacitors are nominal
S1200608 2026-08-18 1p2 OMA2 M1 SUS-M2, U24 BOSEM 2026/08/18: Looking good;
2026/02/09: ?? CH1-4 bad above 3000Hz
y ***
S1201155 2026-08-18 1p2 OMB2 M1 SUS-M2, U23 BOSEM 2026/08/18: Looking good;
2026/02/02: CH1-4 bad above 3000Hz
y ***
S1201162 2026-08-18 1p2 OMA3 M1 SUS-M2, U21 BOSEM 2026/08/18: Looking good;
2026/02/09: ?? CH1-4 bad above 3000Hz
y ***
S1201165 2026-08-18 1p2 OMB3 M1 SUS-M2, U19 BOSEM 2026/08/18: Looking good;
2026/02/02: CH1-4 bad above 3000Hz
y ***
Non-image files attached to this report
H1 AOS
keita.kawabe@LIGO.ORG - posted 13:00, Monday 31 August 2026 - last comment - 13:23, Monday 31 August 2026(91725)
Potential POP beam clipping in HAM1

There could be POP clipping outside of the PRC, probably in HAM1. This is just based on the two YAW spot move attempts:

One hypothesis is that the POP path in HAM1 is too low as of now.

When we set up the HAM1 POP path in air in April, the green beam was too high and it was missing the top periscope mirror in HAM1. We used pico in HAM3 to bring the path down (alog 89745). It never made sense and we didn't know why that happened, but we believed that the PR3 angle we were using at the time was good and stuck to that angle.

However, IF PR3 angle in PIT at the time had been wrong, and IF we were now somehow closer to the good PR3 angle in PIT, the entire path would be too low as a result of the April pico adjustment.

In this scenario, the HAM1 top/bottom periscope mirror and the dichroic might look like shown in the bottom of beamPos.png. In this cartoon, the beam size, beam separations and the mirror size are to scale, though we don't know exactly where the beams are. There could be other places where IR is clipped at the bottom, but HAM1 periscope mirrors are most likely because of 45 deg PIT angle.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 23:20, Sunday 30 August 2026 (91738)

As for intra-cavity loss we've been worried about (alog 91696), Sheila wondered if good numbers in the past were measured with the arms kept off-resonant by ALS and some of the bad numbers now were without ALS. If that was really the case, that makes about a factor of 2.2 difference.

Power buildup without ALS is proportional to ~(t_PRM/(1-r_PRM*r_ITM))**2 ~ 60 where t_PRM**2~0.03, r_PRM**2~0.97 and r_ITM**2~0.985.

If the arms are anti-resonant, the reflectivity of the arm is almost 1, so the buildup becomes (t_PRM/(1-r_PRM))**2~130.

camilla.compton@LIGO.ORG - 11:02, Monday 31 August 2026 (91745)

Comparing PR3 the day we did this alignment, 1st April 2026 23:30 UTC plot,  to last week, plot. PR3 is <25urad different which is less than 1mm on the POP periscope. Edit: Keita notes there is a curved mirror after PR2 so 11urad could be a big change.

PR3 in April was P -443, Y -58 on M3_DAMP channels. it is now P -465, Y -34. This is now -22urad in Pitch, +24urad in Yaw from now to April.
On the M1_DAMP it was, in April, P -981, Y -356. It is now P . This is now P -970, Y -357. This is a change of +11urad in Pitch, -1urad in Yaw from now to April.
On the oplev it was, in April, P +4.3, Y -11.1. It is now P . This is now P +3.2, Y -15.6. This is a change of -1.1urad in Pitch, -4.5urad in Yaw from now to April.
None of these would explain needing to pico to stop hitting the POP periscope. PR3 to PR2 distance is 16.2m  (git) so distance from PR3 to HAM1 would be a little more than 2 x 16.2 = ~ 35m. Then 11urad over 35m would be 0.3mm which would not explain change in beam on the periscopeEdit: Keita notes there is a curved mirror after PR2 so 11urad could be a big change.

PM1 (RM3) is moving a lot while in chamber in April but settled with DAMP INMONs around P +460, P +1170. Last week we did not spend any time higher than 500urad in the PM1_M1_DAMP_Y.  

Images attached to this comment
keita.kawabe@LIGO.ORG - 13:23, Monday 31 August 2026 (91753)

You can use the left panel of POP_beam_spot_pos_VS_PR3.png for PR3 PIT motion too, though the sign might look confusing (for PIT, positive displacement on the plot means lower). -22urad of PR3 in PIT means that the beams are now ~14mm down on the HAM2-HAM3 septum if we believe M3_DAMP.

(OTOH if we believe oplev the spot position change is too small to matter, if we believe M1_DAMP it's 7mm higher on the septum so it's the wrong sign. Note that PR3 angle is not the only thing that changes the spot position in HAM1, for example the beam could have been too low on the ITMs.)

The only fact we know for sure is that the beams were found to be too high in HAM1 back then and we used pico for "fix" it. It's possible that the real issue, whatever that was, is gone now and our beams are too low in HAM1.

H1 AOS
louis.dartez@LIGO.ORG - posted 12:12, Monday 31 August 2026 (91747)
Accidentally sent drive to ETMX
[Elenna, Louis]

This a late alog from work done on Friday. Elenna and I were trying to get ALS DIFF to work with ETMY since we are not actuating on ETMX right now. During this process we accidentally kicked the ETMX suspension twice on Friday afternoon (my mistake). This has been shared with Oli, who plans to retake the ETMX health check TFs to determine whether these kicks resulted in any material changes there. Updates regarding getting ALS locked using ETMY will come in another log as that work is ongoing.
Images attached to this report
LHO EPO
tyler.guidry@LIGO.ORG - posted 12:01, Monday 31 August 2026 (91751)
EX Temperature Adjustments
Temperature swings at EX have been on the extreme side since powering on cleanrooms in prep for upcoming work. Zone 3 heater coils, which feed the VEA initially had A, B and C temp sensors online. I have since removed two of the three (A & C). Temperature control for the VEA will now to driven solely by sensor B. Will monitor how this changes in the coming days.

R. McCarthy T. Guidry 
H1 SUS
filiberto.clara@LIGO.ORG - posted 11:52, Monday 31 August 2026 (91750)
ETMY ESD High Voltage Driver

WP 13577

Sheila reported the EY ESD bias was not responding. Readback monitor shows output ~200V regardless of requested voltage. I checked the HV and LV power supplies. Both were powered on. One thing to note, the current draw on the positive 430 and negative 430 power supplies were not the same. I went out to the VEA and verified connections near the flange. The shrink tubing used to isolate the SHV connectors from the cable tray were not installed. I reinstalled them. I verified led lights on both the HV and LV ESD drivers. Both look fine. I enabled and disabled the HV outputs on the UK HV driver and heard the relays switching. Next, I powered cycled the chassis by removing the ±18V with the HV outputs disabled. I disconnected the first two SHV cables (Bias and one of the quadrants). To test the remote enable, Louis enabled the outputs from the control room. The bias slowly ramped down to -430V. First Quadrant went to 140V. High voltage disabled. SHV cables reconnected and repeated to drive the outputs. Louis confirmed the bias readback monitor is responding.

F. Clara, L Dartez

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 11:29, Monday 31 August 2026 (91748)
BSC10 Annulus Ion Pump Railed

The annulus ion pump for BSC10 railed late last night, around 8:50 pm local time.
Nothing to do for now, but soon we will check the annulus ion pump to see what is wrong with it.

Images attached to this report
H1 SUS (SUS)
thomas.roocke@LIGO.ORG - posted 10:35, Monday 31 August 2026 (91746)
QOSEM Noise Hunting - DC Offset vs Noise

Summary: These is no correlation between the DC level of the QPD difference channels and the output voltage noise, suggesting excess resistor noise is not to blame.

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466

Thus far we have rulled out real motion being the casue of this excess noise, as motion measured by the BSC2 GS13's, propagated down to M1 isn't enough to explain it. Leading suspicions are excess noise arrising from the new resistors used in the whitening changes (which in the past have been observed to cause issues, see ENG Log 1028, for more details) or LED noise. A trait of excess resistor noise is a roughly linear increase with increrasing DC voltage across the resistor. As such I would expect a correlation between the DC difference voltage and the noise on the difference signals if this is the culprit.

In Figure 1, we plot the DC level of each of the 12 difference signals from the LHO BBSS QOSEMs, against the voltage noise level of that signal at 15Hz (frequency away from any suspension resonances). Here we see no clear correlation between the DC level and the noise, indicating that its likely not excess resistor noise driving this. 

 

Non-image files attached to this report
H1 SUS (SUS)
thomas.roocke@LIGO.ORG - posted 09:53, Monday 31 August 2026 - last comment - 15:16, Monday 31 August 2026(91744)
QOSEM Noise Hunting - Seismic Driven Motion

Summary: We projected BSC2 SUSP motion as measured by ISI GS13's to the BBSS M1. This shows that seismic motion isn't enough to explain the excess QOSEM noisefloor. 

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466

Here we look at the motion expected in the QOSEM readouts as driven by seimic motion coupling from the SUSP down into M1. Figures 1-6 attached below show the euler DOF readouts from the QOSEMs, compared against the motion measured at the SUSP by the ISI GS13's propagated to BBSS M1 using the suspension transfer functions. In these plots we see that Longitdualal SUSP motion has the largest contribution to the measured M1 motion, but not enough to explain the raised QOSEM noisefloor. With that said, these plots do show that ideally SUSP motion should be the dominant noise source for BBSS M1 below 10Hz.

This data was taken from LHO at T0=1470725000.

Non-image files attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 15:16, Monday 31 August 2026 (91756)SEI

Hey Tom,

It's probably more useful to look at the SUSpoint to GAP rather than the SUSpoint to M1 inertial, where GAP is the thing the qOSEM is measuring, and is approximately M1 - SUSpoint. This should be pretty clean in vertical even though the cross couplings are complex for most other DOFs . Above a few hertz this will look like the ISI motion. The SUS models should make this pretty straightfoward. Also, maybe in scientific notation? 

H1 SPI
jeffrey.kissel@LIGO.ORG - posted 09:46, Monday 31 August 2026 - last comment - 17:28, Monday 31 August 2026(91741)
SPI L Wrapped Phase Excursions on 2026-08-26 @ 17:16 UTC -- Probably Excitation
J. Kissel

I found the SPI L MEAS and REF IFO signals -- namely in its unwrapped phase signal form -- off in the weeds this morning at ~1700 [rad] and ~1000 [rad], indicating that the phase unwrapping algorithm needs to be reset.

I'm probably just gathering statistics here rather than identifying a cause, but since the system is still new, I figure calling out *when* and "what else was going on?" the SPI longitudinal (L) phase signal shows events in which the unwrapping algorithm glitches or drifts off into the weeds is worth it. There were two back-to-back phase excursions on Wednesday 2026-08-26 17:16 and 17:17 UTC (10:16a and 10:17a local PDT). 

Here're a few trends of *some* channels that I thought might be the obvious culprits -- 
    (1) Did the HAM2 or HAM3 (H23) ISIs trip? No.
    (2) Was there large excess motion or glitches in the H23 ISIs? No. (Only X is shown, but I checked Y, Z, RX, RY, and RZ and they also don't show anything)
    (3) Did the SPI's optical levers see anything? Yes, but not excellently correlated.
    (4) Was there main IFO laser light scattered from within the chamber into the SPI? Doubtful. While the IMC was struggling to lock, locking events (i.e. flashes on MC2 TRANS) are not obviously correlated.

I only show the MEAS_A raw phase signal (first row), but the trend of the unwrapped phase shows you that all PDs saw these glitches.

Zooming out, look at the second trends, the phase signal shows that it was "buzzing" at a max and min of -2*pi and +2*pi through out a time from 17:11:32 UTC to 17:17:44 UTC -- which looks very suspiciously like some excitation.
BUT -- the phase excursion doesn't happen until ~80% of the way through whatever excitation this is...

As of this morning -- There haven't been any unwrapped phase excursions since this one.

I've reset the phase unwrapping algorithm on 2026-08-31 16:43 UTC but hitting the H1:SPI-H23_IFO_PHASE_UNWRAP_RESET button, available to hit on each of the MEAS_IFO and REF_IFO CONDITIONING screens, linked from the SPI OVERVIEW.
Images attached to this report
Comments related to this report
sina.koehlenbeck@LIGO.ORG - 17:28, Monday 31 August 2026 (91758)SPI

Note that if the light drops or the interferometer is misaligned, the phase measurement becomes invalid and leads to arbitrary phase accumulation. Therefore, the light level and contrast should always be checked.

H1 IOO
jennifer.wright@LIGO.ORG - posted 14:18, Saturday 29 August 2026 - last comment - 12:05, Monday 31 August 2026(91737)
JAC Heater Guardian updated

Following on from yesterday's alog #91730 today I turned off the JAC Heater controller and switched the gain back to -0.1 and the second pole at 1Hz off also.

I then updated the JAC heater guardian so it switches on and off the Beckhoff JAC Heater Controller and also adds in the normalised control signal from the length feedback to the JAC PZT as an error to the Heater control signal.

The code that does this is:

class HEATER_SERVO_OFF(GuardState):
    index = 20
    request = True
    def run(self):
        ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'Off'
        ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0

        if beckhoff_check():
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return False


class HEATER_SERVO_ON(GuardState):
    index = 1
    request = True
    def main(self):
        self.pzt_fb = ezca['JAC-PZT_DRIVER_VOLTS']
        self.pzt_low = ezca['JAC-PZT_DRIVER_PZTHIGH']
        self.pzt_high = ezca['JAC-PZT_DRIVER_PZTLOW']
        self.servo_setpoint = ezca['JAC-HEATER_CONTROL_SETTEMP']
        self.in_loop_sensor = ezca['JAC-HEATER_THERMISTOR_1_TEMPERATURE']
        self.sensor = 1

    def run(self):
        if beckhoff_check():
            notify(f'Servo on with set temperature: {self.servo_setpoint} deg.')
            ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'On'
            if ISC_library.JAC_locked():
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = (self.pzt_fb/(self.pzt_high - self.pzt_low))
            else:
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return 'HEATER_SERVO_OFF'

                
edges = [
        ('HEATER_SERVO_ON', 'HEATER_SERVO_OFF'),
        ('HEATER_SERVO_OFF', 'HEATER_SERVO_ON'),
        ]

 

It is necessary to normalise the PZT fb signal by the total range of the PZT HV driver before adding the signal into the error point to normalise it.

The code should only include the offset from the PZT error point if the JAC is locked, this is because we don't want it adding random offset while the pzt is scanning.

However we do still want the JAC heater locked to its set temperature when the JAC is unlocked.

From the image you can see that the JAC-HEATER_CONTROL_VOLTSOFFSET is zero until we get past the scanning state (number 20) in the JAC locking sequence.

I will leave this servo on all weekend to test it with the new guardian control.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 12:05, Monday 31 August 2026 (91752)

Long term trend as of this morning.

Images attached to this comment
H1 SPI
jim.warner@LIGO.ORG - posted 17:15, Friday 28 August 2026 - last comment - 09:50, Monday 31 August 2026(91731)
SPI Diff length and HAM2&3 ISI motion

Posting some initial plots of SPI DIFF L, doing my best to line up with my results here with alog 73976, where Jeff looks at IMC F length in hz/rthz and compares that to ISI motion. On the attached image, I show spectra for the differential HAM2-3 X super sensors (calculated online in seiproc, using blended cps and gs13s from each chamber), HAM2 and 3 X gs13s and IMC F, all calibrated to hz/rthz using Jeff's factors from 73976. H1:SPI-H23_DIFFDISP_MAIN_OUT_DQ is also calibrated to hz/rthz using the same 70.551 hz/nm Jeff calculated for the ISI. With that calibration, SPI DIFFDISP is still off from the other sensors by about a factor of 3. 

For the second image, I made a new copy of Jeff's template from 2023, re ran it for last night and added SPI DIFFDISP. We don't have CARM yet, so it's not complete, but I updated references. Again, I used Jeff's 70.551 calibration factor to convert SPI DIFFDISP from nm to hz. SPI seems to agree better here, so I'm not sure what the differences are from from first plot. 

 

Images attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 09:50, Monday 31 August 2026 (91743)

Jim, it's great to see a first length SPI spectrum. Could you calibrate those signals in m/sqrtHz instead? It would be easier to comprehend.

For checking the calibration (and the signs), you could do a simple test by driving one of the HAM2 or HAM3 ISI at the error point of the length (X) loop at low frequency (0.3Hz?) and compare the time series of the SPI and the ISI drive.

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