Displaying reports 1361-1380 of 83163.Go to page Start 65 66 67 68 69 70 71 72 73 End
Reports until 13:16, Thursday 01 May 2025
H1 ISC (VE)
camilla.compton@LIGO.ORG - posted 13:16, Thursday 01 May 2025 (84225)
HAM1 Periscope Placed, POP/ALS path septum window cover removed

Jennie, Jordan, Camilla 

We covered the REFL septum widow with the cover to protect it and then placed the HAM1 periscope on the table. Then removed the septum covers so that now that REFL, PSL and POP/ALS septum windows are uncovered and we can get beams though. Photo attached. 

Images attached to this report
H1 ISC
daniel.sigg@LIGO.ORG - posted 12:04, Thursday 01 May 2025 - last comment - 16:41, Thursday 01 May 2025(84224)
Testing photodetectors in HAM1

I was using the RF test input to test the response of the photodetectors in HAM1.

LSC-POP_A, LSC-REFL_A, LSC-REFL_B are working as expected after swapping the cables at the patch panel for Test-Out and RF1.

ASC-REFL_A was working as expected.

ASC-REFL_B showed no response.

ASC_POP_X looks like the RF cables may be switched.

Comments related to this report
daniel.sigg@LIGO.ORG - 15:13, Thursday 01 May 2025 (84226)

Swapped the coax cables on POP-X and it is working as expected now.

We did flash light tests on all detectors and were able to observe DC shifts on all detectors. LSC REFL_A and POP_A were swapped. This is a wiring diagram error and the in-air d-subs were swapped at the vacuum feedthrough.

daniel.sigg@LIGO.ORG - 16:41, Thursday 01 May 2025 (84229)

We measured the current draw of ASC REFL_A and REFL_B, they are very similar to each other and close to the values measured in the test procedure.

Still no RF transfer functions for REFL_B.

LHO VE
david.barker@LIGO.ORG - posted 10:44, Thursday 01 May 2025 (84222)
Thu CP1 Fill

Thu May 01 10:14:06 2025 INFO: Fill completed in 14min 2secs

Jordan confimed a good fill curbside.

Images attached to this report
LHO VE
jordan.vanosky@LIGO.ORG - posted 09:24, Thursday 01 May 2025 (84220)
Morning Purge Air Checks 5-1-25 & Pump Checks

Morning dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 , approx. -42C

 

The turbo on the YBM tripped as a result of the power glitch reported last night see alog 84217, leading to a slight pressure rise in the corner.

I closed the main gate valve at that turbo and restarted the scroll pump/backing turbo and main turbo. Once the turbo reached full speed and the intake pressure was lower than the main volume pressure I verified trip setpoints and re-opened the gate valve..

This was the only turbo station that tripped. Output tube/XBM & HAM6 turbos were all nominal.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 08:48, Thursday 01 May 2025 (84217)
Power glitch 2:39:31 Wed 30th April 2025 PDT

Another site power glitch, caught by GC OSB UPS but not CDS MSR UPS. Seen by CS MAINSMON.

My house lights flickered around this time.

UPS email:

Date : 04/30/2025
Time : 21:39:31
Code : 0x0109

Warning - UPS: On battery power in response to an input power problem.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 08:07, Thursday 01 May 2025 (84216)
DAQ FW2 added to DAQSTAT, its status now viewable on CDS Overview MEDM

Jonathan, Dave:

I have added the new third framewriter (FW2) to DAQSTAT.

H1:DAQ-FW2_STATUS is now viewable in the DAQ section of the CDS Overview (see attached).

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 07:32, Thursday 01 May 2025 - last comment - 08:57, Thursday 01 May 2025(84215)
OPS Thursday day shift start

TITLE: 05/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 4mph Gusts, 3mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Vent work today includes:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:57, Thursday 01 May 2025 (84218)

Dust monitor 5 could use a power cycle, same with the diode rooms dust monitor. The counts are stuck, I restarted the diode room dust monitor.

H1 ISC
camilla.compton@LIGO.ORG - posted 17:19, Wednesday 30 April 2025 - last comment - 14:38, Monday 02 June 2025(84193)
ISC Alignment Work, Day 1 in HAM1: Majority of REFL Path optics aligned.

Keita, Elenna, Oli, Rahul, Camilla

Summary: Majority of REFL path optics are aligned. Need to beam profile and finish LSC and ASC REFL diode placement on this path and place/check all beam dumps.

This morning, Keita opened the light pipe, locked the IMC  but couldn't see the beam as nicely as he did on AS_AIR yesterday. Since that time he had restored PR2 and PR3 to a time we were last locked. He reverted those changes as we could see the beam back at AS_AIR. Checked again IM4 trans QPD was the same as yesterday.

Additionally M16 was placed roughly in the correct position, all optics are now on HAM1 (apart from PM1) and the class-B pans are empty and packed up.

Left IMC locked.

Comments related to this report
oli.patane@LIGO.ORG - 18:00, Wednesday 30 April 2025 (84213)EPO

Attaching a bunch of photos of the current alignment:

(I don't have the names of the optics on the SLED so I'm calling them by the order that the beam goes through them)

- Alignment from RM2 onto M5 (attachment1, attachment2)

- Coming from M5, through M6, and onto first lens on SLED (attachment3)

- Coming through first SLED lens onto second SLED lens (attachment4)

- Through SLED lenses and onto first steering mirror (attachment5, attachment6)

- Alignment onto SLED pico mirror (attachment7)

- Top view of pico showing that there is available range in both pitch and yaw (attachment8)

- Distance between L1 and front of LSC REFL A (L1 focal length is 222mm) (attachment9, attachment10)

- Distance from LSC REFL A to M18 (attachment11)

- Distance from LSC REFL B to M18 - needs to be moved closer (attachment12)

 

Images attached to this comment
keita.kawabe@LIGO.ORG - 10:02, Thursday 01 May 2025 (84221)

About REFL WFS sled:

  • When the beam was centered by eyeballing on both the 2" lens and the 1" lens, the beam missed the last steering mirror (circled in red) but all other mirrors were without clipping.
  • When the beam was centered on the 2" lens but was off-centered by about 1 mm in +Y direction on the 1" lens (again eye balling), no clipping anywhere but the beam was still closer to the edge of the last steering mirror than I liked.
  • We used the 2nd corner mirror (circled in blue) to steer the beam back to the center of the last steering mirror.
  • Moved the steering mirrors for the WFS heads to place beam dumps at convenient locations.
Images attached to this comment
corey.gray@LIGO.ORG - 14:38, Monday 02 June 2025 (84722)EPO

Tagging for EPO

H1 General
ryan.crouch@LIGO.ORG - posted 16:30, Wednesday 30 April 2025 (84192)
OPS Wednesday DAY shift summary

TITLE: 04/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: The vent work continues...
LOG:                                                                                                                                                                                                                                                           

Start Time System Name Location Lazer_Haz Task Time End
14:51 FAC Kim & Nellie LVEA Y Tech clean 15:54
15:21 ISC Camilla LVEA Y Put up/prep hazard signs 15:54
15:38 VAC Jordan LVEA Y Purge air checks 15:56
15:45 ISC Keita LVEA Y Open PSL light pipe 15:49
15:54 FAC Kim MidX N Tech clean 17:00
15:54 VAC Travis MidX, EndX N Turbo monthly checks 18:48
15:54 FAC Nellie MidY N Tech clean 16:58
16:11 FAC Jim, Mitch, Randy EndY N Wind Fence work 22:12
16:34 ISC Camilla, Keita, Elenna LVEA Y HAM1 alignment work, Elenna out 1800UTC 19:31
16:59 VAC Jordan MidY N CP3 pump check 17:17
17:01 FAC Kim FCES N Tech clean 17:38
17:27 SAF Richard LVEA Y Safety checks 17:44
17:48 ISC Oli LVEA Y Join HAM1 alignment crew 19:32
18:28 VAC Janos LVEA N VAC checks 19:09
18:49 FIT Ibrahim Yarm N Walking 19:42
20:32 CAL Tony PCAL lab LOCAL Switch spheres 21:47
20:35 ISC Camilla, Keita LVEA Y HAM1 alignment Ongoing
20:38 ISC Oli LVEA Y HAM1 work Ongoing
21:49 VAC Gerardo, Jordan LVEA Y HAM6 gauge power cycle 21:56
22:31 VAC Gerardo, Jordan LVEA Y Trace a cable for a HAM6 gauge 22:56
22:37 CAL Tony PCAL Lab LOCAL Sphere swap, measurement 23:11
22:56 VAC Jordan MidY N CP3 pump check 23:29
22:55 OPS TJ Garb room N Grab something 22:57

RM troubleshooting alog84204

EY wind fence continues

HAM1 alignment continues

Vacuum gauge work by HAM6

H1 ISC (ISC)
raed.diab@LIGO.ORG - posted 16:14, Wednesday 30 April 2025 (84210)
Follow up on the DARM sensing function simulation


Following the work from yesterday post, 2 questions came up immediately. One, how much does the sensing function change with input power? We can plot it as a function of arms circulating power instead. Second, if the detuning is the same, but at different mode mismatches, do we get the same sensing function?

We can see the answer to the first question in this plot. These sensing functions are normalized to 100 Hz value. The ratio between the highest power and the lowest power sensing functions is plotted (dashed line) as well.  

 

Before answering the second question, let’s look at the following scenario. 

We lock the interferometer, get SRCL.DC to be -90.4643, then we change that detuning while locking. What happens to the PDH signal and the sensing function now?

 

Here I plotted the error signals as I change SRCL.DC detuning by ± 0.5 deg 

 

 

And the DARM sensing at different detuning looks like this 

 

 

So, we see that the sensing function significantly changes with detuning at a constant mismatch. 

 

So, from here, let’s answer the 2nd question. What we will do is to change the mismatch then manually offset the detuning to be the same in both cases. 

 

For that I look at 2 cases. The first case is the default case where there is a mismatch between SRC and ARM cavities with SRCL.DC = -90.4643 and I plot the sensing function. Now, when I change the radii of curvature of ITMX and ITMY - I get almost a perfect mode matching - SRCL.DC becomes ~ -90.004. Again, the question is, if I add an offset to make SRCL.DC = -90.4643, would I get the same sensing function as the first case, where SRCL.DC is -90.4643 due to the mismatch.


 

The answer turns out to be not entirely, but also it depends on the power as well. 

So, I looked at 2 cases, the first with input power of 1W, in which both sensing functions are very similar to each other in behaviour (not magnitude). The normalized plot shows that, in addition it shows the ratio between both of them.  This is shown in here

 

 

The 2nd case is with an input power of 60W. In this case, they are not as similar to each other anymore, though not so different either. 

This is shown in here

 

To conclude the 2nd question: the sensing function is almost the same (depending on the power) at the same detuning regardless of the mismatch (in the low mismatch limit < 2%)


 

Images attached to this report
Non-image files attached to this report
H1 SUS
ryan.crouch@LIGO.ORG - posted 15:51, Wednesday 30 April 2025 (84207)
BS Oplev damping output turned off

Jim, RyanC

We noticed that the oplev damping values seemed pretty large, so we turned off the output for the OLDAMP. The noise increase started the morning of the 1st which makes sense as it's when the vent started.

Images attached to this report
H1 AOS
patrick.thomas@LIGO.ORG - posted 15:34, Wednesday 30 April 2025 - last comment - 17:10, Wednesday 30 April 2025(84208)
Restarted h0vaclx TwinCAT system, updated high voltage trip points
WP 12505.

Patrick, Gerardo

I tried various restarts of the Beckhoff PLC on h0vaclx, but none of them changed the error on the PT110 gauge. I did notice an additional diagnosis of the error, which is that the status of the EtherCAT ports is abnormal, which I think is an indication that something is not right with the connection of the gauge to the h0vaclx EtherCAT network. Gerardo went out to reseat the cable and look for anything odd about it.

I went through and checked the relay trip point levels for each of the gauges on h0vaclx. I found PT110, PT180 and PT170 set to 1E-5 and changed them to 5E-5. PT132 was already at 5E-5. The other gauges do not have the trip points enabled.

PT110 1E-5 -> 5E-5
PT140 not enabled
PT180 1E-5 -> 5E-5
PT170 1E-5 -> 5E-5
PT132 5E-5
PT193 not enabled
PT192 not enabled
PT191 not enabled
Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 15:53, Wednesday 30 April 2025 (84209)

I used the vacuum SDF safe.snap file to restore CP2's PID settings. To speed this up in the future I wrote a script to do this, the script should be ran on a machine with write access to the vacuum controls IOCs.

/ligo/home/vacuum/burt_restore_h0vaclx.bsh

cp /opt/rtcds/userapps/release/cds/h1/burtfiles/h1vacuumsdf/h1vacuumsdf_safe.snap /tmp/h1vacuumsdf_safe.snap
cat /tmp/h1vacuumsdf_safe.snap|grep "^H0:VAC-LX_"|awk '{print "caput ",$1,$3}' > /tmp/h0vaclx

while read -r i;do
${i}
done < /tmp/h0vaclx

 

gerardo.moreno@LIGO.ORG - 16:41, Wednesday 30 April 2025 (84211)VE

Error is fixed, all we had to do was connect the Ethernet cable to correct port, yes somehow I managed to connect it on the wrong port, but the odd part is that we had a valid pressure signal, except for the error noted by Patrick.

patrick.thomas@LIGO.ORG - 17:10, Wednesday 30 April 2025 (84212)
For future reference, specifically, the correct port (in vs. out) on the gauge itself.
H1 CAL (CAL)
joseph.betzwieser@LIGO.ORG - posted 18:33, Tuesday 29 April 2025 - last comment - 15:45, Wednesday 28 May 2025(84181)
O4b uncertainty budget correction TF
Calibration is currently regenerating the O4b uncertainty budgets.

Due to a missed change to the ETMX UIM suspension filters, which was found in LHO alog 82804, and then fixed only on Feb 27, 2025 (see LHO alog 83088), we need to add a correction TF to be included in the uncertainty budgets.

I attach a graph of that correction TF (corrected model / original model) and the text file needed for that correction.

We will be using correction TF in all our uncertainty budgets for O4b, and up to Feb 27, 2025 around 20:00 UTC, or GPS 1424721618 for O4c.
Images attached to this report
Non-image files attached to this report
Comments related to this report
ling.sun@LIGO.ORG - 22:05, Wednesday 30 April 2025 (84214)

Since after the July-Aug break, the low frequency response got closer to unity due to other mixed effects, we only apply the TF correction in uncertainty calculation before the break: 

From 1396796418 = Wed Apr 10 15:00:00 UTC 2024 to 1404864018 = Sat Jul 13 00:00:00 UTC 2024

After the break, we leave it to GPflow to take care of the unmodeled residual using monitoring data.

ling.sun@LIGO.ORG - 15:45, Wednesday 28 May 2025 (84641)

Although the low-frequency response got closer to unity at later times, we found that GPflow still could not sufficiently capture the unmodeled residual.

We now determine that the above TF correction should be applied thoughout O4b at LHO.

H1 SUS (SEI, SUS)
edgard.bonilla@LIGO.ORG - posted 12:02, Tuesday 29 April 2025 - last comment - 14:56, Monday 05 May 2025(84171)
SR3 OSEM estimator update

Edgard, Oli.

Follow up to the work summarized in 84012 and 84041.

TL;DR: Oli tested the estimator on Friday and found the ISI state affects the stability of the scheme, plus a gain error in my fits from 84041. The two issues were corrected and the intended estimator drives look normal (promising, even) now. The official test will happen later, depending on HAM1 suspension work.

____

Oli tested the OSEM estimator damping on SR3 on Friday and immediately found two issues to debug:

1) [See first attachment] The ISI state for the first test that Oli ran was DAMPED. Since the estimator was created with the ISI in ISOLATED (and it is intended to be used in that state), the system went unstable. This issue is exacerbated by point 2) below. This means that we need to properly manage the interaction of the estimator with guardian and any watchdogs to ensure the estimator is never engaged if the ISI trips.

2) [See second attachment] There was a miscalibration of the fits I originally imported to the front-end. This resulted in large drives when using the estimator path. In the second figure, there are three conditions for the yaw damping of SR3:
           ( t < -6 min )          OSEM damping with gain of -0.1.
    ( -6 min<  t  < -2 min)   OSEM damping with a gain of -0.5, split between the usual damping path and the estimator path.
     ( -2 min < t < 0 min)     OSEM + Estimator damping.

The top left corner plot shows the observed motion from every path. It can be seen that M1_YAW_DAMP_EST_IN1 (the input to the estimator damping filters) is orders of magnitude larger than M1_DAMP_IN1 (the imput to the regular OSEM damping filters).

The issue was that I fit and exported the transfer functions in SI units, [m/m] for the suspoint to M1, and [m/N] for M1 to M1. I didn't export the calibration factors to convert to [um/nm] and [um/drive_cts], respectively.

____

I fixed this issue on Friday. Updated the files in /sus/trunk/HLTS/Common/FilterDesign/Estimator/  to add a calibration filter module to the two estimator paths (a factor of 0.001 for suspoint to M1, and 1.5404 for M1 to M1). The changes are current as of revision 12288 of the sus svn.

The third attachment shows the intended drives from the estimator and OSEM-only paths. They look similar enough that we believe the miscalibration issue has been resolved. For now we stand by until there is a chance to test the scheme again.

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 13:40, Tuesday 29 April 2025 (84179)

I've finished the set of test measurements for this latest set of filter files (where we now have the calibration filters in)
These tests were done with HAM5 in ISOLATED

Test 1: Baseline; classic damping w/ gain of Y to -0.1(I took this measurement after the other two tests)
start: 04/29/2025 19:22:05 UTC
end: 04/29/2025 20:31:00 UTC

Test 2: Classic damping w/ gain of Y to -0.1, OSEM Damp Y -0.4
start: 04/29/2025 17:16:00 UTC
end: 04/29/2025 18:18:00 UTC

Test 3: Classic damping w/ gain of Y to -0.1, EST Damp Y -0.4
start: 04/29/2025 18:18:05 UTC
end: 04/29/2025 19:22:00 UTC

Now that we have the calibration in, it looks like there is a decrease in the noise seen between damping with the osems vs using the estimator.

In the plot I've attached, the first half shows Test 2 and the second half shows Test 3

Images attached to this comment
edgard.bonilla@LIGO.ORG - 16:21, Tuesday 29 April 2025 (84185)

I analyzed the output of the tests for us to compare.

1) First attachment shows the damping of the Yaw modes as seen by the optical lever in SR3. We can see that the estimator is reducing the motion of the 2 Hz and 3 Hz frequency modes. This is most easily seen by flicking through pages 8-10 of the .pdf attached. The first mode's Q factor is higher than OSEM only damping at -0.5 gain, but it is lower than if we kept a -0.1 gain.

2) The second attachment shows that we get this by adding less noise at higher frequencies. From 5 Hz onwards, we have less drive going to the M1 Yaw actuators, which is a good sign. There is a weird bump around 5 Hz that I cannot explain. It could be an artifact of the complementary filters that I'm not understanding, or it could be an artifact of using a 16Hz channel to observe these transfer functions.

Considering that the fits were made on Friday while the chamber was being evacuated and that the suspension had not thermalized, I think this is a success. The Optical lever is seeing less motion in the 1-5 Hz band consistent with expectations (see, for example some of the error plots in 84004), with the exception of the 1Hz resonance. We expect this error to be mitigated by performing a fit with the suspension thermalized.

Some things of note:

- We could perform an "active" measurement of the estimator's performance by driving the ISI during the next round of measurements. We don't even have to use it in loop, just observe M1_YAW_EST_DAMP_IN1_DQ, and compare it with M1_DAMP_IN1_DQ.
The benefit would be to get a measurement of the 'goodness of fit' that we can use as part of a noise budget.


- We should investigate the 5 Hz 'bump' in the drive. While the total drive does not exceed the value for OSEM-only damping, I want to rule out the presence of any weird poles or zeros that could interact negatively with other loops.

 

Images attached to this comment
Non-image files attached to this comment
edgard.bonilla@LIGO.ORG - 09:42, Thursday 01 May 2025 (84219)SEI, SUS

Attached you can see a comparison between predicted and measured drives for two of the conditions of this test. The theoretical predictions are entirely made using the MATLAB model for the suspension and assume that the OSEM noise is the main contributor to the drive spectrum. Therefore, they are hand-fit to the correct scale, and they might miss effects related to the gain miscalibration of the SR3 OSEMs shown in the fit in 84041 [note that the gain of the ISI to M1 transfer function asymptotes to 0.75 OSEM m/ GS13 m, as opposed to 1 m/m].

In the figure we can see that the theoretical prediction for the OSEM-only damping (with a gain of -0.5) is fairly accurate at predicting the observed drive for this condition. The observed feature at 5 Hz is related to the shape of the controller, which is well captured by our model for the normal M1 damping loops (classic loop).

In the same figure, we can see that the expected estimator drive is similarly well captured (at least in shape) by the theoretical prediction. Unfortunately, we predict the controller-related peaking to be at 4 Hz instead of the observed 5 Hz. Brian and I are wary that it could mean we are sensitive to small changes in the plant. The leading hypothesis right now is that it is related to the phase loss we have in the M1 to M1 transfer function that is not captured by the model.

The next step is to test this hypothesis by using a semi-empirical model instead of a fully theoretical one.

Images attached to this comment
edgard.bonilla@LIGO.ORG - 14:56, Monday 05 May 2025 (84260)SEI, SUS

We were able to explain the drive observed in the tests after accounting for two differences not included in the modelling:

1) The gain of the damping loop loaded into Foton is different from the most recent ones documented in the sus SVN:
sus/trunk/HLTS/Common/FilterDesign/MatFiles/dampingfilters_HLTS_H1SR3_20bitDACs_H1HAM5ISI_nosqrtLever_2022-10-31.mat
They differ by a factor of 28 or so, which does not seem consistent with a calibration error of any sort. But since it is not documented into the .mat files makes it difficult to analyze without ourtright having the filters currently in foton.

2) There was spurious factor of 12.3 on the measured M1 to M1 transfer function due to gains in the SR3_M1_TEST filter bank ( documented in 84259 ). This factor means that our SR3 M1 to M1 fit was wrong by the same factor, the real transfer function is 12 times smaller than the measured one, and in turn, than our fit.

After we account for those two erroneous factors, our expected drive matches the observed drive [see attached figure]. The low frequency discrepancy is entirely because we overestimate the OSEM sensor noise at low frequencies [see G2002065 for an HSTS example of the same thing]. Therefore, we have succeeded at modelling the observed drives, and can move on to trying the estimator for real.

_____

Next steps:
- Recalibrate the SR3 OSEMs (remembering to compensate the gain of the M1_DAMP and the estimator damping loops)
- Remeasure the ISI and M1 Yaw to M1 Yaw transfer functions
- Fit and try the estimator for real

Images attached to this comment
Displaying reports 1361-1380 of 83163.Go to page Start 65 66 67 68 69 70 71 72 73 End