TITLE: 06/05 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
Just put the IFO in DOWN for the night after losing lock from ENGAGE_ASC_FOR_FULL_IFO. I was having trouble all evening getting DRMI to stay locked - we kept losing lock from the 16.2 Hz oscillation that Craig and Elenna had found yesterday (84769). I have no idea why it's only been appearing in the evenings - yesterday evening we had these issues, then this morning no issues at all, and then this evening issues again!! I would lose lock from it anytime after ENGAGE_DRMI_ASC, but even just in DRMI_LOCKED_PREP_ASC, the oscillation was there, just not ringing up.
One of the times I was able to get DRMI to lock, I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements. Later on, Sheila called and figured out it must be due to the MICH gain being too high, so I lowered MICH2 gain, originally at 1, by 30% to 0.7. After doing that, the 16 Hz oscillation went away (diaggui) and we were able to get through DRMI. Sheila said we probably needed that gain back to 1 for DRMI_TO_POP, so I paused at RESONANCE, reset the MICH2 gain to 1, and then continued. We lost lock during ENGAGE_ASC_FOR_FULL_IFO.
So the MICH2 gain is currently at its original gain of 1.
Evening task progress for today:
LOG:
23:30 Sitting in NOMINAL_LOW_NOISE while tests are being run
00:32 Started BB calibration measurement
00:37 BB measurement done
00:38 Lockloss due to earthquake
- started a manual initial alignment
- tried to leave SCAN_ALIGNMENT for UNLOCKED and got a Guardian node error about the time being in the past - had to manual before reloading to get out of it (txt)
- After the initial alignment was done, I relocked SRY and left it there for a while while Vicky and Kevin worked on SQZ stuff
02:24 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation (84769)
02:37 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
- I paused in DRMI_LOCKED_PREP_ASC and adjusted SRM to make POP look better, then went into ENGAGED_DRMI_ASC. We had an oscillatoni start, but we were able to survive it. Then I went into TURN_ON_BS_STAGE2 and we immediately lost lock
03:24 Lockloss from ACQUIRE_DRMI_1F while trying to acquire. We had gotten it earlier and I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements, but we lost DRMI when I aborted the SRCL measurement and we weren't able to grab it again
03:40 Lockloss from ACQUIRE_DRMI_1F
- Ran another initial alignment
04:20 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
04:31 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation
- Sheila called, I lowered MICH2 gain (originally at 1) by 30% to 0.7, then the 16 Hz oscillation went away and we were able to get through DRMI
- Paused at RESONANCE, reset the MICH2 gain to 1, and then continued
04:58 Lockloss from ENGAGE_ASC_FOR_FULL_IFO
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
00:44 | VAC | Gerardo | LVEA | YES | Moving a ladder by HAM4 | 01:21 |
I forgot to actually attach the text file for the ALS_XARM error I got last night, so here it is
After losing lock earlier due to an earthquake, we went through an initial alignment. After that had finished, I put the ifo back into SRY so that they could calibrate the ADF. They finished that a bit ago, and after touching up SRC1 and rerunning the SRC alignment, we are now starting to relock.
I was only able to take the broadband measurement due to an earthquake that knocked us out of lock a minute later. We had been at full power for around 5 hours at the time this measurement was run. Unfortunately since we weren't able to take the Simulines measurements, I am not able to run the report.
Broadband:
Start time: 1433118749 (2025-06-05 00:32:11 UTC)
End time: 1433093874 (2025-06-05 00:37:36 UTC)
Data found in: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250605T003226Z.xml
M. Todd, C. Cahillane, G. Mansell
We're curious if any of the IMC WFS channels (DC and RF) are seeing some of the peaks we witness in DARM. Most of the sensors seem dominated by phase noise due to being in air; IMC-TRANS seems the best witness. Not sure if there is anything meaningfull from these, indicating coherence with the DARM peaks.
List of Figures: references are from March 12th, 2025 -- lives are from June 4th, 2025
1. IMC REFL and TRANS PSD estimate comparison before (March 12, 2025) and after vent (June 4, 2025)
2. IMC WFS A/B DC/RF-I PITCH
3. IMC WFS A/B DC/RF-I YAW
The template to measure these again is found at /ligo/home/matthewrichard.todd/Templates/imc/imc_wfs_comparison.xml
It seems like the summary of this is "input beam jitter was never good, but is worse now than in March 2025", especially at 500 Hz in IMC_REFL and IMC_WFS_DC.
I ran an iterative tuning of the LSC feedforward today. The feedforward was already decent, but there was some room for improvement. The two attached screenshots compare injections from the new feedforward fit and the old fit. The only place to pay attention to moving forward is the high frequency coupling of SRCL, which may be effected by the large SRCL offset measured (and potentially corrected) today. If we see any >100 Hz noise coupling from the LSC, maybe we can do another iterative fit. I also injected in PRCL and the noise coupling has not changed, so the previous feedforward is just fine.
The new filters are in FM7 for both MICHFF and SRCLFF, and I updated the guardian.
Vicky, Sheila, Kevin, Camilla
Increased NLG (needed to adjust SHG waveplate) by taking OPO trans setpoint from 95uW up to 120uW. Measured NLG = 49 (numbers below) following 76542.
Data attached and saved at /ligo/home/camilla.compton/Documents/sqz/templates/dtt/20250607_SRCdetuning.xml
Type | Time (UTC) | SRCL | Angle | DTT Ref |
No SQZ | 21:37:00 - 21:43:00 | N/A | N/A | ref 0 |
FIS | 22:17:30 - 22:30:30 | -191 | (CLF-) 242 | ref1 |
FIS | 22:35:00 - 22:38:00 | -90 | (CLF+) 120 | ref2 |
FIS | 22:49:30 - 22:52:30 | 0 | (CLF+) 172 | ref3 |
FIS | 23:17:00 - 23:20:00 | -390 | (CLF-) 161 | ref4 |
FIS | 23:45:00 - 23:48:00 | -455 | (CLF-) 143 | ref5 |
FDS | ~ 00:00:30 | -455 | (CLF-) 143 | ref6 |
Note that I left the OPO servo gain at -8, but we have previously left it there (83569) or used -12dB for 120uW OPO trans (83370)
opo_grTrans_ setpoint_uW | Amplified Max | Amplified Min | UnAmp | Dark | NLG (usual) | OPO Gain |
120 | 0.018035 | 0.000119507 | 0.000316548 | -2e-5 | 48.9 | -8 |
Here are the plots of this dataset, showing that our SRCL detuning (in gwinc) would be 50 mrad with no digital offset in the SRCL loop. Kevin tells us that this is a double passed SRCL detuning, so it's really 25 mrad, 1.4 degrees of SRCL detuning.
Edited to add the last point (and have the correct plots).
TITLE: 06/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
IFO is in NLN_CAL_MEAS and PLANNED ENGINEERING
Extremely productive day in which we got to Nominal Low Noise for the first time in two months!
Very briefly, here's what we did today:
Relevant alogs:
alog 84800: low range coherence checks
alog 84798: a2l optimized pre-NLN
alog 84796: IM4 and MC2 TRANS
There are undoubtedly more in-progress alogs about work done today.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:30 | LASER | LASER HAZARD | LVEA | LASER HAZARD | LVEA IS LASER HAZARD (\u2310\u25a0_\u25a0) | 07:26 |
14:39 | FAC | Herc Lift Lift | MX | N | Lifting a lift | 15:05 |
17:11 | FAC | Randy | MX | N | Inventory | 20:10 |
17:29 | VAC | Travis | MY | N | Checking storage space | 17:44 |
20:54 | AOS | Jeff, Jordan | Optics Lab | Local | SPI Collimator | 21:06 |
20:55 | VAC | Travis | MY | N | Inventory | 20:55 |
TITLE: 06/04 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 19mph Gusts, 10mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.14 μm/s
QUICK SUMMARY:
Currently we are sitting in NOMINAL_LOW_NOISE and people are working on measuring and updating various things.
Ibrahim
Ran a low range coherence check to better understand H1 range and its effects right before NLN. Screenshot of result attached.
Camilla, Ibrahim
Ran A2L before NLN to maxmimize range.
We had to run the a2l script a few times for all QUADs. The first two times, there was no change in gain because the required change vin gain was too much for the script to apply (a safety feature I'm sure). Camilla and I then stepped the gain in the right direction until we were sure that it would be within the adjustability of the script. It took two more runs in order to finally get the range maximized. This improved the range by about 20 MPc. Screenshots attached (the screenshot named initial is before manual stepping).
M. Todd, C. Cahillane
We are looking at the RIN in LSC-REFL_A to try and understand if there are some cavity dynamics that can give an estimate of the power recycling cavity mode-matching to the arms (for some more background, see Daniel's alog 70985)
I've made a plot that shows some interesting changes in the REFL_RIN asd as a function of thermal state. In particular I've looked at the asd at 4 different times as we thermalize after locking and stabilize the ISS.
There's some very interesting dynamics around 5-50 Hz. For the HF dynamics, I've also plotted the shot-noise limit based on that time's DC REFL_A_LF power; which I think is the limit in that frequency regime.
I've put both the dtt plot as well as my own plot that used quick_psd.
Next, I would like to model what RIN we would expect in that frequency band and compare to these measurements, specifically if this is intensity noise coupling changes due to mode mismatch changes during thermalization.
Looking at IM4 and MC2 trans, we see that the amount of power on MC2_TRANS and IM4_TRANS has decreased by around 1%. The plot shows a time in March 12, 2025, with white dashed lines where those values are now on June 04, 2025. The IM4_TRANS calibration was fixed after the HAM1 work in alog 82260. The PRG is around 3% higher now, going from 52.2 to 53.9. The PRG calculation already incorporates this apparent 1% fall in IM4_TRANS. Matt Todd checked the PRG at 2W in alog 84668. As far as alignment, MC2_TRANS is servoed to zero by the input PZT using IMC ASC DOF3, so that is "unchanged". IM4_TRANS has drifted only a small amount, from 0.1 to 0.2 in PITCH, and -0.04 to -0.10 in YAW. This is all loosely consistent with the small changes in input pointing we've seen in the ISS array pointing seen in alog 84728. Keita noticed that the SEG3 on the ISS QPD is totally saturated at -32768 cts due to the misalignment onto that PD, so it becomes even harder to trust the ISS QPD reference. We have not yet closed the ISS secondloop as a part of the locking sequence, so we don't know if the beam jitter coupling to DARM problem will get worse when we close this loop. I reckon there is a very high likelihood that it will. Keita had more suggestions, including 1) injecting into the IMC and checking coherence between IMC WFS and the ISS array and DARM (Mr. Todd has already started this analysis alog 84775). 2) moving the input pointing into the array in PITCH and YAW and checking the PHASE between each individual array diode, maybe via line injection, to see if there is any cancellation happening, or if some diodes are more susceptible to misalignments 3) far future: change around plugs for INNER and OUTER so that the INNER diodes are the most stable, best-aligned ones. This could improve our overall beam jitter coupling, if we think it's coupling via the intensity loop.
Trending back to a recent 2W lock, our PRG is a bit too high, nearing 60 when Matt has recently measured it to be 55.6. I added a gain correction factor to the PRG bank of 0.93 to account for this, in FM4. This makes our current 60 W locked PRG about 50!
I checked out the individual diodes on the array to see if they have different responses to beam jitter. It seems like Keita's intuition was correct. ISS array PDs 2, 3, 5, and 7 have significantly higher intensity noise at 3.5 Hz, 2.0 Hz, 1.1 Hz, and 0.15 Hz. These frequencies correspond to some HSTS suspension resonances for YAW in particular. Most likely is we are clipping somewhere on the path to the ISS array for only a few of these diodes. There is also some improvement in the diode noise at around 330 Hz, 380 Hz, and 960 Hz. PDs 1, 4, 6, and 8 are better performing. Out of those, we still see some beam jitter, just significantly reduced. PDs 1, 4, 6, and 8 are better for both low and high frequency motion, which is consistent with clipping. Jennie Wright will post a picture of the ISS array itself, but she believes the diodes are arrayed like5 6 7 8 - - 1 2 3 4 - -
when looking from the back of the array where the cables are coming out. The underlined diodes are the "bad" diodes. Seems to not be totally sensible as an overall DC YAW adjustment, which is consistent with our attempts to align onto this array. To reproduce this PSD plot, runquick_psd H1:PSL-ISS_SECONDLOOP_PD?_OUT_DQ -t1 1433112446 -d 3600 -b 0.01
on a CDS machine.
WP12583
At 15:54 Tue 03jun2025 PDT the EX HWWD showed activity. This was repeated later in the day between 18:40 - 19:10. This could mean I don't need to go to EX to perform a cable-out test.
Attached 10 week trend shows when the various HWWDs went quiet and later resumed activity.
TJ, Dave:
The ADJUST_POWER state of the ISC_LOCK guardian node has been exercised recently during locking, with the unexpected consequence of various CDS system mis-interpreting this as entering/leaving nominal-low-noise. This is because this state's number is 1000, greater than NLN=600. For example, attachment shows CDS overview screen mistakingly showing models' SDF diffs in RED. Yesterday TJ reduced this state's number to 521, a number which wasn't available when this state was first created but has since become available (graph snippet shown).
Wed Jun 04 10:10:09 2025 INFO: Fill completed in 10min 5secs
Gerardo confirmed a good fill curbside.
Oli, Georgia, Elenna
While we were taking care of several LSC items, Georgia pointed out that we are seeing the 0.8 Hz buzzing in INP1 yaw again, and to a lesser degree CHARD Y. While we did several useless things to debug, I noticed that the DC centering loops were also buzzing with the same frequency oscillation. I decided to try changing the DC centering loop gain (since I had raised the loop gain significantly last week), and noticed that NONE of the DC6 pitch or yaw filters were engaged, but a gain of 1 was engaged, essentially feeding the input signal right back to PM1. Bad!!
Searchingh DC6 in the guardian shows that in PREP_ASC_FOR_FULL_IFO, I found these lines of code:
ezca.get_LIGOFilter('ASC-DC6_P').only_on('INPUT','OUTPUT','DECIMATION')
ezca.get_LIGOFilter('ASC-DC6_Y').only_on('INPUT','OUTPUT','DECIMATION')
Not good! Since the gain of DC6 is set on, this effectively keeps the gain on but turns off all the filters and just feeds back the pure error signal to the suspension.
I commented those lines out of the guardian and loaded, and then reengaged all the proper filters. A large 28 Hz line that had been present in DARM disappeared at this point, likely because the DC centering loops require a 28 Hz notch to avoid some suspension mode.
After this, I then tried turning down the DC1 and DC2 pitch and yaw gains to -1. This seemed to help the buzzing in CHARD and INP1. Georgia and I were able to engage all the low noise ASC settings without any issues (CHARD P had been held in high bandwidth to avoid a ring up and the soft loops had high gain for the same reason).
We need to monitor for a while longer and also try relocking, but these changes may fix many of our ASC issues.
I have SDFed these gain changes.
While locking this arvo, we stepped through lownoise_asc slowly by hand trying to catch which step was causing the 1Hz ring up that caused locklosses yesterday.
One time we reduced the DSOFT_Y gain down, thought we saw something ring up, but when we gradually decreased it the ring up did not come back.
The CHARD_P filter and gain changes in this state seemed to cause some oscillations in the PRG, so we left CHARD_P in a high noise state for a while. This left a lot of noise in DARM (first screenshot). We later ran the lownoise_asc steps for CHARD_P, after Craig and pals phased the LSC-POP diode, and this seemed to fine (second screenshot).
Hopefully the reduced gain in DC1 and 2 and the existance of filters in the DC6 loops will improve the ASC. But if we still see ringups in lownoise_asc the next best thing to try is undoing the steps for CHARD_P.
We now have confirmation that the DC centering loops have been having a significant effect on the ASC and causing many of our problems.
The DC loops appeared to have a large amount of gain peaking at low power around 0.8 Hz (I turned up the gain too high and didn't check the gain peaking). After we powered up I measured CHARD Y, which is a loop whose gain we have not been able to raise until reaching high power during the past few days. Attached is a comparison of the CHARD Y OLG both with the DC centering loop gain high and low (cut by half).
We were able to turn up and turn down the DC centering gain to confirm that it is causing the right half plane zero in CHARD Y. We only measured CHARD Y so we don't know the effect on other loops, but it appears that other loops are also more stable with less gain in the DC centering.
I have turned up the CHARD Y gain at engage ASC with no problems, this is now saved in the guardian.
M. Todd, C. Cahillane, S. Dwyer
I ran another estimate of the PRG, following Craig's method in alog 58327, and estimate it to be around 54.2 W/W.
I compared the TRX power to Input Power ratio during the FIND_IR state versus the PREP_ASC_FOR_FULL_IFO state, with the PRM transmission as a normalization factor.
TRX_POWER_FULL_IFO / INPUT_POWER_FULL_IFO
PRG = -------------------------------------------------------------------------------------
TRX_POWER_FIND_IR / (Tp * INPUT_POWER_FIND_IR)
I've attached the quick script I've used for the interesed reader.
I reran this measurement during DARM_TO_DC_READOUT (GRD-ISC = 501, input power = 2W), comparing the input and TR-X powers during the previous FIND_IR state (GRD-ISC = 16, input power = 2W). And I got a post vent PRG of 55.6 W/W. (post-vent)
I reran this estimate for the same states, before the vent (FIND_IR = 1427488687, DARM_TO_DC_READOUT =1427490018) and got a PRG of 55.7 W/W. (pre-vent)
It's interesting that we estimate almost the exact same PRG pre and post vent, though we may be able to improve this post vent value (probably not drastically) with some ASC improvements. We wanted to get this estimate to just check that everything is in general order in HAM1 after the vent.
I think our PRG channel calibration needs updating. Matt's measurement agrees with mine: that the PRG is about 54 when we are at 2 W of power. However, at 2 W it is currently reading 60, which is wrong, possibly due to slightly less power on IM4 trans. I will add a correction factor in FM4 of our "LSC_PR_GAIN" bank, 55.6/59.8 = 0.93.
I checked what the PRG was according to the calibration channel H1:LSC-PR_GAIN_OUT16 during the same time that I used for my measurement of the post-vent PRG (1432694134) and it is off by roughly a factor of 8%.
The calibration channel reports a PRG of roughly 59.9; I've measured it to be 55.5. We may benefit from some re-calibration.