Displaying reports 11261-11280 of 84712.Go to page Start 560 561 562 563 564 565 566 567 568 End
Reports until 17:23, Wednesday 31 January 2024
LHO VE (VE)
travis.sadecki@LIGO.ORG - posted 17:23, Wednesday 31 January 2024 - last comment - 19:04, Wednesday 31 January 2024(75655)
1-31 vent vacuum diary

Today activities:

-EX pumpdown continues.  Roughing via Hepta pump was restarted this morning, and by ~14:30 PT pumping was transitioned to the turbo station (initially backed by the Hepta then swapped to scroll pump backing once the inlet pressure was in the e^-2 Torr range).

-Quantity 2 of the 3IFO 12" CF-to-triple-4.5" CF reducer/feedthrough assemblies were removed from the north side of BSC8. These were replaced with 12" CF blanks.  

Comments related to this report
jordan.vanosky@LIGO.ORG - 17:40, Wednesday 31 January 2024 (75656)

Todays purge air dew point measurement, -43.9degC

Images attached to this comment
travis.sadecki@LIGO.ORG - 19:04, Wednesday 31 January 2024 (75658)

CF assemblies removed from BSC8 north side.  

Images attached to this comment
H1 AOS (AOS, ISC)
keita.kawabe@LIGO.ORG - posted 17:05, Wednesday 31 January 2024 - last comment - 14:05, Thursday 01 February 2024(75651)
Quiet HAM6 day (Rahul, Betsy, Keita)

We put the OMCS baffles back on except the -Y side vertical panel, which had a non-standard screw/washer/O-ring configuration. It turns out that that was done intentionally back in Aug/2016 because otherwise the OMC trans beam won't come out of the shroud hole (alog 28944).

The shroud panels had finger marks from gloves as well as spots that look like dust particulates (1st attachment). We wiped using IPA and wipes, which reduced the finger marks (2nd attachment). Though they look much better in the picture, in reality we might have been just spreading it over the larger surface. Some spots didn't move at all. Anyway, we cleaned the panels using ionized nitrogen gun (for particulates) immediately followed by alcohol-wipe.

There was one particularly bad spot, see Betsy's picture.

3rd and 4th pictures show Rahul and Betsy working on a small horizontal top panel. 5th picture shows the OMC surrounded by the shroud panels.

After attaching the shroud panels (except for the -Y side vertical one), we found that one of the white DCPD cables interfered with the top glass panel, so Betsy pulled the cable up higher in the cable retainer attached to the suspension cage. PZT cable was really close to the other DCPD cable, but the PZT cable doesn't have a retainer, so I bent that cable to form a large arc to avoid interference. On -X side, Rahul found that one of the QPD cables is very close to a BOSEM cable, so he worked on that.

These resulted in some change in the OMCS alignment, and top osem numbers shifted according to Rahul. My hope is that this is benign enough we can take care of that using mostly OM2 and OMC.

Rahul measured the TF for OMCS and they're OK.

Tomorrow we'll attach the remaining panel, recenter BOSEMs for OMC and OM2,  and I'll start the electronics check.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 20:17, Wednesday 31 January 2024 (75659)

A couple PR photos, and the one of the panel with the particularly offensive mark - note the residue around it as if there was a previous attempt to remove it. It did not move for me either, my guess is it's actually a little divot. Will install it as is.

Images attached to this comment
corey.gray@LIGO.ORG - 09:14, Thursday 01 February 2024 (75664)EPO

Tagging EPO for Output Mode Cleaner photos.

rahul.kumar@LIGO.ORG - 14:05, Thursday 01 February 2024 (75678)SUS

This morning I re-adjusted the BOSEMs on OM2 (all four of them) and OMCS (T1 and T3).

Also, I attached the one remaining side baffles.

I will take TF measurements and check the health of both the suspensions.

H1 PEM (ISC, PEM)
marc.pirello@LIGO.ORG - posted 16:53, Wednesday 31 January 2024 (75650)
LIGO Accelerometer Chassis chassis installed at EX, MX

Continued from ALOG75592 

Installed EX S2300070 - 9 channel Accelerometer Chassis

Installed MX S2300060 - 4 channel Accelerometer Chassis

Installed EY S2300073 - 9 channel Accelerometer Chassis

Installed MY S2300076 - 4 channel Accelerometer Chassis

Notes on install, MX was not completed due to power incompatibility, we need an adapter cable for this, same as MY.

Final cable arrangement listed below, many of the signals do not match the drawing D1300773, the following is as they were installed:

Front Cable - Accel Channel - Back Cable

Cable 7 - CH1 - OPLEV_ACC_Y

Cable 8 - CH2 - BSC10_ACC_Y (should be BSC10_ACC_X)

Cable 9 - CH3 - TRN_TBL_ ACC_Y (should be BSC10_ACC_Y)

Cable 10 - CH4 - BSC10_ACC_Z

Cable 11 - CH5 - BSC10_ACC_X (should be TRN_TBL_ACC_Y)

Cable 12 - Black cable to ??, magnetometer.  CH6 is empty on front, back is BSC6_FL_ACC_Z

Cable 13 - CH7 - EBAY ACC_Z

(TBI) - CH8 - 

(TBI) - CH9 - 

To fix this to match the DCC Drawing, CH2 moves to CH3, CH3 moves to CH5, CH5 moves to CH2.

J. Jimerson, M. Pirello

H1 AOS
david.barker@LIGO.ORG - posted 16:30, Wednesday 31 January 2024 - last comment - 09:50, Thursday 01 February 2024(75649)
LVEA Dust Monitor temperature channels are bad, dust particle measurements are good.

Following the DAQ+EDC restart yesterday, Tue 30 Jan 2024, the LVEA Dust monitor temperature channels have flatlined at 25F. This has been see before late last year in exactly the same curcumstances, see alog:

28nov2023_alog

The actual dust particle measurements continue to be good, only the temperatures are broken.

In the 2023 case, just under 3 days later at 03:39 Fri 01 Dec 2024 the temperature channels sponteneously fixed themselves and came back to life.

If the temps are still stuck tomorrow morning we will try a restart of the DUST LVEA IOC.

Comments related to this report
david.barker@LIGO.ORG - 09:50, Thursday 01 February 2024 (75668)

I restarted the h1dustlvea IOC on h0epics this morning at 08:40, this has not fixed the issue.

This time the EDC connected to the values seen on the MEDM, previously they were all at 25F. 

All the dust monitors show reasonable temps except PSL101 which came up with 25F and is staying there.

The core problem persists: CA clients which establish callbacks (MEDM, EDC) are stuck with the value they got at connection. Running caget every second most of the time returns a steady value, with an occassional 25F or VAL+n returned.

We have situations wherein the EDC has one value, the MEDM has another and caget has a third.

In this example I am running "caget H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF" every second:

H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 25 *
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 70 *
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
 

LHO General
austin.jennings@LIGO.ORG - posted 16:00, Wednesday 31 January 2024 (75641)
Wednesday Shift Summary

TITLE: 01/31 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

HAM 3 baffle work continues. HAM 7 work slated for tomorrow. Team TCS is still currently in the LVEA.

LVEA is laser safe.
LOG:                                                                                                                                                                                                                                                                                                                                                                                                       

Start Time System Name Location Lazer_Haz Task Time End
16:00 fac karen.kim lvea n technical cleaning (Karen out @ 17:18) 17:50
16:33 VAC Jordan LVEA N Purge air measurement 16:42
16:35 TCS Camilla/TJ LVEA N TCS table work and leak checks (Jason in @ 17:51) 18:34
16:42 ISC Robert/Mitch/Tony/Corey HAM 3 N Baffle installation 19:18
16:52 VAC Jordan EX N Pump down (Travis in @ 17:37) ??
17:32 EPO Preet/Vicky HAM 3 N HAM 3 views 18:05
17:54 SUS Keita/Rahul/Betsy HAM 6 N OMC work 19:59
18:14 FAC Chris EY N Wind fence prep work ??
18:52 TCS TJ/Camilla/Jason LVEA N TCS water line leak checks and table work 20:03
19:03 VAC Travis LVEA N Conflats work 19:43
19:24 FAC Karen Wood shop/fire pump N Tech clean ??
20:59 ISC Mitch/Robert/Tony/Corey HAM 3 N Baffle installment (Tony/Corey out @ 23:27) 23:40
21:08 VAC Jordan EX N Pump down 23:29
21:14 VAC Travis LVEA N Feedthru and conflats work ??
21:25 TCS Camilla/TJ/Jason LVEA N TCS work (Camilla out @ 23:44) ??
21:47 EE Marc/Jabari EX/MX/EY/MY N Install accelerometers 23:38
H1 ISC
sheila.dwyer@LIGO.ORG - posted 15:22, Wednesday 31 January 2024 - last comment - 14:12, Friday 02 February 2024(75584)
matlab model of DARM loop for comparison to pyDARM

While Louis and I were working on the DARM loop transitions, we revived an old matlab model I had of the DARM loop, in parallel with Louis using pyDARM to produce plots of the loop cross overs.   This imports filters from CALCS for the sensing and actuation functions, and the suspension filters, and makes some plots of the loop.  For some history about this effort to change the DARM loop, see 74790, and for similar plots made using the pyDARM model of the DARM loop, see 74771.

Here are some plots produced by this model for reference.  The first two attachments show the DARM configuration used in O4a and the proposed configuration (New DARM) tested in 74887 (which has different UIM filters than the configuration documented in 747790) Both of these show a DARM OLG measurement with black x's.  In both cases there is a discrepancy between the model and the measurement, especially visible in the phase around 200Hz. Louis exported a model of the sensing function from pyDARM which we tried substituting for the CALCS sensing function model shown in these plots, this actually made the phase discrepancy worse.  I was able to match the measurement better by adding a delay of 250microseconds to the sensing function, but this is not shown in the plots here.  This discrepancy doesn't cause me too much concern: the model seems accurate enough to evaluate the loop stability, and the pyDARM model which is used for calibration does reproduce this OLG accurately.  By flipping between these two plots, you can see that the NEW_DARM configuration has more low frequency gain (which probably isn't needed), more gain in the PUM around a few Hz (which was our goal, to reduce RMS drive on the ESD), and also a better roll off of the UIM so that the UIM gain is not visible on the plot around 150 Hz.  This feature of our current DARM loop has been a complication for calibration, so we are happy about this change.

The third plot shows the model and measurements of the crossovers. To see Louis's write up of how we are evaluting the stability of cross overs see T2300436. In particular, we are refering to the measurement L2_LOCK_L_IN1/L2_LOCK_L_IN1 as G_pum, and the measurement L1_LOCK_L_IN1/L1_LOCK_L_IN2 as G_uim.  To have a stable crossover we need G_pum and G_uim to not be +1.  We made a measurement of G_pum in the new configuration, which matches this model well.  (It didn't match well in 74771)  We had difficulty making this L2 LOCK measurement in the old DARM configuration, as discussed in 74226.  The plot also shows a measurement made at L1 lock in the O4 configuration, we never took this measurement in the new configuration.  While there are some discrepancies with the UIM measurement, these both agree well enough to confirm that the model is fairly correct.

The next two plots show comparisons of the new and old DARM loops, first the OLGs then the distrubution to actuators .  The new loop leaves the PUM/ESD crossover just below 20Hz where it has been, but has a steeper offloading with less phase margin for the PUM. 

We also plotted and looked at the closed loop response to distubances, for the over all loop and for disturbances at the injection points L2 LOCK (1/(1-G_pum)) and at L1 LOCK (1/(1-G_uim)) to look for gain peaking.  This does indicate that the new model has very slightly more gain peaking for the PUM crossover around the frequencies where we are having trouble (2.5-3.5Hz) than the old loop.

This model is in sheila.dwyer/LSC/DARM/DARM_model/DARM_loop_model_Dec2023.m  and attached here. 

 

Non-image files attached to this report
Comments related to this report
louis.dartez@LIGO.ORG - 14:12, Friday 02 February 2024 (75712)
Minor correction: G_pum is L2_LOCK_L_IN1/L2_LOCK_L_IN2.
H1 CAL
dana.jones@LIGO.ORG - posted 14:08, Wednesday 31 January 2024 (75642)
Should we be excluding the time delay term in the sensing function model?

Dana, Louis

The sensing function model that is currently being used has five free parameters that we can fit for: the optical gain H_c, the coupled cavity pole frequency f_cc, the optical spring frequency f_s, the quality factor of the optical spring Q_s, and the residual time delay τ_C. However, all of the sensing function models generated to fit measured data in O4 so far have excluded the time delay term. It is unclear why this is the case/when this choice was made, so we decided to explore whether or not this term should be excluded; i.e., does excluding the time delay term cause the model to fit the data better?

Our results are summarized in the attached plots, showing the sensing function model with and without the time delay term, the measured data they were fit to, and the residuals for two sample measurements taken during O4a. The sensing function report numbers are shown in the legend, along with the fit parameters generated as part of these reports (see /ligo/groups/cal/H1/reports/) written in brackets, i.e., [H_c, f_cc, f_s, Q_s, τ_C]. The difference the time delay makes in the model is more obvious in figure 2, where τ_C is almost an order of magnitude larger than that of figure 1. Looking at the residual plots on the right, the blue markers are the measured data divided by the model with the time delay, and the orange markers are the measured data divided by the model without the time delay. Comparing these two sets of residuals, it is not immedialy obvious which one is the better fit, although perhaps the blue markers (time delay included) do fit the data slightly better. Regardless, it is clear that the choice of whether or not to include this time delay term is something that should be given more thought, and indeed it seems to fit certain measurements better than others (e.g., the model that includes the time delay seems to be a slightly worse fit compared to the model without the time delay in figure 1).

Additionally, one might think that if excluding the time delay is truly the best fit, then the MCMC which generated the fit parameters for the models shown in the two figures would simply return 0 for τ_C. However, this is not what has happened. Deeper investigation is needed to figure out why.

Images attached to this report
LHO FMCS
eric.otterman@LIGO.ORG - posted 12:10, Wednesday 31 January 2024 (75646)
OSB AHU airflow increase
The supply flow setpoint for AHU 3 was increased from 14,500 CFM to 15,000 CFM. This is due to inconsistent heat output from the AHU. The heating coil air-proving switch is factory set at ~.5 inches of water column, and the PI loop of the AHU controller oscillates the flow ~ 1000 CFM. At the lower end of air flow, this is not high enough to keep the proving switch closed and the heaters de-energize until the flow increases again, leading to ON/OFF operation and inconsistent heating. Increasing the flow rate allows the flow switch to remained closed at the lower end of oscillation.  
LHO General
austin.jennings@LIGO.ORG - posted 11:58, Wednesday 31 January 2024 (75645)
Mid Shift Report

Baffle installation team is currently out for lunch, and has been making great progess. OMC work in HAM 6 and TCS table and leak checks are currently ongoing in the LVEA.

LHO VE
david.barker@LIGO.ORG - posted 10:37, Wednesday 31 January 2024 (75644)
Wed CP1 Fill

Wed Jan 31 10:11:43 2024 INFO: Fill completed in 11min 39secs

Images attached to this report
H1 SYS (SYS, VE)
keita.kawabe@LIGO.ORG - posted 10:12, Wednesday 31 January 2024 - last comment - 16:25, Wednesday 31 January 2024(75643)
Dust counter on a stand by ham5 is not working

Could somebody have a look? Pressing buttons won't change the screen.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 16:25, Wednesday 31 January 2024 (75648)

TJ asked me to power cycle the unit. I turned it off, waited for 5 sec, turned it on, and it's back.

Images attached to this comment
LHO General
austin.jennings@LIGO.ORG - posted 08:17, Wednesday 31 January 2024 (75640)
Ops Day Shift Start

TITLE: 01/31 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.62 μm/s
QUICK SUMMARY:

- HAM 3 baffle work continues

- TCS work will continue today

- HAM 7 work slated for sometime this week or the beginning of next

LHO VE
janos.csizmazia@LIGO.ORG - posted 19:15, Tuesday 30 January 2024 - last comment - 21:04, Tuesday 30 January 2024(75638)
1-30 vent vacuum diary
Today's activities:
- HAM3 Y+ door has been removed
- The pumpdown at EX has been started, with the Hepta. In the end of the day, the pressure is in the low E+0s - a.k.a. a few Torrs; so transitioning to Turbo tomorrow. The purge air won't be switched off until the leak tests
- In parallel with the HAM3 door removal, the purge air was hooked up to the X-manifold as well (now it is purging at the input beam; at the x-manifold; and at HAM7)
- BSC8 AIP railed - possibly there is a leak between the main volume and the annulus volume, will be further investigated. Will be taken care of tomorrow
Comments related to this report
jordan.vanosky@LIGO.ORG - 21:04, Tuesday 30 January 2024 (75639)

Today's dew point measurement at the OMC tube, prior to in-chamber activites, -45.8degC

Images attached to this comment
H1 AOS
robert.schofield@LIGO.ORG - posted 16:53, Tuesday 30 January 2024 - last comment - 09:16, Thursday 01 February 2024(75637)
MC Baffle by HAM2 successfully angled to ten degrees

Robert, Mitchell, Corey, Tony, TJ, Alena, Eddie, Betsy, the SLiC team.

The baffle by HAM2  can, at 5 degrees, specularly reflect some scattered light back to beam spots and has been shown to produce scattering noise (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=74772). Today we changed the angle of the baffle to 10 degrees using new hardware designed at CIT. The new hardware and the procedure worked well. The figure shows photos of the work.

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 20:21, Wednesday 31 January 2024 (75660)

Here's TJ in HAM3 locking the ISI via only 1 open door and squeezing through around either side of the table.

Also a door crew snapshot.

Images attached to this comment
corey.gray@LIGO.ORG - 09:16, Thursday 01 February 2024 (75665)EPO

Tagging EPO for Stray Light Baffle & Door Removal photos.

H1 ISC (ISC, SUS)
keita.kawabe@LIGO.ORG - posted 21:34, Monday 29 January 2024 - last comment - 09:10, Tuesday 13 February 2024(75601)
HAM6 work Jan/29/2024: Alignment of the laser into the new OMC, day 4 (Camilla, Vicky, Julian, Rahul, Sheila, Betsy, Keita)

day 1 (alog 75548), day 2 (alog 75557), day 3 (alog 75575)

HAM7 irises were good

Sheila/Camilla checked the iris position on HAM7 and it was good.

ASC-AS_C whitening gain was increased by 18dB, dark offset was reset

I didn't like that the ASC-AS_C input was so small. Increased the whitening gain by 18dB (from nominal 18dB to 36dB) and reset the dark offset.

Recentered the beam on ASC-AS_C. One thing that was strange was that the ASC-AS_C_NSUM would become MUCH bigger (like a factor of 10) when SRM is misaligned. I was worried that I was looking at a ghost beam. Camilla measured the  beam power to be ~1mW out of HAM7 and ~0.7mW into HAM6. When ASC-AS_C was centered, ASC-AS_C_NSUM_OUT became ~0.008 give or take some. Taking the 16dB extra whitening (i.e. a factor of 8) into account, ASC-AS_C_NSUM~0.008 means about 1mW into HAM6, which was in a ballpark, so I convinced myself that the beam on AS_C was good.

HAM6 irises and beam height on OM, the beam was still very low on OM2

At this point OMC QPDs are reasonably centered, so Sheila and Camilla checked the beam position on irises in HAM6.

The beam was OK on the first iris but was a bit low (~2mm) on the iris closer to the OM1.

The beam position on OMs at this point as well as the slider values and max DAC output are listed below (see Camilla's pictures, too). Note that the YAW position in the table is the position of the incoming beam on the mirror measured at some (unknown) distance, it's not on the mirror.  

  OM1 OM2 OM3
Beam height (nominal 4") 1/8" too high 1/4" too low 1/16" too low
YAW position 1/8" to +X 1/32" to -X Cannot measure
PIT slider 430 20 610
YAW slider 600 1300 -231
Max DAC output 11k 7k 9k

The beam was clearing the input and output hole on the shroud, was cleanly hitting the small OMCR steering mirror by the cage, and was already going to the OMCR diode.

They confirmed that the OMC trans video beam was visible on the viewer card when OMC flashes and it was hitting the steering mirror (but we need a viewport simulator to see if the beam will clear the viewport aperture).

Bringing the beam up higher on OM2

Unfortunately the beam was still very low (~1/4"), however I was able to use OM1 alignment slider to bring the beam up on OM2 and use OM2/3 alignment sliders to still center the OMC QPDs. After this was done, OM2 PIT offset became large but OM1/OM3 offsets became low-ish. This was a very good sign as it's infinitely easier to mechanically tilt OM2 than OM1/OM3 due to superior mechanical design.

Anyway, by doing this, the beam height on OM2 went up by about 1/8" (see Rahul's pictures). It's still too low by 1/8", but bringing the beam up more would mean that OM3 DAC output will become large w/o mechanically relieving, which I didn't want to do, so I decided to stay here.

  OM1 OM2 OM3
Beam height 1/8" too high (didn't measure, no reason to suspect that it changed) 1/8" too low 1/16" too low
PIT slider 20 2710 -590
YAW slider 650 660 60
Max DAC output 7.2k 21k 7.1k

Mechanically relieving the OM2 PIT offset

Julian set the OM2 PIT slider gain to 0.75 (from 1), Rahul turned the balance mass screw on the upper mass of OM2 to compensate. We repeated the same thing four times (slider gain 0.75->0.5->0.25->0, each step followed by Rahul's mechanical adjustment). We had to adjust OM2 Y slider in the process to bring the beam back to the center of the OMC QPDs, but overall, this was a really easy process (did I mention that tip-tilt adjustment is not an easy thing to do?).

We ended up with this (we haven't measured the beam height again as OM2 was the only thing that moved, so the height numbers are from the previous table just for convenience).

  OM1 OM2 OM3

Beam height (didn't measure, no reason to suspect that they changed)

1/8" high 1/8" low 1/16" low
PIT slider 20 0 -590
YAW slider 650 760 60
MAX DAC output 7.2k 5k 7.1k

I declared that this is a good place to stay. Rahul fixed the balance mass on OM2 upper mass.

Rahul also fixed the balance mass on OMCS.

Fast shutter path, WFS path, ASAIR path, OMCR path

We closed the fast shutter and the reflected beam goes to the high power beam dump.

We opened the fast shutter and checked the WFS path. The beam was already hitting one quadrant of WFSB but was entirely missing the WSFA. The beam was a bit low on the lens on the WFS sled, so I used two fixed 1" steering mirrors upstream of the WFS sled to move the beam up on the lens and keep the path reasonably level. See Rahul's pictures for the beam height. After this, both WFSs saw the light, and at this point we used pico to center both. We weren't able to see the beam reflected by the WFS but assume that it still hit the black glass.

We tried to see the ASAIR beam but couldn't. Since the beam is hitting the center of ASC-AS_C, we assume that the ASAIR beam will still hit the black glass.

OMCR beam was already hitting the OMCR photodiode, but the beam was REALLY close to the beam dump that's supposed to catch ghost beam. We temporarily moved the dump so the beam is about 5mm from the edge of the glass, but this might be too far. I'll find how close it's supposed to be from the past alog.

Couldn't check if PZT1 is working.

We tried to see if OMC length error signal makes sense when scanning the OMC length, but whenever the OMC is close to resonance there was a huge transient in the DCPD SUM as well as the length signal, probably the intensity noise (due to acoustics or jitter or something) is too much. We'll measure the capacitance of the PZT from outside.

Current status of LVEA

Laser hazard, HAM5 GV is closed, HAM6 and HAM7 curtains are closed.

Remaining tasks

Comments related to this report
camilla.compton@LIGO.ORG - 08:43, Tuesday 30 January 2024 (75614)

Photos attached before the beam height on OM2 was adjusted. In Keita's stage "HAM6 irises and beam height on OM, the beam was still very low on OM2".

Photos of OM1 Pit and OM1 YawOM2 Pit and OM2 Yaw, no photo of OM3. Position of beam on Iris 1, Iris 2 (and the backside of Iris 2). And photos of HAM7 with curtains split for SQZ beam. HAM6 with iris 1.

Images attached to this comment
rahul.kumar@LIGO.ORG - 10:08, Tuesday 30 January 2024 (75615)

Attached below are the pictures showing the beam height on OM2 (pitch and yaw position) and WFS in HAM6 chamber after we made the adjustments.

Also shown is the lens before the WFS, on this the yaw looks OK and is slightly low on pitch but Keita is happy with this.

On a different note:-

OM1, OM3, OMC BOSEM flag position looks fine, OM2 will need some adjustment (once we are laser safe).

The latest slider values for OM1-3 has been attached below.

Images attached to this comment
keita.kawabe@LIGO.ORG - 09:43, Tuesday 30 January 2024 (75616)

The last photo in alog 65101 from Sept. 2022 shows the distance between the OMCR beam dump and the main OMCR beam back then. We will get close to this photo.

https://alog.ligo-wa.caltech.edu/aLOG/uploads/65101_20220923181903_BD_clearance.jpg

julian.gurs@LIGO.ORG - 17:09, Wednesday 31 January 2024 (75653)
Possibly clipping at a beam dump.
In picture "beforemoving" it can be seen how the beam hits the outer left edge of the IR card and this side "touches" the beam dump.
We have moved the beam dump because the beam is centered on the lens.
Images attached to this comment
corey.gray@LIGO.ORG - 09:10, Tuesday 13 February 2024 (75840)EPO

Tagging EPO for alignment of HAM6 work

H1 ISC (ISC, SUS)
keita.kawabe@LIGO.ORG - posted 22:53, Friday 26 January 2024 - last comment - 16:02, Wednesday 31 January 2024(75575)
HAM6 work Jan/26/2024: Alignment of the laser into the new OMC, day 3 (Rahul, Koji, Betsy, Keita)

OMCS was touching.
Rahul made OMCS transfer functions and found that something was touching. He, Koji and Betsy went to the floor to center the OSEMs. T1 was touching, which was fixed. Depth of OSEMs were adjusted, too.

Something is funny about OM3 damping.

Rahul also made TFs for OMs and thought that they were fine. However, OM3 PIT damping was oscillating at 1.75Hz. I flipped the sign of H1:SUS-OM3_M1_DAMP_P_GAIN (nominally -1, now +1) and it damped fine. I hate this.

1st attachment red shows the OLTF of OM3 P damping loop at around the offending resonance. This was of course measured with the flipped damping gain, and the OLTF looks absolutely strange. The 1st UGF is ~1.73Hz with -42deg phase, and the 2nd UGF is ~1.77Hz with -180deg phase.

If you draw a Nyquist diagram, you will find that this is a stable TF. OTOH, with the "correct" damping gain, this will become unstable. So we know why this works and why the correct sign doesn't, but we don't know what changed and why. 

Alignment converges.

With the OMC suspended without any biases, we adjusted OM1/2/3 biases to align the beam into the OMC (i.e. centering both of the OMC QPDs).

At some point we found that the ASC-AS_C was totally off-centered, used SRM to recenter, and continued the alignment.

2nd attachment shows the status as of now. Both of the OMC QPDs are reasonably centered, ASC-AS_C too. BOSEM DAC output for OM1 is ~11k max. OM2 and OM3 are at ~7k max  and ~9k max, respectively. These are OK though OM1 is not super.

Current status of the LVEA etc.

It's laser hazard. SQZ manager was set to DOWN. Koji closed small HAM5 GV and HAM7 -X curtain.

Remaining work (Monday).

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 16:02, Wednesday 31 January 2024 (75647)ISC, SUS

OM3 damping mystery solved, everything back to normal.

The sign of the OM3 P damping gain got back to the nominal -1 (negative 1) after yesterday's boot fest (alog 75627) and OM3 was happily damping everything.

Turns out that the problem was a rogue filter in all of OM3 M1 COILOUTF channels, stealing about 7dB and ~61deg at 1Hz, 12dB and ~73deg at 2Hz, which was fixed after booting things.

In the attached ndscope screen, at 2024/Jan/26 17:25:11 UTC, OM3 M1 BIO status request was changed from 2 (nominal, hardware LPF ON) to 1 (cannot be used for OMs as hardware LPF seems to be always ON). I don't know how this happened.

FM1 in OM3 M1 COUIOUTF was turned on, that's a digital LPF used when hardware LPF is off, but the hardware filter is always on, causing mismatch. The same filter was turned on for OM2, but it was set back to normal after ~30 minutes. After rebooting things yesterday, state request for OM3 coils got back to normal.

Today I made OM3 P damping TF and it made sense (attached dtt, red is now, blue is when COILOUTF was in a bad state). Taking into account the sign flip between the red and blue, clearly the blue is delayed about 60deg at 1Hz and maybe 80deg-ish at 2Hz.

The blue showed a huge L coupling, which went away in today's data, I don't know why. (Green trace is the L2L OLTF just to show you where the L peak is.) I haven't bothered to change the state request back to 1, flip the damping gain and repeat the measurement just to see if  the L coupling comes back.

I don't know how this happened.

Images attached to this comment
H1 PEM (ISC, PEM, TCS)
marc.pirello@LIGO.ORG - posted 16:45, Friday 26 January 2024 - last comment - 11:39, Thursday 01 February 2024(75592)
CER Accelerometer Chassis Installed

Replaced the Endevco Accelerometer Power Conditioners with LIGO Accelerometer Power Conditioners. WP11653

Order in the rack:

U19 - Accelerometer Power Conditioner S2300062

U16-U17 AA Chassis S1300101

U14 - Accelerometer Power Conditioner S2300063

U13 - Accelerometer Power Conditioner S2300065

U12 - Accelerometer Power Conditioner S2300069

U11 - Accelerometer Power Conditioner S2300064

Still have EX, EY, MX, MY, FCES to complete.

M. Pirello, J. Jimerson. R. Schofield

Comments related to this report
marc.pirello@LIGO.ORG - 16:28, Tuesday 30 January 2024 (75636)

Mid Y, we were not able to connect power, we installed the chassis and will revist.

Installed Accelerometer Chassis at EX, cables connected and chassis powered up.  One of the Acelerometer cable connectors is loose and will be repaired later this week but it is functional.

Signal Order Asbuilt:

Slot = Cable Number = Accelerometer Number

1 = 4 = PEM EY BSC10

2 = 7 = PEM EY EBAY

3 = empty = empty

4 = 1 = PEM EY OPLEV

5 = empty = empty

6 = empty = PEM EY BSC6

7 = 6 =Black Cable

8 = 2 = PEM EY BSC10

9 = 3 = PEM EY TRN

10 = 5 = PEM EY BSC ACC X

We have no slot 10 on the new chassis therefore we moved cable 5 to slot 5, and moved the PEM EY BSC ACC X cable to match on the back.

Once we matched the cables we rearranged the signals to match the numbering on the front, i.e. cable 1 goes to slot 1, cable 2 goes to slot 2, etc...

Slot = Cable Number = Accelerometer Number

1 = 1 =  PEM EY OPLEV

2 = 2 = PEM EY BSC10

3 = 3 =  PEM EY TRN

4 = 4 = PEM EY BSC10 (this cable had a loose connector, but registered as an accelerometer)

5 = 5 = PEM EY BSC ACC X (this cable did not register as an accelerometer)

6 = 6 = Black Cable (this cable is unlabeled)

7 = 7 = PEM EY EBAY

8 = empty (This needs AA and signal)

9 = empty (This needs AA and signal)

J. Jimerson, M. Pirello

marc.pirello@LIGO.ORG - 17:01, Wednesday 31 January 2024 (75652)

Further investigation into EY Accelerometers

Slot = Cable Number = Accelerometer Number

1 = 1 =  PEM EY OPLEV

2 = 2 = PEM EY BSC10_Y (Should be BSC10_ACC_X)

3 = 3 =  PEM EY TRN (should be BSC10_ACC_Y)

4 = 4 = PEM EY BSC10_Z 

5 = 5 = PEM EY BSC ACC X (should be TRN_TBL_ACC_Y)

6 = 6 = Black Cable (this cable is unlabeled) * same issue as EX

7 = 7 = PEM EY EBAY

8 = empty (This needs AA and signal)

9 = empty (This needs AA and signal)

Same as EX, CH2 moves to CH3, CH3 moves to CH5, CH5 moves to CH2.

marc.pirello@LIGO.ORG - 11:39, Thursday 01 February 2024 (75674)PEM

Removed S2300069 from CS PEM rack, this is not supposed to be installed here.

Displaying reports 11261-11280 of 84712.Go to page Start 560 561 562 563 564 565 566 567 568 End