TITLE: 08/18 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: 3mph Gusts, 0mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY: Some light maintenance tasks this morning, then alignment of the corner will continue to get us to locking DRMI.
Workstations were updated and rebooted. This was an OS packages updated. Conda packages were not updaed.
TJ, Camilla
I put SR3 into it's O4 alignment (P 458, Y -135) changed from (P 524, Y -135), checked no saturating pixels (ITMX stayed at 1Hz frame rate, ITMY increased to 5Hz), took new HWS references and started the HWS code.
We are running a ring heater test with 2W/segment for 4 hours this evening. Using scripts below on tmux sessions:
Ring heaters should be back to nominal by ~1am. Purpose of this is to check HWS alignment before we align the CO2s (using HWS).
Just to confirm that there's nothing grossly wrong with the beam coming into PSL ISS 2nd loop array, I tried to minimize the jitter coupling from IM3 dither to PDSUM_INNER. If there is something terrible, we might have to change the IM2 and IM3 angle again, which will change the input alignment into the IFO, so it makes sense to say that IM2/IM3 are good now. That way, ISS alignment will be truly isolated from the IFO.
I moved two picos for ISS and ended up with the following coupling in RIN/m:
This looks to be consistent with October/2025 measurements in the lab: https://dcc.ligo.org/T2500077-v4, the screenshot of which is attached here as 2025October_T2500077.png. INNER (i.e. PD1/2/3/4) PIT is somewhat worse, INNER_YAW is at least a factor of 3 better. (OUTER_PIT is somewhat better and OUTER_YAW is a factor of 2 worse, but I haven't tried to make OUTER sensor better.)
I went away from the center of the QPD: PIT=-0.603 YAW=-0.295, which corresponds to -84um in PIT and -41um in YAW. This is to say that the displacement is not huge at all. Don't try to center.
The first pico (ch1 for HAM2) was moved from (X,Y)=(0,0) to (569,-476), the second (ch8) from (0,0) to (685, -541).
Though individual diode outputs are all different from O4 days because of different alignment, PDSUMINNER and PDSUMOUTER are the same as in O4 (compare ISSpath_align_20260817.png with ISS_INNER_and_OUTER_in_O4.png).
I didn't make a huge scan so I don't know how far the beam is from the edge of the diodes, but this already looks OK to me. If needed we can search for a better spot position further without changing IM2/3.
What was done:
DTT template and my detailed memo of what was done are available in /ligo/home/keita.kawabe/ISS2ndAnd3rdLoop/ISS2ndLoopAlignment
TITLE: 08/18 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: The optics lab has been a little dusty today, three events over 10k 0.3um particles and its got up to 40k as of 18:30. PSL laser room is also seeing some counts, 300-400 in the 0.3um range. The MSR has also heated up a few degrees, but it seems to have plateaued. Corner alignment continued and there is still more to be done. There are a few overnight tests planned... A SEI injection on HAM3 in RY and X (Huyen) is on going as of end of shift, some JAC heater tests (Jennie) will be later tonight?, an IFO power increase with JAC (Masayuki) is on going as of end of shift, and a ring heater test with SR3 (Camilla) ~8/830PM PST / 20:00UTC.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 23:39 | SEI | Jim | FCES | N | Restore config/settings | 23:50 |
E. Capote, L. Dartez, K. Kawabe, C. Compton Today we've tried to get PRMI locked without success. Here are some brief notes about what we tried since both Elenna and I have to go for the day. This morning Elenna ran a full initial alignment, checked PRX and MICH BRIGHT, and aligned for PRMI. She noted that the flashes we were getting were very low and PRMI wouldn't lock. We checked the input alignment and noticed that the alignment that Keita and I set up in 91447 were kicked sometime early last week. It wasn't immediately clear to us why. We checked for drift in the MCs and IMs then reset the IMs to where Keita and I placed them in 91447. We then had to re-find PRX by moving IM4, PR2, and PRM. We made a point to avoid touching ITMX and PR3 since their positions were set when we had the arm during last week's peek. We also checked the BS alignment in MICH to make sure we were in a good place there. We also measured the MICH and PRX OLGs ... they look fine and match the reference measurements in the dtt templates in userapps. We also went over Masayuki's notes from when he got PRMI locked last week (91501) to make sure all of his changes stuck. They did for the most part but for some reason the REFLAIR_A_RF9 gain got reset to 2.5. We fixed that but there might somewhere in the guardian code that needs to be fixed to keep the 3.5 gain. We continue to struggle to lock PRMI as it doesn't seem to trigger for long enough to maintain the lock. Some more things that we'll try tomorrow: 1.) trend and compare today's flashes against last week's. 2.) re-check the POP clipping situation to determine whether we made things worse. 3.) go out to ISCT1 to check the REFLAIR diode and make sure it's still well aligned. 4.) run POPX centering. Elenna and/or I will circle back to provide some plots etc here later on as we both have to run now. We are handing things off to the JAC and SPI teams for evening/overnight tests.
I have installed a new EPICS IOC (dac_overflow_rate_ioc) which for each model calculates the per second increase in the accumulated DAC overflow counter. If the rate is non-zero, the upper block of the DAC Overflow square in the CDS Overview turns yellow. The lower block shows dark green if the accumulated counter is non-zero (i.e. overflows in the past which have not been cleared).
The new IOC runs on the service host cluster, it is monitored by a "DAC OVERFLOW" system block at the bottom of the CDS Overview.
Please note that the accumulated DAC overflows wrap-around at 0x1000000 (just over 16 million) to prevent the number on the MEDM becoming too large to be read.
Jennie W, Sina K, Jim W,
We made good progress today. There was a factor of 4 that we had forgotten in the demodulation that you need to scale the final amplitude by to get the Vpp. Once we put this in we get ~100% for the reference interferometer and 76% for the measurement interferometer.
We debugged the demodulation calculation by turning off the signal input to the REF A IFO and then looking at what heterodyne amplitude it calculated when we injected a signal of 2Vpp into the H1:SPI-H23_IFO_REF_A_DEMOD_SIG filter bank.
See the photo showing the injected signal calibrated into volts in yellow, in purple the amplitude calculated as A = sqrt( I^2 + Q^2), where I and Q are the output of the demodulator, and in red is the out amplitude after multiplying by a factor of 4.
I put this calibration factor into all four H1:SPI-H23_IFO_{REF,MEAS}_{A,B}_HETAMP filter banks as cal_demod in FM0.
We also measured the dark offsets for the four PDs and two QPDs. We did this with the shutter closed. From the input counts, the QPD B segments look a lot noisier than the QPD A segments so I wonder if we are getting scattered light from main IFO beam.
I might redo this dark offset test with the JAC unlocked or with the PSL shuttered in order to verify this. It might also explain why we occasionally get the efficiency calculation of the reference interferometer coming out to 101% if we have stray light on one or more PDs.
The calibration factors and new dark offsets were accpted in SDF.
One of the nights this week we will start our program of calibration measurements using the ISI sensors to calibrate the SPI sensors.
Per WP 13415 I finished migrating the dust monitors and the dewpoint monitor to the IOC cluster (service-host 0,1,2). With this I was able to turn off the old h0epics server. These will now auto start after power outages as well as there are no manual steps in the startup sequence.
One note.
The dewpoint monitor held its files in /ligo/lho/h0/target. As a limit in the container I am running these in it wants the command that is executed to be under /opt/rtcds. So I copied the target area over to /opt/rtcds/lho/h1/target and put a symlink in on /ligo/lho/h0/target/dewpoint.
TJ, Camilla WP #13528
Today we swapped the ITMY HWS SLED as it had degraded, last swapped May 2025 84417.
Following the T1500193 procedure
TITLE: 08/17 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: After diagnosing some alignment troubles, work has continued towards being able to lock PRMI. The ITMY HWS SLED was swapped, the corner volumes continue to be pumped down, and the LVEA is still Laser HAZARD.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 14:38 | FAC | Randy | LVEA | - | ISI craning prep | 15:31 |
| 14:52 | FAC | Kim | LVEA | - | Technical cleaning | 15:47 |
| 16:35 | PSL | Jason | OptLab | - | Parts search | 16:56 |
| 17:04 | SEI | Jim | FCES | - | HAM8 ISI work | 21:04 |
| 17:07 | FAC | Kim | EY | - | Technical cleaning | 18:07 |
| 18:26 | VAC | Gerardo | LVEA | - | Checking HAM7 | 18:31 |
| 19:52 | FAC | Randy | LVEA | - | Craning scissor lift | 20:52 |
| 20:45 | VAC | Gerardo, Travis | LVEA | - | Prepping to move super sucker from HAM1 to HAM6 | 21:25 |
| 21:22 | SEI | Shoshana, Huyen | LVEA | - | Removing CRS laser copper block | 21:32 |
| 21:42 | DAS | Jenne, Reinhardt | LVEA | - | Running DAS fiber | 22:10 |
| 22:08 | SAF | TJ | LVEA | YES | Transitioning to Laser HAZARD | 22:40 |
| 22:42 | TCS | TJ, Camilla | LVEA | YES | Swapping ITMY HWS SLED | 23:29 |
[Huyen, Shoshana]
We saw worsening CRS noise after adding copper block on top of the laser in an attempted to help with thermal regulation. We went ahead and removed the copper block and saw that the noise improved significantly.
Picture one shows the noise taken over the weekend with copper block on the laser (with capacitive damping on) [ref], and the noise during the day right after the block was removed (with capacitive damping on).
When removing the copper we noticed it was pretty cool to the touch, so it probably wasn't providing much thermal regulation to begin with (i.e. the TEC is doing it's job). Our best guess for why it was worsening the noise is that having some extra weight on the laser was adding some extra stress onto it which was translating to the signal.
Since getting the capacitive damping hooked up, we've been keeping the gain at 100, which seems to damp down the CRS at a reasonable rate without putting to much voltage on it, and we decrease the gain to 50 once the CRS is relatively damped down.
We've been having some confusion in the control room this morning on the IFO alignment as we've been struggling to lock PRMI despite running the usual initial alignment steps successfully and with it having been locked last week. While trending things from last week to see what may have changed, Louis discovered that around 05:45 local time last Monday morning (August 10th), the alignments for the IMs changed notably according to their OSEM readbacks. This lines up with an earthquake that came through at that same time, which tripped the ISI platforms in HAMs 1-5 (noted in the operator shift start alog). It's been seen in the past that a HAM2 ISI trip has caused the IMs to move, so unfortunately this isn't surprising. Also unfortunately, the alignments for the IMs were not restored, so the alignment work that took place later that day to prepare for the peek down the X-arm (alogs 91463 and 91470) would have been done with the assumption the input IFO pointing was good, while in reality it was not.
I have restored the alignments of IMs 1-3 according to their OSEM readbacks before the ISI trip, and Louis confirmed the alignment to the IM4 TRANS and ISS secondloop PDs are good. We will continue to recover alignment in the corner to work towards DRMI locking again.
JAC length dither line at 809Hz is on. I also editted the Guardian so that he won't disable it.
It will keep engaged for a couple of days.
TITLE: 08/17 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: 5mph Gusts, 3mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: With all chambers now closed and pumpdown ongoing, the focus this week will be continuing corner alignment and improving DRMI locking. The IMC is locked at 2W and the LVEA is Laser SAFE.
(Travis, Gerardo)
The ion pump for HAM1 was incorporated to the HAM volume yesterday, and today the SS-500 pump cart was isolated from the chamber (turbo pump and SS-500 remain on), and as expected the pressure went up and now we are waiting for the ion pump to take over and maintain the vacuum pressure for HAM1. We will be monitoring the progress of the ion pump.
(Travis, Gerardo)
We stopped pumping against the isolation valve for HAM1 turbo, now the turbo needs to spin down before we can disconect the cable from the magnetically levitated turbo pump. The flex hose was removed and the scroll pump was stopped, but needs to remain on until the turbo stops spinning.
(Travis, Gerardo)
We removed the old gauge a BCG-450 and installed a new one a BPG-552. Since the gauge at this location does not play role with relays and such, the old pigtail did just fine, provided the power to the new gauge. The new gauge is powered on and connected to the same EtherCAT cable as the one that that we removed. Dead volume of this assembly is getting pumped down with a small can turbo pump and an aux-cart, and a very long flex hose, and probably will continue to pump over the weekend.
No issues were encountered while replacing the gauge.
(Travis, Gerardo)
Aux-cart and all other accessories have been removed from this gauge.
We need to leak check the conflat on this new gauge.
Jennie W,
Since Daniel put in a TEC controller for the JAC temperature servo we will no longer use the current version of the guardian control loop so I have set JAC_HEATER guardian to SERVO_OFF. The TEC is turned on and the set point is at 25.4 Degrees C.
The servo controller can be reached by going to sitemap->IOO->JAC Overview->Controller. To turn it off select the 'OFF' button in the top right corner of the controller. The loop can be measured by using the excitation button noted in the picture.
I will trial this over the weekend so I can double check it doesn't drive the JAC away from the control point.
I'm running a script called inject_TEC.py which does a swept sine from 0.01 to 100 Hz on the TEC heater servo. This has an amplitude of 0.001V so shouldn't have a big effect on the temperature.
See photo for the control signal, JAC heater drive voltage and the error point.
It will take this voltage away from the DAC output votlage used to drive the JAC heater and so shouldn't disrupt the temperature control of the JAC so it will stay locked.
The current measurement takes 31 minutes and I started it at 04:24:37 UTC.
It stopped at 04:56:03 UTC.
I will leave the JAC Heater servo running as it was working servoing the temperature to 25.4 degrees C all weekend (apart from a brief period when Masayuki unlocked for calibration measurements earlier today.
Camilla, Oli, Caroline, Masayuki, Sheila
During this realignment, SR3 was moved 65urad in Pitch, see attached.
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:
The M2 stage of the BS has been moving a lot since yesterday afternoon ~21:17 UTC, the oplev damping has grown with it.
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.
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.
This was messing us up again today. I commented out the BS Oplev DAMP lines in the ISC_DRMI DOWN state.