Displaying reports 241-260 of 89077.Go to page Start 9 10 11 12 13 14 15 16 17 End
Reports until 16:06, Tuesday 11 August 2026
H1 ISC
sheila.dwyer@LIGO.ORG - posted 16:06, Tuesday 11 August 2026 - last comment - 09:29, Monday 17 August 2026(91481)
arm peak today, COMM beatnote and PRMI flashes.

Camilla, Oli, Caroline, Masayuki, Sheila

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 09:29, Monday 17 August 2026 (91562)

During this realignment, SR3 was moved 65urad in Pitch, see attached.

Images attached to this comment
H1 SQZ (SUS)
ryan.short@LIGO.ORG - posted 15:57, Tuesday 11 August 2026 - last comment - 15:37, Friday 14 August 2026(91484)
ZM4 PSAMs Preload Adjusted (Again, Final)

R. Kumar, S. Dwyer, C. Compton, R. Short

Following the work done yesterday adjusting the preload on the ZM4 PSAMs (alog91471), Rahul and I set about adjusting it further today to get our calculated projected beam size on SRM close to where we want it. Using the same procedure as yesterday, I turned off the ZM4/5 PSAM drive chassis, Rahul went into HAM7, locked down ZM4, torqued the preload about 1/8" of a turn (it's hard to quantify a torque spec in this manner), then finally unlocked the suspension. I moved the ZM4 pitch alignment slider about -1400 counts to realign the beam on SQZT7 to our alignment irises as a result of this torque adjustment. I then proceeded to take a couple of beam profiles on the table with the M^2 device to see where we landed. This plot [initial] shows the difference between before and after this adjustment in terms of the projected beam at SRM with a few different PSAM settings on ZM4 and ZM5. The four points I took here informed us that we could stand to torque ZM4 a bit further to hopefully line up with the center of the plot.

Rahul went back into HAM7 and torqued another 1/8" and I took another couple of profiles after (I did not need to move ZM4's alignment sliders after this adjustment). I took a total of nine profile points here, all of which can be seen compared to other measurements today on this plot [full]. Since there are points in the bullseye, we decided to stop here and that this is where the ZM4 preloading will stay. This plot [final] shows just the beam profiles taken at our final preloading position.

Tomorrow we will move on to final closeout checks in HAM7.

Images attached to this report
Comments related to this report
ryan.crouch@LIGO.ORG - 16:26, Tuesday 11 August 2026 (91486)SUS

I ran a health check TF on ZM4 and it looks good.

2026-08-11_2200_H1SUSZM4_M1_WhiteNoise_L_0p02to50Hz.xml
2026-08-11_2200_H1SUSZM4_M1_WhiteNoise_P_0p02to50Hz.xml
2026-08-11_2200_H1SUSZM4_M1_WhiteNoise_Y_0p02to50Hz.xml

Non-image files attached to this comment
rahul.kumar@LIGO.ORG - 10:26, Thursday 13 August 2026 (91515)

The current pre-load value on the ZM4 is 60in-lb + 1/8th + 1/8th turn using a 0.5in size wrench.

sheila.dwyer@LIGO.ORG - 15:37, Friday 14 August 2026 (91551)

Here is a scatter plot for Ryan's final set of measurements, at the final ZM adjustment before the doors went on HAM7.  

It seems that in this position the values of M^2 are smaller than those in 91455 91385 and 90804, and the overlap between the vertical and horizontal q parameters is slighly better.  We can expect to get mode matching better than 99% between the squeezer and OMC for a pretty good amount of our psams range.  

Images attached to this comment
H1 SPI
jennifer.wright@LIGO.ORG - posted 11:59, Tuesday 11 August 2026 - last comment - 12:05, Tuesday 11 August 2026(91482)
SPI medm housekeeping checks

Jennie W, Sina K, Jim W,

 

Summary: Yesterday we had a check through the SPI model just to make sure we have turned on everything and that all is working well, we got as far as ascertaining that no light was making it to the PDs on the ISIJ and K benches and also did some other checks on the LO aand longitudinal IFO paths.

Couple of things we discovered/checked:

NB: We found out today that the shutter controller for our laser pick-off was not connected - Jim and Fil have now solved this (alog #91467).

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 12:05, Tuesday 11 August 2026 (91483)

Today Jim also turned on H1:SPI-H23_DIFFDISP_MAIN_GAIN output  and set the gain to 1 to debug the sending of signals to the ISI model. I have accepted these in SDF.

Images attached to this comment
H1 General
ryan.crouch@LIGO.ORG - posted 07:36, Tuesday 11 August 2026 - last comment - 10:52, Monday 17 August 2026(91474)
OPS Tuesday day shift start

TITLE: 08/11 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: CALM
    Wind: 9mph Gusts, 4mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.06 μm/s 
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:09, Tuesday 11 August 2026 (91475)SUS

The M2 stage of the BS has been moving a lot since yesterday afternoon ~21:17 UTC, the oplev damping has grown with it.

Images attached to this comment
louis.dartez@LIGO.ORG - 08:42, Tuesday 11 August 2026 (91476)
The BS oplev damping was turned back on by me inadvertently yesterday. The OLDAMP Gain increases happened right as I requested DOWN from the ISC_DRMI guardian. Masayuki and I did notice additional motion on the BS yesterday but we didn't know at the time whether it was due something we did or from something someone else was doing. Now, looking at the timing of the grd state request and confirming by looking at ISC_DRMI.py, I can say that the BS oplev damping was 1.) turned on by accident and 2.) can be / should be turned back off.
Images attached to this comment
elenna.capote@LIGO.ORG - 08:48, Tuesday 11 August 2026 (91477)

I tried to SDF the oplev damping off, see 91267, but I never checked what the guardians do. I recommend we change the guardian code to not engage oplev damping until we can diagnose why it isn't working, specifically, saturating the suspension.

louis.dartez@LIGO.ORG - 10:52, Monday 17 August 2026 (91564)
This was messing us up again today. I commented out the BS Oplev DAMP lines in the ISC_DRMI DOWN state.
H1 CDS
erik.vonreis@LIGO.ORG - posted 03:28, Tuesday 11 August 2026 (91473)
Workstations updated

Workstations were updated and rebooted. This was an OS packages update.  Conda packages were not updated.

H1 SQZ (AWC, SQZ)
sheila.dwyer@LIGO.ORG - posted 21:21, Monday 10 August 2026 (91471)
ZM4 psams adjustment today

Rahul, Ryan, Sheila

Today we think that we found a rapid way to iterate the psams preloading, and we made a couple of changes for ZM4.  

Frst Ryan and I measured the beam profile with ZM5 psams servo set to -8V, and ZM4 psams PZT votlage at 0V,  

Rahul can add the details of how he did this, but he added about 1/8 turn of torque to the ZM4 psams.  We then turned the laser back on, and took a beam profile measurement.  Unfortunately the profiler software got into a strange state where the beam waist seemed to be at a very different position and it would not calculate the original beam parameters.  We thought this was because the beam profile had changed dramatically, and Rahul backed off the preload by 1/8 of a turn.  As we were remeasuring the profile Ryan S noticed that the range of the translation stage displayed on the screen went only from 0-100mm, while it normally goes from 0-200mm.  The software would not allow Ryan to reset the measurement range parameter, until we powered the profiler off, exited the software, and started both up again.  

After this, we saw that indeed we had a reasonable q measurement, although not really an improved mode matching. It does seem promising to adjust ZM4 this way, as each iteration took about 30 minutes including our confusion about the beam profiler.  

Images attached to this report
H1 ISC
louis.dartez@LIGO.ORG - posted 19:37, Monday 10 August 2026 (91470)
PSL Green Beam aligned onto COMM PD on ISCT1
S. Dwyer, J. Oberling, L. Dartez

This afternoon we went to ISCT1 to align the green beam from the PSL Green PD, and ALS COMM PD. This is pre-peek prep so that by the time the peek takes place we don't need to worry about the beam alignment from the PSL.

We struggled a little bit to find an alignment that agreed with the crystal and the downstream PDs. We were able to get a beam onto the COMM PD. Sheila thinks that what we set up so far is more than enough to get a beatnote during the arm peek. We aligned the green beam onto the green PD but for some reason couldn't get see a readout signal that corroborated that the beam had made it onto the diode. We tried doing some troubleshooting, which included a local cable swap and adjusting the PD placement on the table. Neither were successful and, given the time of day, we opted to revisit at a later time. The important part thing is that the COMM PD _was_ seeing the beam. 
Images attached to this report
H1 CDS
jonathan.hanks@LIGO.ORG - posted 18:11, Monday 10 August 2026 (91469)
WP 13504 investigating higher rate of transport issues

As per WP 13504 we made some changes on h1daqdc0 to see if they would impact the error rate*.  We turned on the irqbalance daemon to see if that would help with IO load.  We are going to let this run a day or two and evaluate what things look like.  We are looking at other ideas (timing changes, network config changes, possible code changes to lock cores and network interrupts together better) but are going to hold off until the control room is ready.

* In the daqd, the CRC errors are a misnomer.  It really means late data, not corrupt data.

H1 SEI
jim.warner@LIGO.ORG - posted 17:58, Monday 10 August 2026 - last comment - 12:08, Tuesday 18 August 2026(91468)
Testing high voltage CPS on HAM8 ISI overnight

While Huyen is here, we've dug out the high voltage CPS that we got several years ago to try testing them on HAM8 again. We have a little preliminary data, that doesn't look good so far, but we will try to see if we can get any improvements over the next couple of days, while HAM8 is still isolated from the rest of the detector.

Comments related to this report
huyen.pham@LIGO.ORG - 12:08, Tuesday 18 August 2026 (91553)

We had the HV CPS connected at HAM8 ISI from Monday 08/10 to Friday 08/14. We could not get the HV CPS noise floor (around 100Hz) down to expected level - x4 better than the normal CPS sensor noise as seen before in alog 78287 (tested at HAM7). Figure 1 is HV CPS noise at HAM8 - reference is th normal CPS before swapping. As we troubleshooted, the noise got modulated some but never get to expected noise floor. The best we can get is x2 better. Another issue is that some HV CPS noise floor is not stable, see short figure 2 and clip #1.

We have tried to troubleshooting this without success by isolating all the rack and interface/ethernet boxes off the ground, adding some wrap to make them more thermal stable, swapping cables around. From the start, the light indicators on the board did not make sense. While plugin, the near/far light on H2 module never went away, and the light on H1 and H3 modules were not even on even before plugging in. However, the signals looks okay in timeseries. The ISI can still be isolated with these HV modules. 

I've tried to select the time where few of the noises is low and best present cartisian DOF to check the performance, but none looks great.

If the noise is not stable and comparable between sensors, this is hard to tell if the performance improved or whether the HV CPS actually helps. 

Images attached to this comment
Non-image files attached to this comment
H1 SPI
jim.warner@LIGO.ORG - posted 17:48, Monday 10 August 2026 - last comment - 09:56, Tuesday 11 August 2026(91467)
No power on power mon pd in SPI laser chassis

Jennie and I were looking at the SPI with Sina during a call today and Sina pointed out there was no power on the first PDs on the SPI breadboard. She said there was a witness pd in there SPI laser chassis that could be checked with a multimeter next to the chamber, so I went and checked that this afternoon. I'm not totally sure what all of the labels meant, but I think there is no laser light on the pd in the interface chassis. The SPI_LP_M1_PD was at 0v, the other two, SPI_LPMON_M2_RFMEAS and SPI_LPMON_M3_RFREF were at ~.8v regardless of the state of the CDS control of the SPI pick off shutter, which I had Ryan toggling remotely. We've talked to Ryan and Jason about going into the PSL tomorrow to check the function of the SPI pick off shutter, I think we will also try to check the output of the fiber at the chassis with a laser card at least. Not sure how hard it would be to look with a power meter.

Images attached to this report
Comments related to this report
filiberto.clara@LIGO.ORG - 09:56, Tuesday 11 August 2026 (91478)

Cable at shutter controller on IOT1L was not connected. DB9 was connected to ouput CH2.

LHO General
corey.gray@LIGO.ORG - posted 16:33, Monday 10 August 2026 (91458)
Mon Day Ops Summary

TITLE: 08/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan S

SHIFT SUMMARY:

Input Align & ZM4 work continued today with LVEA being transitioned to HAZARD toward the end of the shift for checks at ISCT1.

Apollo on-site to begin work addressing a beam tube enclosure section which is failing by installing framework inside the beam tube enclosure (this section in question is part of X1 on the Xarm [near the bridge]).

VAC team has been preparing for the quick X-arm opening peek tomorrow.

 LOG:

H1 SUS (SUS)
timothy.ohanlon@LIGO.ORG - posted 15:29, Monday 10 August 2026 (91466)
QOSEM to BOSEM Performance Comparison

+ Valera

Now that we have the full 6x12 QOSEM to Euler matrix implemented at LLO, I have made a bunch of comparison plots looking at ITM BOSEMs and BBSS QOSEMS. Per sensor, we see about 2 to 3 times improvement but expected more like 10x. I made the comparison for L1 and H1. I also directly compared L1 v H1 BBSS QOSEM performance and compared the L1 6x6 v L1 6x12 OSEM to Euler Matrix.

L1 BS QOSEM vs L1 ITM BOSEM
H1 BS QOSEM vs L1 ITM BOSEM
L1 vs H1 QOSEM
L1 6x6 vs L1 6x12 OSEM to Euler Matrix 

Some things to note for the comparison plots

Non-image files attached to this report
H1 IOO (IOO)
khanh.vu@LIGO.ORG - posted 14:32, Tuesday 04 August 2026 - last comment - 00:43, Tuesday 11 August 2026(91386)
IOT1 Table Work
Jennie Wright, Masayuki Nakano, Khanh Vu

This morning we worked on several tasks on the IOT1 table, including installing the camera and shutter, profiling the beam, and calibrating the DC power.

We identified a new location for the camera using the beam transmitted through JACR_M5. During this process, Masayuki noticed that the beam was being clipped by the shutter. We suspect that the beam may have been clipped for some time. We then installed the camera in its new location, and Masayuki aligned the shutter on the table.

Next, we profiled the beam for the wavefront sensors. We found that the Gouy phase separation between the two WFSs is approximately 70 degrees. We decided to leave the current configuration as it is since the separation is good enough. Masayuki will make a plot and perform a more detailed calculation later.

We also maximized the laser power in the REFL path by optimizing the waveplate angle. When JAC is unlocked, the measured power on the RFPD is 5.1 mW, and the trigger PD voltage is 0.28 V. When JAC is locked, the measured power decreases to 0.4 mW, and the trigger PD voltage is 0.02 V. Since the beam is split evenly, each WFS receives approximately 2.55 mW of optical power.

Finally, we calibrated the DC readout of RFPD by converting counts to mW. Before performing the calibration, Masayuki checked the alignment and recentered the RFPD. He then recorded two sets of measurements, each averaged over 10 seconds:

Measurement #1

* JAC_REFL_A_LF_INMON: 1072.3966186523437 counts
* DC power: 4.4 mW

Measurement #2

* JAC_REFL_A_LF_INMON: 1073.5228637 counts
* DC power: 4.5 mW

After the calibration, we updated filter number 10 with the new coefficients.
Comments related to this report
masayuki.nakano@LIGO.ORG - 14:56, Tuesday 04 August 2026 (91388)

The beam profile between the beamsplitter and the JAC WFS  was measured. Here I fit a Gaussian beam to those measured beam sizes and convert the WFS locations into Gouy phase.

Fit

The measured beam diameters were fit independently in x and y with the standard Gaussian beam model, w(z) = w0 * sqrt(1 + ((z - z0)/zR)^2) with zR = pi * w0^2 / lambda and lambda = 1064 nm:

  w0 [um] z0 [m from JACR_BS4] zR [cm]
x 141.2 0.377 5.89
y 151.9 0.370 6.81

The beam is slightly astigmatic, so x and y are treated separately throughout.

WFS positions and Gouy phase

The positions of WFS A and WFS B were measured with a ruler from the same reference as the profile scan: WFS A at z = 0.325 m, WFS B at z = 0.410 m. The corresponding Gouy phases, psi(z) = arctan((z - z0)/zR), are:

  WFS A [deg] WFS B [deg] Separation [deg]
x -41.3 +29.5 70.8
y -33.5 +30.4 63.9

Assessment

The separation is 71 deg in x and 64 deg in y, not the optimal 90 deg. This is not optimal, but it is not terrible either: the two WFS remain well separated in Gouy phase and the sensing matrix would not be close to degenerate. Given the time available we did not optimize the layout.

If we want to optimize it later, the fix is straightforward: moving WFS A upstream (toward the BS) by about 5 cm in x / 7 cm in y, i.e. from z = 0.325 m to roughly z = 0.27 m, brings the separation to 90 deg. WFS B does not need to move. 

Images attached to this comment
khanh.vu@LIGO.ORG - 09:38, Wednesday 05 August 2026 (91405)
Additional context for the work described above: The motivation for the table work came from the difficulties we had with the sensing and input matrices of the JAC ASC loops. In pitch, the PZT and JM1 signals are well separated, but their responses in yaw are too similar. This is problematic because we need the two wavefront sensors to distinguish between the motions of the two actuators.

While identifying a new location for the camera, Masayuki noticed that the shutter was clipping approximately half of the beam on the left side. We suspect that the beam may have been clipped for some time and that this may be related to the yaw issue, since the clipping affects yaw more strongly than pitch.
masayuki.nakano@LIGO.ORG - 00:43, Tuesday 11 August 2026 (91472)IOO

Summary

Today we installed the iris to block the ghost beam on the JAC REFL path with an iris, and to re-measure the beam profile with it in place. The ghost beam was produced by the laser window which picks off the partial power of the JAC reflection beam (~0.4%). Since this laser window doesn't have the wedge on it, the AR reflection is not well separated. We observed this interference during the original beam profile measurement in this thread. 

And now, the iris dumps the ghost beam, and we made a new the beam profile measurement. I made a good JAC REFL optical model which obtained by the fitting the beam profile measurement. We will use this model for the WFS signal calibration.


Iris installation

An iris was placed on the REFL path, between the first pick-off mirror and the first lens. To position it, the beam profiler was set just after the beam shutter, and the iris was closed while watching the profile, until the ghost was blocked and the main beam was left untouched. Actually, Since the ghost beam is very close, the main beam is partially blocked as shown in the attached pics. We will see if it would have any effect on our WFS signals.


Beam profile measurement after the change

1/e2 diameters along the REFL path, with JACR_MB4 as the origin:

z [inch from JACR_MB4] -21 3.5 5.5 7.5 9.5 11.5
horizontal [μm] 4440 1360 1140 895 696 500
vertical [μm] 4540 1360 1111 873 661 461

On-table distances were also measured: JACR_L1 to JACR_MB4 = 24", JACR_MB4 to WFS A = 12.5", JACR_MB4 to WFS B = 15.5".


New propagation model

I made a model of the beam propagation of the JAC REFL path from PSL to JAC and IOT1. This model was fitted to the new profile, with the PMC waist as origin.

Taken as known. The positions of lenses in PSL (IO_MB_L1/L2/L3) and of the JAC waist are the design values, i.e. the PSL bench to HAM1 relative distance is trusted.

Taken as unknown. The design placed the IOT1 table only loosely, and the periscope that matches the HAM1 beam height to the table height was estimated roughly. The distance from the JAC input to the IOT1 table is therefore the principal free parameter, allowed ±30 cm; it enters the calculation as the position of JACR_L1 measured from the PMC waist. The profile measurement was referenced to JACR_MB4, which carries its own error, so the JACR_MB4-JACR_L1 distance is a second free parameter.

The profile carries astigmatism, so a yaw tilt was allowed on each of the four lenses (three on the PSL bench, one on IOT1). This is deliberately over-parameterised: the individual tilts should not be read as physical alignment errors.  However, the aim of this analysis is not to measure how each lens sits but a model accurate enough for the following calculation. So as long as the aquired prameters are physically reasonable, we can use these numbers as the following calculations.

One note:
The HAM1 periscope (JAC_M1/JAC_M2) rotates the beam 90 degrees about its axis, so the transverse planes swap on the way to JAC: bench x (YAW) descends from the upstream sagittal channel and bench y (PIT) from the tangential one. A tilt therefore gives astigmatism of opposite sign depending on which side of the periscope the lens sits. This is the reason why the x/y beam size flipped at periscope in the attached plot.


Result

parameter fitted vs design
JACR_L1 position from PMC waist 11.4768 m -21.5 cm
JACR_MB4 to JACR_L1 0.6004 m -0.36"
yaw tilt, IO_MB_L1 / L2 / L3 -16.9° / -7.1° / -1.8° -
yaw tilt, JACR_L1 -3.2° -

The fitted path from the JAC input to the IOT1 table comes out about 21.5 cm shorter than design, which is the scale of looseness that was expected there.


Astigmatism at the WFS planes

Expressed as the difference in accumulated Gouy phase between the two transverse axes:

  model from the measured profile alone
WFS A -4.10° -4.96°
WFS B -10.61° -10.32°

Sanity check: mode matching into JAC

Taking the cavity eigenmode as the reference, the fitted injection-lens tilts imply a mismatch of 0.48 % (tangential) and 0.43 % (sagittal), 0.91 % combined. Small enough not to conflict with the measured mode matching (~1%).


Model parameters

PMC eigen mode

axis w0 [μm] zR [mm]
tangential (u) 546.312 881.232
sagittal (v) 549.028 890.016

The waist sits at z = 0 in both axes. Downstream of the periscope the tangential channel becomes bench y (PIT) and the sagittal channel bench x (YAW).

Elements

z is given from the PMC waist (the model's own origin) and from JACR_MB4 (the origin the bench profile was measured against).

element z from PMC waist [m] yaw tilt [deg] source
PMC waist 0.000000 - origin
IO_MB_L1 0.900000 -16.86 design / tilt fitted
IO_MB_L2 0.960000 -7.12 design / tilt fitted
IO_MB_M4 (PZT) 2.812000 - design
IO_MB_L3 2.900000 -1.75 design / tilt fitted
HAM1 periscope (JAC_M2) 7.040000 - design; x/y swap
JM1 7.268000 - design
JAC input mirror 7.576000 - design
JAC waist 7.826000 - design
JACR_L1 11.476799 -3.15 fitted
JACR_MB4 12.077174 - fitted (via JACR_L1 distance)
WFS A 12.394674 - measured from JACR_MB4
WFS B 12.470874 - measured from JACR_MB4

What was fitted, and what was not

parameter fitted value design allowed range
JACR_L1 from PMC waist 11.476799 m 11.691967 m ±30 cm
JACR_L1 to JACR_MB4 0.600375 m 0.609600 m ±1"
yaw tilt, IO_MB_L1 -16.8588° 0 ±20°
yaw tilt, IO_MB_L2 -7.1210° 0 ±20°
yaw tilt, IO_MB_L3 -1.7534° 0 ±20°
yaw tilt, JACR_L1 -3.1527° 0 ±20°
Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:40, Friday 24 July 2026 - last comment - 12:03, Friday 14 August 2026(91238)
PRMI alignment this morning

Keita, Sheila, Tony,  Jennie W

Before the JAC PZT problem, I did get an hour or so of alignment time in.  Summary: we now have light on LSC POP and POP X for the same PM1 alignment, and ITMX is back to the alignment that should point down the arm.  We have the expected power in LSC POP path, but a factor of 20 too small in both DC and RF signals in the popair path. 

These screenshots show MICH fringes with 10W input power, where I started and where I ended.  The idea was to move to the ITMX alignment that Jenne Driggers found using the arm beam here: 89738.  I watched the mich fringes and AS camera while moving the ITM, moved the beam splitter to keep the michelson fringes, and as Keita suggested moved PR3 to keep the beams on the ISCT1 refl camera.  This did cause the michelson fringes on the LSC pop diode to get smaller, when that happened I paused, went to the PR2 spot move guardian state, and adjusted PR3 to bring the fringes back on LSC POP.  After bringing the ITMX yaw alignment back I could see that there is now light on POPX and LSC POP A for the same PM1 alignment.  

When I walked ITMX pitch, I had to also adjust yaw several times as I went along to keep the mich fringes.  I also adjusted PRM to keep PRX alignment good as I moved along. Looking at this screenshot of the brief time when PRMI was flashing, the POP A LF flash was about the O4 power level (91211), as was reflair A, but popair has too little power.   The result of this was that PR3 started the day 56urad away from the O4 slider, but is not -15urad.  PR3 yaw started the day close to the O4 slider but is now -47urad.

I also adjusted the POP X dark offsets so that this QPD will be less confusing to read, SDF screenshot attached.

We tried walking PR3 in PR2 spot move to allow us to centering POP X without saturating PM1, this alignment is shown in this screenshot, but when we then aligned PM1 to put the beam on LSC POP, we were missing power there. 

 

  POP A LF POPAIR B LF REFLAIR A LF MICH IN1 (REFLAIR A 45 Q) PRCL IN1 (REFLAIR A 9I) POPAIR B RF18 POP X NSUM
PRMI O4 200-400 200 2-10 +/-6000 +/-600 80-100  
PRMI yesterday 100 6 (10 today) 2.5-4 +/-20 +/-100 5  
PRX O4 0.5            
PRX now 0.5            

MICH dark O4

1468885440 

7 1 0.01       -0.5 (dark level -0.6)
MICH dark PM1 -265 P -2364 Y) 1 0.01       3.1 (centered)
MICH dark PM1 0,0 4 1 0.01       0.2 (P and Y both close to -1)
Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 10:45, Tuesday 11 August 2026 (91480)

The MICH dark time that I labeled as O4 above was actually from July, a better time to use for O4 (chosen from a list that Tony generated of MICH dark times) would be 1457969940 which is May 28 2025 00:15:42 UTC.

sheila.dwyer@LIGO.ORG - 12:03, Friday 14 August 2026 (91546)

MICH dark time from May 28th 2025, 00:15:42 UTC

  • POP A NSUM + POP B NSUM: 3.3, 3.4 counts
  • POPAIR B LF = 1 count
  • POP A LF OUT DQ = 4
  • POP X (7e-4) there was a factor of 400 normalization that Elenna removed, so this would now be 0.28

Now MICH dark locked:

  • ASC POP A + B 1.2 and 0.8 counts
  • POPAIR B LF 0.1 count
  • POP A LF 0-0.4 counts (noisy)
  • POP X 0.2
Displaying reports 241-260 of 89077.Go to page Start 9 10 11 12 13 14 15 16 17 End