Displaying reports 1021-1040 of 84067.Go to page Start 48 49 50 51 52 53 54 55 56 End
Reports until 07:57, Wednesday 02 July 2025
H1 CDS
david.barker@LIGO.ORG - posted 07:57, Wednesday 02 July 2025 (85497)
HWS camera control shows running status

Tuesday morning I found that HWS ETMY camera control had stopped running at 06:27 PDT for unknown reasons. This was discovered when H1 went out of lock at the start of maintenance and the ETMY camera was not enabled. This was not an actual issue because the ETMY camera is turned off.

To bring attention if a camera controler stops running I made two changes the camera control system:

1) Added GPS times to the controller code (required loading python3-requests and python3-dateutil for gpstime)

2) Added run-status widgets to MEDM, if a camera controller's GPS falls behind by 5 minutes or more its MEDM shows a purple block

Attachment shows ETMY in a stopped state.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 07:51, Wednesday 02 July 2025 - last comment - 14:51, Wednesday 02 July 2025(85496)
Wed DAY Ops Transition

TITLE: 07/02 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 8mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

Rough night continues after Maintenance Day with rung up violins and input alignment shift. 

Comments related to this report
corey.gray@LIGO.ORG - 08:50, Wednesday 02 July 2025 (85499)SUS

NOTE:  Well, after getting H1 back to 60W, the violins are not rung up and better than how they looked at the end of my shift yesterday.

(Sheila & Todd are now looking at the Squeezer & I returned H1 to be able to "Observe WITH Squeezing".)

ryan.crouch@LIGO.ORG - 14:51, Wednesday 02 July 2025 (85503)SUS

I noticed ETMX mode1 has been high ever since coming back from maintenance yesterday and we usually don't damp this mode. I took a high res spectra to confirm that it was this mode and not another close line causing this and it was so I tried to find some damping settings.

Nothing worked all that well, some tentative new settings are FM1+FM2+FM10 G=-50.

H1 SQZ
oli.patane@LIGO.ORG - posted 05:40, Wednesday 02 July 2025 - last comment - 06:27, Wednesday 02 July 2025(85494)
Ops OWL Intervention part 3: SQZ Edition continued

Called again due to the squeezer FC, same as last time. I've checked and the OPO temp maxes out H1:SQZ-CLF_REFL_RF6_ABS_OUT, and the adjustment I made earlier to FC1 and FC2  gets H1:SQZ-FC_TRANS_C_LF_OUT almost at 100. The FC is losing lock at atmost the same spot - it's getting to TRANSITION_IR_LOCKING and is saying that green is losing lock either right after loading in the LSC matrix, or after the same spot as before, after changing the DOF1 gain to 0.

I don't know what else to try, so I ran Ryan Short's script for changing the default guardian SQZ states so that we could go into Observing without squeezing until I can contact someone at 13:00UTC.

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 06:27, Wednesday 02 July 2025 (85495)

We've been approved to continue to do Observing without Squeezing until people are able to look at the issue when they get onsite

H1 SQZ
oli.patane@LIGO.ORG - posted 02:36, Wednesday 02 July 2025 (85493)
Ops OWL Intervention part 2: SQZ edition

Got called again, this time because the SQZer unlocked and the filter cavity was having trouble relocking. Green could lock fine and it would find IR, but it would unlock before getting to IR_LOCKED. I did the normal thing of adjusting FC2, and later FC1, while trying to maximize H1:SQZ-FC_TRANS_C_LF_OUT, but it didn't help. It seemed like as soon as the gain was changed from 1 to 0 for the H1:SQZ-FC_LSC_DOF1 filter bank during TRANSITION_IR_LOCKING, green would lose lock. Does this make sense or is it just a coincidence?

I tried adjusting the opo temperature just in case, but that didn't seem to help either, at least I don't think it did? It kept going back to just green locked whenever we would get to IR locked. I just realized that we lost lock, and trending back it looks like we lost lock a few minutes before I started adjusting the opo temperature, so that makes sense why the FC guardian was being weird and kept going back to green locked.

Anyway, hopefully that worked, otherwise I'll be back.

H1 General (ISC, SQZ, SUS)
oli.patane@LIGO.ORG - posted 00:16, Wednesday 02 July 2025 - last comment - 10:07, Wednesday 02 July 2025(85492)
Ops OWL Intervention: SDFs edition

H1 Manager called on me to help with a bunch of SDF diffs.

- Some ASC POP A offsets, which were accepted in safe earlier today (85490), so I went ahead and accepted them for Observe as well

- IMC PZT offset changes, which were made earlier when working on realigning the IMC (85476)

- ALSX camera offsets, which were changed earlier (85472)

- the SR3 and SRM dackill bypass times were lengthened temporarily for part of the work today, which I realize now should have been reverted oops need to fix when we're out of Observing tomorrow

- SQZ OPO servo's common board excitation had been left switched on (switch on the right from EXC A), so I just opened the switch

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 10:07, Wednesday 02 July 2025 (85500)

Reverted DAQ Kill Bypass times to their 1200 values (per Oli's note above).

Images attached to this comment
LHO General
ryan.short@LIGO.ORG - posted 22:14, Tuesday 01 July 2025 (85491)
Ops Eve Shift Summary

TITLE: 07/02 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY: H1 has not been fully locked since before the maintenance period this morning, although I don't believe anything done during maintenance is to blame.

After maintenance, violin modes were very rung up, so we've been spending long stretches in OMC_WHITENING (when we've been able to get there) damping. Nominal violin damping settings have been working, it's just been taking a while to bring them down. On all three occasions where we've been damping violins here this afternoon and evening, there have been random locklosses (from sources I haven't been able to determine) before reaching NOMINAL_LOW_NOISE. Jitter noise injections were being run during one of these locklosses, but that didn't appear to be the cause, reinforced by the fact that these were run again the next time in OMC_WHITENING and there was not a lockloss. In addition, a few minor earthquakes and DRMI taking it's usual long time to catch have been making lock acquisition take seemingly longer than usual. I'm not sure what else there is to try as alignment has generally looked good this evening and overall I've been able to make locking progress before an inevitable out-of-nowhere lockloss happens.

H1 is currently trying to lock DRMI.

H1 SQZ
matthewrichard.todd@LIGO.ORG - posted 17:27, Tuesday 01 July 2025 (85488)
Moving OPO crystal and NLG Measurements

M. Todd, S. Dwyer


This morning Sheila and I went out to HAM7 to move the OPO crystal to try and get rid of some loss, continuing from this work.

We got the translation stage driver out of the SQZ cabinet and after a bit of fiddling with the connector, we were able to see a response in the IR and Green transmission.

From here we moved the OPO to the right and then back to the left, measuring the NLG and Threshold Power at each position:

Position Max OPO Therm. Green Launch Unamp. Dark NLG P_thres[uW] P_set [uW] Notes
0 0.0577 30.698   0.00663 0.0000232 8.73 90.35 80 8:58 AM
20 0.052 30.647       7.87 91.65 80 9:06 AM
40 0.049 30.618 20.7     7.41 92.47 80 9:15 AM
60 0.0477 30.593 19.85     7.22 92.87 80 9:21 AM
0 0.0494 30.61 20.5     7.47 92.36 80 9:25 AM
-10 0.0498 30.612 20.6     7.53 92.24 80 9:33 AM
-20 0.0499 30.613 20.7     7.55 92.22 80 9:37 AM
-40 0.0502 30.616 20.8     7.59 92.13 80 9:41 AM
-60 0.0508 30.624 21     7.69 91.97 80 9:45 AM
-80 0.0512 30.63 21.2     7.75 91.86 80 9:52 AM
-100 0.0515 30.634 21.3     7.79 91.78 80 9:55 AM

As you can you see when we "returned" to our starting position our NLG never returned to its starting point. Sheila and I went back into the control room to try and recover the NLG via adjusting the OPO temp, but in un-plugging the driver before digitally closing the connection, we think we kicked the OPO into a very different position than expected. To even get something sensible we had to change the OPO temp by over one degree celcius -- far more than should be necessary to get the Green and IR to be coresonant.

So after lunch, we back into the LVEA and connected the driver again as well as a function generator to the OPO PZT, reading the IR and Green transmissions onto a scope. We also increased the seed power to 2W so that we could see it on the scope more easily. Ensuring the connector was more properly setup, we moved the OPO a BUNCH to the left to get the Green and IR to be co-resonant. After awhile the driver would not let me move it to the left anymore, (though it would let me move to the right a couple steps but then NOT retrace my steps back left...), so we decided to leave it as it was. At the end of it we had moved 22 x 50 steps (+ 1 x 10 steps) to the left, and decided to do the rest of the actuation with the OPO temp.

We measured the NLG in the final position and it was disappointingly low but we decided to regroup and think about things.

Position Max OPO Therm. Green Launch Unamp. Dark NLG P_thres[uW] P_set [uW] Notes
-1110 0.00186 30.46 15.5 3.40E-4 -2.70E-5 5.137 99.34 80  
-1110 0.00280     3.48E-4 -2.70E-5 7.539 121.06 105  

More to come, and more to think about!

H1 CAL (CAL)
francisco.llamas@LIGO.ORG - posted 17:17, Tuesday 01 July 2025 - last comment - 17:07, Monday 14 July 2025(85487)
PCAL EX Measurement
DriptaB, FranciscoL, TonyS

Measurement summary:

Resumed routine end station measurement post O4c comissionning break. Procedure following T1500062 went smoothly. The beams as found are shown in the first attached image, were both pcal beams are shown in the IR card. The beam target was placed to have a reference of the "center" of the input aperture. The second attached image shows both pcal beams after the measurement procedure, showing no change in alignment. Forgot to use target and was under a time crunch to finish procedure. Results are nominal -- there are no outliers found on the plotted trends. We thus conclude, from the reported measurement, no need to update EPICS values for PCAL X "Force coeff. calculation".

Terminal output from data analysis script:

$python3 generate_measurement_data.py --WS PS4 --date 2025-06-24
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2025-06-24 corrected to ES temperature 299.2 K :
-4.70052522573445 -0.0002694340454223 2.66508565972755e-05
Copying the scripts into tD directory...
Connected to nds.ligo-wa.caltech.edu
martel run
reading data at start_time: 1435423390
reading data at start_time: 1435423770
reading data at start_time: 1435424085
reading data at start_time: 1435424665
reading data at start_time: 1435425020
reading data at start_time: 1435425335
reading data at start_time: 1435425435
reading data at start_time: 1435426070
reading data at start_time: 1435426405
Ratios: -0.46199911560110457 -0.4661225769446798
writing nds2 data to files
finishing writing
Background Values:
bg1 = 9.235188; Background of TX when WS is at TX
bg2 = 5.284960; Background of WS when WS is at TX
bg3 = 9.145166; Background of TX when WS is at RX
bg4 = 5.413446; Background of WS when WS is at RX
bg5 = 9.219525; Background of TX
bg6 = 0.642557; Background of RX
 
The uncertainty reported below are Relative Standard Deviation in percent
 
Intermediate Ratios
RatioWS_TX_it = -0.461999;
RatioWS_TX_ot = -0.466123;
RatioWS_TX_ir = -0.455904;
RatioWS_TX_or = -0.461457;
RatioWS_TX_it_unc = 0.092717;
RatioWS_TX_ot_unc = 0.098001;
RatioWS_TX_ir_unc = 0.097458;
RatioWS_TX_or_unc = 0.092076;
Optical Efficiency
OE_Inner_beam = 0.986610;
OE_Outer_beam = 0.990080;
Weighted_Optical_Efficiency = 0.988345;
 
OE_Inner_beam_unc = 0.062698;
OE_Outer_beam_unc = 0.063147;
Weighted_Optical_Efficiency_unc = 0.088986;
 
Martel Voltage fit:
Gradient = 1636.767545;
Intercept = 0.229197;
 
 
Power Imbalance = 0.991154;
 
Endstation Power sensors to WS ratios::
Ratio_WS_TX = -1.077445;
Ratio_WS_RX = -1.391120;
 
Ratio_WS_TX_unc = 0.058121;
Ratio_WS_RX_unc = 0.042422;
 
=============================================================
============= Values for Force Coefficients =================
=============================================================
 
Key Pcal Values :
GS = -5.135100; Gold Standard Value in (V/W)
WS = -4.700525; Working Standard Value
 
costheta = 0.988362; Angle of incidence
c = 299792458.000000; Speed of Light
 
End Station Values :
TXWS = -1.077445; Tx to WS Rel responsivity (V/V)
sigma_TXWS = 0.000626; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS = -1.391120; Rx to WS Rel responsivity (V/V)
sigma_RXWS = 0.000590; Uncertainity of Rx to WS Rel responsivity (V/V)
 
e = 0.988345; Optical Efficiency
sigma_e = 0.000879; Uncertainity in Optical Efficiency
 
Martel Voltage fit :
Martel_gradient = 1636.767545; Martel to output channel (C/V)
Martel_intercept = 0.229197; Intercept of fit of Martel to output (C/V)
 
Power Loss Apportion :
beta = 0.998895; Ratio between input and output (Beta)
E_T = 0.993606; TX Optical efficiency
sigma_E_T = 0.000442; Uncertainity in TX Optical efficiency
E_R = 0.994705; RX Optical Efficiency
sigma_E_R = 0.000443; Uncertainity in RX Optical efficiency
 
Force Coefficients :
FC_TxPD = 7.903342e-13; TxPD Force Coefficient
FC_RxPD = 6.193451e-13; RxPD Force Coefficient
sigma_FC_TxPD = 5.805084e-16; TxPD Force Coefficient
sigma_FC_RxPD = 3.826232e-16; RxPD Force Coefficient
data written to ../../measurements/LHO_EndX/tD20250701/
Images attached to this report
Non-image files attached to this report
Comments related to this report
francisco.llamas@LIGO.ORG - 17:07, Monday 14 July 2025 (85753)CDS

Comment regarding the missing signal on the EX Pcal MEDM:

We noticed that H1:CAL-PCALX_OFS_DRIVE_MON was not working as expected a few weeks ago. On this expedition to make ES measurements, Dripta and I used a few breakout boards to ensure that the "OFS drive monitor" signal was coming out of the Pcal chassis and into the ADC Chassis. We confirm that there was a signal coming out of the Pcal Interface Chassis back board (D1400149V1), the DB9 output labeled "To Fast ADC", pins 1 and 6 (not the same name but, by process of elimination, we assume that "OFS drive monitor" is, in the drawing, "InLoopOut±") , so we can rule out the Pcal chassis. Due to lack of time, however, we were not able to pinpoint the step at which this signal is lost.

Tony found the next step in our hunt: Page 3 of D1300226V13 shows the ADC side of "To Fast ADC", specifically, "ADC CHAN±00" is assigned, in the drawing, to InLoopOut± . I am tagging CDS for any insight on their side. Discussions and a follow-up plan are in progress to find the signal.

H1 ISC (SEI)
elenna.capote@LIGO.ORG - posted 16:41, Tuesday 01 July 2025 - last comment - 18:24, Tuesday 01 July 2025(85486)
HAM2 taken offline, seems to change IM alignment

Jeff, Sheila, Elenna

Executive summary: Our input alignment has changed. We know this because the alignment onto IM4 trans has changed. This corresponds to the IMs 1-3 OSEMs showing a change, which corresponds with HAM2 being taken offline to change the power supply.

Today, an H1SEI23 power supply was replaced, and preceding this activity HAM2 and HAM3 were taken offline, 85475.

When HAM2 came back online, the OSEM readbacks on IMs 1-3 showed a change in both pitch and yaw. The table below summarizes how much each suspension's alignment has changed.

IM Pit change (urad) Yaw change (urad)
1 2 0
2 66.8 2.7
3 14.8 4.3

This shift in alignment is also apparent on IM4 trans, which shows the pitch offset has increased by 0.3 and yaw offset by 0.03 (uncalibrated).

We first noticed something had changed when we ran input alignment- I had to move PR2 by 5 microradians in both pitch and yaw just to get the lock to catch, and then the alignment offload further changed the PR2 sliders.

This change is further backed up by the fact that the POP A offsets have changed, and the PRG at 2 W seems to have decreased slightly.

We're not sure how bad of a problem this is. We have been able to lock and power up with no issues. We had a random unrelated lockloss, so I cannot yet see if the buildups at full power once thermalized have changed significantly.

The locking process is now much slower again, since the alignment offsets for the PRM have changed, and the convergence of the PRM ADS tends to set the rate at which we can engage ASC in full lock.

The first two attachments are screenshots show the shift in the IM alignment and IM4 trans alignment. I included the HAM2 ISI guardian state to show this change corresponds with HAM2 going offline.

The third attachment shows how the POP A offset has changed at full IFO 2 W. We can use this scope to adjust the POP A QPD offset and speed up locking, if we want to keep this input alignment.

The fourth attachment shows the ITMX green camera offset screen in full IFO at 2 W. I was watching this screen to confirm the new ITMX green camera offsets I set earlier today were ok. I think the set value differs from the live value here because of the new input alignment.

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 18:15, Tuesday 01 July 2025 (85489)

We sat at full power for 1 hour and had thermalized to a PRG of 49. Trending back to our last lock before maintenance it looks like we achieve about the same PRG in this amount of time, so there is minimal impact on the buildups. There might be a small reduction in the jitter coupling. We should check again when fully thermalized to be sure.

elenna.capote@LIGO.ORG - 18:24, Tuesday 01 July 2025 (85490)

Since we are going to stay this way for at least tonight, I updated the POP A offsets to help shorten ENGAGE ASC FOR FULL IFO. SDF attached.

Images attached to this comment
H1 SUS
oli.patane@LIGO.ORG - posted 16:37, Tuesday 01 July 2025 - last comment - 15:34, Friday 11 July 2025(85485)
Satamp swap OSEM noise first looks

I ran my damp_regression_compare script (85369) on the suspensions that we swapped the satellite amplifiers for today, BS, PRM, PR3, SRM, and SR3. The results show a decrease in the OSEM noise of at least 2x!

Part of what the script does is save the channel data as a .mat file so it's quicker to run next time, so I'll post that as well as the results.

BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12374

Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435348334_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435435046_1200.mat
    r12373

PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12376

Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435435046_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435348334_1200.mat
     r12375

PR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/allDampRegressCompare_H1SUSPR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12380

Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435348334_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435435046_1200.mat
     r12379

SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12378

Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435435046_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435348334_1200.mat
    r12377

SR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/allDampRegressCompare_H1SUSSR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12382

Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435348334_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435435046_1200.mat
    r12381

Non-image files attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 15:34, Friday 11 July 2025 (85696)

Since a few of the before times I picked for some of the suspensions were during times where they had ISC control on, I've rerun them with a better starting time where there was no ISC control

BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435154988vs1435435038-1200.pdf
      r12436

Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435154988_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435435038_1200.mat
     r12437

PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
      r12438
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435435046_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435154988_1200.mat

     r12438

SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
      r12441
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435435046_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435154988_1200.mat

    r12441

Non-image files attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 16:36, Tuesday 01 July 2025 (85455)
Tues DAY Ops Summary

TITLE: 07/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 131Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Maintenance Day.

Model changes, then DAQ restart at noon--

LOG:

LHO General
ryan.short@LIGO.ORG - posted 16:09, Tuesday 01 July 2025 (85484)
Ops Eve Shift Start

TITLE: 07/01 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 18mph Gusts, 11mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY: H1 has just relocked following the maintenance period today, but currently waiting in OMC_WHITENING to damp some very rung-up violin modes. Meanwhile, Elenna is running jitter noise injections. I'm also aware of the OPO crystal move from today, so I'll be watching SQZ performance this evening and will adjust the temperature if need be.

H1 SUS
ryan.short@LIGO.ORG - posted 16:03, Tuesday 01 July 2025 (85483)
In-Lock SUS Charge Measurement - Weekly

FAMIS 28412, last ran and analyzed in alog85311

The analysis for this week's ITMX measurements failed again, same as last week, due to too low of coherence (0.01219488098759549, which is below the threshold of 0.1), so there's not a new data point for the ITMX plot. All other QUAD's analyses ran without issue.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 15:52, Tuesday 01 July 2025 - last comment - 07:53, Friday 11 July 2025(85482)
Early report on HWS cameral control

Camilla, TJ, Dave:

Last Thursday 26th June 2025 alog85373 I restarted the HWS camera control code. We hoped this would improve the 2Hz noise comb in DARM. Initial results for F-Scan (observing) suggest it has not made much, if any difference. 

Attached F-Scans show the spectra on sun22jun2025 and mon30jun2025. The 2Hz comb (blue squares) look unchanged.

More investigation is needed to verfiy we are indeed disabling the frame aquisition on all HWS cameras when H1 is in observation.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 16:33, Thursday 10 July 2025 (85678)DetChar, TCS

Looking at the HWS camera data, Dave's code was successfully stopping the HWS camera dueing NLN from 27th June, as expected 85373.

However, looking at the f-scans from the last week, the 2Hz comb was there until 3rd July but was gone on 4th July and hasn't returned since.

Nothing HWS related should have changed on the 3rd July (ops shift log 85519).

Images attached to this comment
evan.goetz@LIGO.ORG - 07:53, Friday 11 July 2025 (85683)DetChar
Excellent, thank you Camilla and Dave! This is very helpful.
H1 CDS
david.barker@LIGO.ORG - posted 15:25, Tuesday 01 July 2025 - last comment - 15:44, Tuesday 01 July 2025(85479)
CDS Maintenance Summary: Tuesday 1st July 2025

WP12649 Add h1ascimc WFS_B_DC chans to DAQ

Elenna, Dave:

A new h1ascimc model was installed which adds two 16kHz versions of the WFS_B_DC channels to the DAQ. The new channels are

H1:IMC-WFS_B_DC_[PIT,YAW]_OUT_16K_DQ

A DAQ restart was required.

WP12635 VACSTAT HAM1 update

Dave:

A new H1EPICS_VACSTAT.ini was generated. This removes the temporary H1-PT100B VACSTAT gauge and adds the new HAM1 PT100_MOD2 gauge to the DAQ. After the EDC+DAQ restart, VACSTAT was restarted sans H1-PT100B now it is longer needed by EDC.

WP12637 HWS Camera Control

Dave

As part of getting the HWS camera control system running again, its new IOC was added to the EDC via H1EPICS_HWSCAMCTRL.ini. EDC+DAQ restart was needed

DAQ Restart

Dave, Jonathan, Erik

DAQ was restarted for four changes:

1) New H1ASCIMC.ini, adding two new fast DQ channels.

2) New H1EPICS_VACSTAT.ini, removing obsolete VACSTAT chans associated with H1-PT100B

3) Removed H1EPICS_VACHAM1.ini, which was trending the temporary H1 version ot PT100B

4) Added new H1EPICS_HWSCAMCTRL, new HWS camera control's IOC non-string channels.

This was a very messy restart.

After restarting the h1ascimc model, the 0-leg was restarted. A second restart of GDS0 was needed.

After writing two full frames, FW0 crashed and restarted itself.

Once FW0 was back, the 1-leg was restarted. GDS1 needed a second restart.

About 10 minutes later, FW0 had a second crash. This is not unheard of, but very rare.

In the course of investigating it was discovered that FW1 had an unused 1TB Seagate HDD (sda) which has been generating errors over the past month. We decided to remove this from h1daqfw1 since it served no purpose.

Following the DAQ restart, item 2) removal means I can stop running the temporary EPICS IOC vac_ham1_pressure_converter_ioc. This code no longer runs on opslogin0 in a tmux session.

WP12651 Replace h1seih23 IO Chassis +24VDC power supply

Fil, Marc, Erik, Dave:

h1seih23 was fenced and powered down. The IO Chassis was then powered down and its +24VDC supply was replaced (bad fan bearing). System was powered back up with no issues.

 

 

Comments related to this report
david.barker@LIGO.ORG - 15:41, Tuesday 01 July 2025 (85480)

Tue01Jul2025
LOC TIME HOSTNAME     MODEL/REBOOT
12:30:40 h1asc0       h1ascimc    <<< new model
12:33:47 h1daqdc0     [DAQ]   <<< 0-leg restart
12:34:00 h1daqfw0     [DAQ]
12:34:00 h1daqtw0     [DAQ]
12:34:01 h1daqnds0    [DAQ]
12:34:08 h1daqgds0    [DAQ]
12:34:12 h1susauxb123 h1edc[DAQ]  <<< EDC restart, VACSTAT, H1-PT100B, HWSCAMCTRL
12:35:18 h1daqgds0    [DAQ] <<< 2nd GDS0 restart
12:38:34 h1daqfw0     [DAQ] <<< FW0 First Crash
12:42:18 h1daqdc1     [DAQ] <<< 1-leg restart
12:42:29 h1daqfw1     [DAQ]
12:42:30 h1daqtw1     [DAQ]
12:42:32 h1daqnds1    [DAQ]
12:42:40 h1daqgds1    [DAQ]
12:43:42 h1daqgds1    [DAQ] <<< 2nd GDS1 restart
13:02:52 h1daqfw0     [DAQ] <<< FW0 Second Crash
13:42:22 h1daqfw1     [DAQ] <<< FW1 restarted to remove faulty sda HDD
14:00:38 h1seih23     h1iopseih23  <<< h1seih23 front end power cycle to replace DC power supply
14:00:51 h1seih23     h1hpiham2   
14:01:04 h1seih23     h1hpiham3   
14:01:17 h1seih23     h1isiham2   
14:01:30 h1seih23     h1isiham3   
 

david.barker@LIGO.ORG - 15:44, Tuesday 01 July 2025 (85481)

DAQ Changes (NAME, TYPE, RATE)

+ H1:CDS-HWS_CAM_CTRL_ETMX_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_UPTIME_SEC 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_CONN_VALID 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_ENABLED 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_GLITCH 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_GLITCH_GPS 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_OPERATIONAL 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VALID 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VALUE 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VAL_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_CONN_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_ENABLED 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_GLITCH 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_GLITCH_GPS 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_OPERATIONAL 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VALUE 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VAL_VALID 4 16
+ H1:IMC-WFS_B_DC_PIT_OUT_16K_DQ 4 16384
+ H1:IMC-WFS_B_DC_YAW_OUT_16K_DQ 4 16384

- H1:VAC-LY_X0_PT100B_GPS_TIME 4 16
- H1:VAC-LY_X0_PT100B_PRESS_TORR 4 16
- H1:VAC-LY_X0_PT100B_UPTIME 4 16
 

Displaying reports 1021-1040 of 84067.Go to page Start 48 49 50 51 52 53 54 55 56 End