Displaying reports 601-620 of 83536.Go to page Start 27 28 29 30 31 32 33 34 35 End
Reports until 07:32, Friday 27 June 2025
H1 General
ryan.crouch@LIGO.ORG - posted 07:32, Friday 27 June 2025 - last comment - 13:15, Tuesday 08 July 2025(85383)
OPS Monday day shift start

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

Comments related to this report
ryan.crouch@LIGO.ORG - 07:46, Friday 27 June 2025 (85385)

14:46 UTC DRMI is struggling when ASC starts, I'm going to run a manual_IA

ryan.crouch@LIGO.ORG - 08:43, Friday 27 June 2025 (85387)

At the time of the request for help 10:22 UTC, we were in in CHECK_AS_SHUTTER where it was presumably stuck at SHUTTER_FAIL which I've encountered again at 15:22 UTC. It's been in that state since 09:05 UTC when we lost lock from 25Ws and the SHUTTER GRD reported "No kick... peak GS13 signal = 51.226"

 

Images attached to this comment
sheila.dwyer@LIGO.ORG - 09:03, Friday 27 June 2025 (85388)

The shutter did not trigger in this last lockloss, it looks like the light heading to the AS port was not high enough to trigger the shutter.

The lockloss_shutter_check guardian check for a kick in the HAM6 GS 13s anytime that we loose lock with more than 25kW circulating power in the arms.  In this case we had just reach 100kW circulating power, so the guardian expected the shutter to trigger.  This lockloss looks unusual in that there isn't a increase in the power going to the AS port right before the lockloss. 

Ryan ran the shutter test and the shutter is working correctly now.

I think that this is probably the result of an usual lockloss happening at somewhat lower circulating power than usual.  We should probably edit the logic in IFO notify to call for operator assistance whenever the shutter is in the failed state. 

Images attached to this comment
keita.kawabe@LIGO.ORG - 12:28, Friday 27 June 2025 (85393)

This is OK, the AS port went dark and stayed there for about 70ms or so after the lockloss and there was no excessive power surge that would have caused the fast shutter to be triggered.

The maximum power of ~1.4W was observed ~160ms after the lockloss, which is well below the threshold for the analog FS trigger (3 to 4W, I don't remember the exact number).

If something similar happened with 60W, though, FS might have been triggered.

Attached is the estimate of the power coming into HAM6 using two different sensors (PEM-CS_ADC_5_19 = HAM6 power sensor in the AS camera can which monitors power before the fast shutter, and ASC-AS_A_DC_NSUM after). Neither of these have hardware whitening, neither saturated (ASA was close to saturation but the HAM6 power sensor saturation threshold is about 570W when beam diverter is open, 5.7k if closed).

Note that the calibration of the PEM channel is a factor of 10 smaller than that in the observation mode (0.177W/ct, see alog 81112 and git repo for lock loss tool) because the beam diverter (90:10) was open.

Images attached to this comment
ryan.crouch@LIGO.ORG - 13:15, Tuesday 08 July 2025 (85624)

I made a timeline of what ISC_LOCK was doing during this event.

Images attached to this comment
LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 22:07, Thursday 26 June 2025 - last comment - 22:19, Thursday 26 June 2025(85380)
OPS Eve Shift Summary

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

IFO is in NLN and OBSERVING as of 04:13 UTC

Quite the frustrating shift in which I encountered:

LOG:

None

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 22:19, Thursday 26 June 2025 (85381)SQZ

We disabled SQZ ASC for the night (not FC ASC), to prevent it from running away again overnight until someone can check what happened.

H1 General
ibrahim.abouelfettouh@LIGO.ORG - posted 19:08, Thursday 26 June 2025 - last comment - 20:22, Thursday 26 June 2025(85377)
OPS Midshift Update: Locking Troubles

It has been a difficult relock acquisition following our last lockloss due to a few reasons all related to the inability to lock DRMI:

1. Small local EQ showing up on both primary and secondary microseism.

2. ALSX PLL Crystal Beatnote insufficient for ALSX lock - this comes on and off and was happening largely in the first hour of lock aquisition. There were 9 locklosses at this state in IR, PRMI, DRMI and of course, LOCKING_ALS. I attempted to cycle through "enable/disable" for the ALSX FIBR LOCK on the ALSX PLL page, but this did not help. The issue seems to have largely went away on its own 45 minutes into trying.

3. DRMI/PRMI general alignment. The flashes are good, and I've seen DRMI lock in worse conditions. I touched the BS, PRM, PR2, SRM, SR2 in order to optimize the alignment further but this proved useless.

The first thing I did after the lockloss was to do a full initial alignment, since I heard that the PRMI ASC was fixed. Before my shift, we were having 45 minutes of issues locking DRMI but the initial alignment did not seem to fix this. After 2 hours of trying to touch suspensions, I have decided to do a step-through of initial alignment. I still allowed PRMI ASC to happen automatically (though will do manually if this lock attempt fails). This has just finished and I'm relocking now..

Comments related to this report
ibrahim.abouelfettouh@LIGO.ORG - 19:09, Thursday 26 June 2025 (85378)

DRMI locked almost immediately after a second, manual initial alignment. Strange.

ibrahim.abouelfettouh@LIGO.ORG - 20:22, Thursday 26 June 2025 (85379)

Lockloss from 522 (LOWNLOISE_ASC). Lost lock at LOWNOISE_ASC due to 2.9 South Oregon EQ. DRMI again is not locking despite touching suspensions, going through PRMI, MICH. Flashes are just fine..

Re-locking now and if this continues to fail for another 20 minutes, I will do yet another manual initial alignment, which is so far the only thing that seems to work.

H1 General (DetChar)
oli.patane@LIGO.ORG - posted 17:52, Thursday 26 June 2025 - last comment - 17:59, Thursday 26 June 2025(85374)
Ops Day Shift End

TITLE: 06/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

Currently relocking and stuck not being able to get past DRMI due to it not wanting to lock and some previous ALSX crystal frequency issues. Ibrahim is working on trying to fix that.

When we went back into Observing after Commissioning today at 21:20 UTC, we had accidentally left the beam diverters open, and didn't notice for 20 minutes, so between 21:20 and 21:41 UTC the beam diverter was open. Once we noticed, we went out of Observing, closed it, and then went back ito Observing. tagging detchar


LOG:

14:30 Observing and have been Locked for 7.5 hours
14:38 Lockloss
15:40 NOMINAL_LOW_NOISE
    21:20 Observing after commissioning end
        - We had accidentally left the beam diverter open so this data may not be very good
    21:41 Out of Observing to close the beam diverter
    21:44 Back into Observing with everything looking good
22:29 Lockloss

Comments related to this report
elenna.capote@LIGO.ORG - 17:59, Thursday 26 June 2025 (85376)

Just want to specify that the only beam diverter left open was the POP beam diverter! All other usually-closed beam diverters were closed.

H1 SUS
oli.patane@LIGO.ORG - posted 17:39, Thursday 26 June 2025 (85369)
Script to show difference in SUS noise before vs after SatAmp swap

In preparation for the SatAmp swap (ECR E2400330), I've written a script that allows us to easily compare the noise performance between satellite amplifier swaps. It takes in a suspension name, ifo, and two gpstimes, grabs the DAMP IN data for all dofs, regresses out the ISI GS13 noise, and then compares the leftover noise between the two gps times.

We wanted to have the script divide out the loop suppression, and Jeff looked into which suspensions we've taken valid open loop TFs for (85289). Some suspensions have valid OLTF measurements, so from those we were able to export the loop suppression to divide out (and are saved in the suspension's Data folders), but others don't have valid measurements, so I made it so if there is a valid measurement, it will divide it out from the regressed sensor noise data, otherwise it'll just show the regressed.

Here is an example of the suspension noise before and after a satellite amplifier swap for SR3 that was done at LLO last summer (72417). There was no loop suppression for us to divide out here, so the plots just show the DAMP IN and the leftover sensor noise.

Here is another example for LHO PR3. This one is only meant to be an example of the plots with the loop suppression removed, as the sat amp is the same for both gps times. There is some weirdness around where the peaks were supposed to be removed by the loop suppression - some dofs still show thin peaks. The loop suppression didn't remove them correctly, and we think this might be because the loop suppression assumes a SISO loop, but we might have cross coupling that then is not accounted for when we are dividing by the loop suppression.

The script is located in /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/damp_regression_compare.m, and is a function so it can be called from somewhere else. It has been committed as r12362.

The data that's pulled for the gps time and timespan for the sus dofs and chamber GS13s takes a while to grab the first tme, so I had it save the data in the respective suspension Data folders (ex. /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1405123218_1200.mat). Then if you need to run that gps time + span again it'll get the data right away.

The results get saved in the suspension's Results folder (ex. /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/allDampRegressCompare_H1SUSPR3_M1_NoiseComparison_1405123218vs1433376018-1200.pdf).
 

Images attached to this report
Non-image files attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 16:46, Thursday 26 June 2025 - last comment - 07:30, Friday 27 June 2025(85373)
HWS camera control code running, EPICS monitoring via MEDM

WP12637 Install HWS Camera Controls

TJ, Camilla, Dave:

I made a slight change to my original Dec 2023 hws_camera_control.py code to use the python epics module to do the cagets directly, and to also use this to add caputs which will try, in a non-blocking way, to send the camera's status to a central EPICS IOC.

The central IOC code is hws_camera_status_ioc.py which runs on cdsioc1 under puppet control.

The camera control code runs every minute in an infinite loop. Each loop it checks the status of H1 using Guardian ISC_LOCK (greater or equal to 600 denotes H1 LOCK). If H1 is locked and the camera is on, it turns the camera off. If H1 is not locked and the camera is off, it turns the camera on.

A mini-overview of the 4 HWS cameras (ITMX, ITMY, ETMX, ETMY) is available on the CDS Overview screen. The block is divided into 4 segments, each camera is shown either in SKYBLUE (camera is enabled, images are being taken) or GREEN (camera is disabled, no noise being created).

Note that the color scheme relates to what is nominal for OBSERVE. Green indicates the cameras have power, but their frame acquisition has been disabled.

Clicking on the HWS block on the CDS Overview opens a detailed screen (see attachment). For each camera this shows if the camera is powered (ETMY is the only one powered down) and if the camera is enabled. The control code also reports its current time, its uptime, its start time and details of where and how it is running.

Second attachment shows the four tmux sessions running the control code, and the arguments used.

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 07:30, Friday 27 June 2025 (85384)

Here is the same view when H1 is locked and the cameras have been disabled.

Images attached to this comment
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 16:08, Thursday 26 June 2025 (85368)
Results from applying ECR E2400330 to UK SatAmp S1100173 -- looks good!
J. Kissel, F. Clara
ECR E2400330

Fil modified the UK SatAmp (D0900900 / D0901284) per ECR E2400330, which means "rev'ing" up the D0901284 circuit board inside from -v4 to -v5 (thanks Michael Laxen for the updated drawing!). 

This mod changes the whitening stage frequency response by adjusting the (R180, R181, R182) values from (750,20e3,20e3) to (1.5e3,80.6e3,80.6e3) Ohm, causing the zero:pole pair to move from z:p = (0.384 : 10.6) Hz to z:p = (0.0969 : 5.31) Hz.

I then measured the frequency response with the nearly*** identical procedure as described in LHO:85349. 

The measured results agree with the expected model of z:p = (0.0969 : 5.31) Hz (and a ~7 kHz high-frequency pole) to within +/-1.5% and +/-1.0 [deg], as was the case for the measured results when this same board was at -v4.

I think we're good to go for rev'ing up many of these satamps, and can have excellent confidence in compensating every channel of every satamp with a z:p = (5.31 : 0.0969) Hz digital filter.

***The only difference is that I needed to drop the source voltage from 0.3 V_SRC to 0.2 V_SRC in order to prevent the differential output stage opamps from saturating. Note -- the saturated response was only ~7% different from expectation and only above the frequency-dependent output of the whitening stage exceeded the ~14V that the differential output opamps can push; I got clued in to this subtlety and have a quantitative answer because the ratio between saturated model and measurement sharply kinked up at 6.39 Hz, and rose up to 7% -- consistent across all four channels -- in a non-linear way that couldn't be explained by adding more zeros and poles. #ThreeHoursWasted

Images attached to this report
Non-image files attached to this report
LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 16:03, Thursday 26 June 2025 (85370)
OPS Eve Shift Start

TITLE: 06/26 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 8mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

IFO is LOCKING at ACQUIRE_DRMI_1F

Planning on going straight to observing once locked.

Lockloss during comissioning (not from calibration)

H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 15:32, Thursday 26 June 2025 (85365)
Lockloss

Lockloss at 2025-06-26 22:29 UTC after almost 7 hours

H1 CAL
oli.patane@LIGO.ORG - posted 14:50, Thursday 26 June 2025 - last comment - 16:47, Thursday 26 June 2025(85364)
Calibration Measurement June 26, 2025

Calibration suite was run after 5 hours of thermalization. Before the measurement was run, work had been done to update the SRCL offset (85362).

Broadband
Start: 2025-06-26 20:35:38 UTC
End: 2025-06-26 20:40:49 UTC
Data: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250626T203538Z.xml

Simulines
Start: 2025-06-26 20:42:09 UTC
End: 2025-06-26 21:05:29 UTC
Data: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250626T204210Z.hdf5
          /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250626T204210Z.hdf5

Current version of the pydarm report can be found at /ligo/groups/cal/H1/reports/20250626T204210Z_prospring/H1_calibration_report_20250626T204210Z.pdf. We are investigating further into why the calibration is so different now.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
francisco.llamas@LIGO.ORG - 16:47, Thursday 26 June 2025 (85371)

After inspection on the sensing function from the initially generated report, we changed the model to an anti-spring and to start the fit at 8 Hz, to see if we could get a better calibration from this measurement.

First, we set the is_pro_spring parameter in the H1_pydarm.ini file from True to False. We expected this parameter make the model (orange line) fit better to the measurement (green dots). Overall, there was no noticeable change of the sensing model compared to the initial report, as seen in the first figure (CAL_SENSING_MODEL_ANTISPRING_20250626.png). Additionally, the sensing MCMC corner plots were not gaussian (opposite to what is instructed in T2400215 section 2.4.2), as seen in the second figure (CAL_SENSING_MCMC_CORNER_ANTISPRING_20250626.png).

To improve on the sensing model, we decreased the sensing parameter mcmc_fmin from 10 to 8 Hz. Even though the sensing function is slightly worse at low frequencies compared to the initial report (the one from oli's alog), the sensing corner plot shows more of a gaussian behavior. Additionally, the uncertainty is still within our 10% budget (see snippet of the calibration monitor from grafana CAL_MONITOR_GRAFANA_POST_CALMEAS_20250626.png), so we will pause on this investigation for now.

The updated report is attached as a PDF file. The measurement has not been tagged at the time of posting this comment. We have yet to understand why the model is struggling with the fit parameters.

Images attached to this comment
Non-image files attached to this comment
H1 ISC (SQZ)
sheila.dwyer@LIGO.ORG - posted 13:39, Thursday 26 June 2025 - last comment - 15:47, Thursday 26 June 2025(85362)
updating SRCL offset

measured NLG with seed of 14.15, had to adjust temperature

Fitting to SRCL detuning guesses for these last two points would suggest we should update our SRCL offset to -382 counts (was previously -455).  We will do this now, as we are about to run a calibration measurement. 

While we were at 0 SRCL offset, Elenna looked at the impact of SRM alignment, she will alog this.  It does seem to have an impact of FIS, which is small compared to the impact of the SRC length offset. 

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 15:47, Thursday 26 June 2025 (85367)

I wrote a summary of the SRM alignment moves here: 85366

H1 ISC
elenna.capote@LIGO.ORG - posted 13:02, Wednesday 25 June 2025 - last comment - 15:46, Thursday 26 June 2025(85330)
SRM alignment on POP vs AS72

Today I was able to drive a line on SRM pitch and yaw, aka SRC1 P and Y, in an attempt to understand how the SRM alignment signal appears in various sensors. Our current configuration has SRM alignment controlled via the AS RF72 signal, which is the beat of the 118 MHz and the 45 MHz.

To do this measurement, I engaged the usual 8.125 Hz notches in the ASC loops, and drove at 8.125 Hz at the SRC1 SM exc point. I measured the signals in the I and Q phase on AS RF72, AS RF45, AS RF36 and POP X RF, which is a 45 MHz demod.

First, it is very hard to drive a large enough signal to even see the line in AS RF72 compared to other sensors. We are currently operating with 1 stage of whitening on RF72, for reference. The attachment shows how the signals appeared in the AS WFS as well as the POP WFS for pitch and yaw.

Once I took this measurement, I looked at the time series of the signals. POPX 45 Q pitch has an offset that corresponds to 1.5 urad of SRM pitch offset. I calculated this calibration factor from my injection: 7.37e-5 SRM pitch urad/POPX pit ct. The POPX Q yaw signal also had an offset, but it was much smaller, only 0.24 urad, calibration factor 3.25e-4  SRM yaw urad/ POPX yaw ct

On June 5, the SQZ team adjusted the SRCL digital offset, and when the SRCL digital offset was zero, the POPX Q offsets corresponded to about 0.09 urad of SRM pitch offset and 0.05 urad of SRM yaw offset (sqz alog).

In the past, we have operated with some SRC1 offset, however, that offset is remarkably small compared to even the dark offsets we have applied to the AS RF72 channels. SRC1 p offset was set to -0.042, SRC1 Y to 0.098, while the four segment dark offsets on RF72 Q are -17.8, 0.2, 2.2, 12.9 (medm screenshot).

Overall, I think we should consider a few things:

Sheila has suggested we open the SRC1 loop and try stepping the offset while monitoring the buildups, the effect of the SRCL offset on SQZ, and the overall offsets in AS RF72 and POPX Q.

Whatever effect alignment offsets in the SRC are having on the SRCL detuning seems to be much smaller in yaw than in pitch.

To calibrate the AS RF72 signals into SRM angle, we can use these factors:

0.274 SRM pit urad/ AS RF72 pit ct

0.173 SRM yaw urad/ AS RF72 yaw ct

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 15:46, Thursday 26 June 2025 (85366)

Today, Sheila and I followed up on this, and the results are a bit confusing, but somewhat promising.

To start, Sheila reran the "brontosaurus plot" measurement, where FIS is injected to help determine the SRCL offset. She reports this work here.

While she changed the SRCL offset, I once again monitored the AS RF72 and POP X signals. As Sheila changed the SRCL offset, the offset in POPX did change the same way as I saw yesterday, which is not that surprising.

Then, when Sheila set the SRCL offset to zero, I tried opening the SRC1 loop and moving SRM around. The first thing I noticed is that the calibration I calculated yesterday seems bad, since I was adjusting the SRM yaw by 11 urad (according to the slider calibration), but the change in the POP X yaw offset corresponded to less than 1 urad (according to my measured calibration from yesterday).

I moved yaw in only one direction, with the goal of seeing if I could reduce the POP X yaw offset. However, I gave up after 11 urad because it didn't seem to be doing much at all except to small effect on POP X yaw.

Next, I tried moving SRM in pitch. I went the positive direction, and Sheila and I immediately saw the buildups get worse, so then I went the other way and the buildups got better! This corresponded to a 20 urad change in SRM pitch, according to the alignment slider. The change in the POP X pitch offset was minimal.

We also saw kappa C increase quite a bit, almost too good to be true, so we didn't trust the value since we had a large SRCL detuning at the time. Sheila did see that the change in the SRM pitch had an effect on the squeezing as well.

However, Sheila then determined a better SRCL offset of -382, so we went there, and the kappa C leveled off to 1.02, which was better than our current nominal value of 1. This seemed to hold. Then, I stepped the SRM pitch offset back to the starting alignment and the buildups decreased and kappa C went back to 1.

Following the buildups, there seems to be a better alignment of the SRM in pitch. At this time it seems like yaw has no effect, but I only moved in one direction. I think that, whatever the SRCL offset is, we should move the SRM around in pitch and yaw and see if there is an improvement to be found in the buildups. My current hypothesis is that the RF72 dark offsets are creating some alignment offset in the SRC. After we find a good SRM alignment position, we can recheck the SRCL offset, hopefully with both a squeezing measurement and a sensing function.

We should also probably check the whitening on RF72, maybe next Tuesday.

These results are making me think that probably POP X Q would not make a good signal for SRC alignment, since it is dominated by the SRCL offset.

The first ndscope attached are showing the behavior of the POP X and RF72 signals while changing SRM alignment. The second shows the buildups and kappa C when changing SRM pitch and SRCL offset from 0 to -382.

Images attached to this comment
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 02:14, Wednesday 25 June 2025 - last comment - 16:55, Thursday 24 July 2025(85317)
Annulus Ion Pump for BSC1 Rails

Signal railed about 5:18 PM local time, I checked trend data for PT120 and PT180 and no pressure rise noted inside the main volume.  Attached is 3 day trend of the pump behavior, very glitchy for a long while already.

System will be evaluated as soon as possible.  AIP last replaced on 2015, see aLOG 18261.

Images attached to this report
Comments related to this report
gerardo.moreno@LIGO.ORG - 04:00, Friday 27 June 2025 (85382)VE

Well, it appears as if the pump still has some life, just a few minutes ago started to pump the annulus system, for now.

Images attached to this comment
gerardo.moreno@LIGO.ORG - 16:55, Thursday 24 July 2025 (85975)VE

(Jordan V., Gerardo M.)

Late entry, activity took place last Tuesday 07/22/2025.

The annulus ion pump signal railed again, so this time we decided to replace the controller.  It does not seem like the controller improved the ion pump behavior, since the current signal is swinging more than before, see attached plot.  We are keeping an eye on this system.

Images attached to this comment
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 16:45, Tuesday 24 June 2025 - last comment - 14:36, Tuesday 15 July 2025(85303)
Filter Cavity Tube Bad Gauge Removal and Replacement-Replacement

(Jordan V., Gerardo M.)

Today we replaced the MKS gauge at FC-C-1, this is the first 6 way cross inside the filter cavity tube enclosure, we installed serial number 390F00490, twice, yes two times.  It turns out that the flange has some scratches on the knife edge, and it was not going to seal regardless of the effort that we put into it.  Once the gauge was removed the scratches transferred to the copper gasket.  We replaced it with serial number 390F00495, this one seems to be doing good.  New conflat was leak tested and no leak was detectable above 2.42e-10 torr*l/sec.

The old gauge serial number is 390F00406 with a date code of June 2021.

Images attached to this report
Comments related to this report
jordan.vanosky@LIGO.ORG - 16:50, Tuesday 24 June 2025 (85305)

Additional pictures of the knife edge damage/dirty flange from manufacturer.

Images attached to this comment
gerardo.moreno@LIGO.ORG - 17:58, Thursday 26 June 2025 (85375)VE

More photos of the MKS390 gauge due to new found features.

We found some features internal to the gauge, see attached photos, maybe when welding the conflat to the gauge body they did not use shielding gas internal to the gauge.

Future reference, we did a test on the gauge with an annealed copper gasket, no leaks detected above the 1.0e-10 torr*l/sec.  So, if this gauge is deemed good we can use it, contacting vendor with lots of questions.  Serial number 390F00495 is for the featured gauge on attached photos.

Images attached to this comment
gerardo.moreno@LIGO.ORG - 14:36, Tuesday 15 July 2025 (85778)VE

For clarification the serial number of the "dirty" gauge is 390F00490 and it is getting returned to the vendor.

The gauge installed and working on FC-C-1 is serial number 390F00495.

H1 ISC
elenna.capote@LIGO.ORG - posted 13:18, Monday 23 June 2025 - last comment - 16:29, Thursday 26 June 2025(85250)
Noise Budget injection inventory

I have been running opportunistic noise budget injections:

So far there seems to be no noise contribution from DC6 P and PRC2 P and Y. CHARD noise contributions are also down significantly with the ISI in place.

 

Comments related to this report
elenna.capote@LIGO.ORG - 16:48, Wednesday 25 June 2025 (85347)

I ran SRCL and MICH injections today as a part of determining if the feedforward is performing well, but I repurposed those injection times in the noise budget templates so now SRCL and MICH are complete as well.

elenna.capote@LIGO.ORG - 16:29, Thursday 26 June 2025 (85372)

After running some PRCL injections to test the feedforward I was also able to update the PRCL noise budget template.

I also reran the jitter noise coupling measurement, since it seemed like the coupling was overestimated at low frequency. The jitter noise had been run very early on in vent recovery, so I am not sure what changed to affect the low frequency coupling (could be the pumps, LSC feedforward, ASC, etc) but now the low frequency coupling is very reduced.

Displaying reports 601-620 of 83536.Go to page Start 27 28 29 30 31 32 33 34 35 End