H1 back to observing at 21:18 UTC following commissioning time. Were getting some DIAG_MAIN notifications after going to max power about the POP X PZT being railed; Sheila says we should fix this but can wait for now. The TMS_SERVO Guardian has a note about this being due to different PR3 alignment.
Accepted new POP_A offsets of 0 in ASC OBSERVE.snap table once at NLN (screenshot attached).
J. Freed
ETMX shows strong coupling of BOSEM noise between 10-20Hz by about a factor of 30 below DARM from most sensors.
Today I did damping loop injections on all 6 BOSEMs on the ETMX M0. This is a continuation of the work done previously for ITMX, ITMY, PR2, PR3, PRM, SR2, SR3, and SRM. As with PRM, gains of 300 and 600 were collected for SR3 (300 is labled as ln or L). Calibration lines were off.
Sheila, Matt T, Mayank, Jennie W
tl;dr: After previous PR2 moves last week, we measured the spot clipping on scraper baffle (and exiting HAM3 viewport) to be 8mW in lock. After measuring this we unlocked for unknown reason and so team PR2 moved 6mm towards the centre of PR2 in yaw while unlocked. We estimate we are roughly centred on PR2 now.
Today Sheila and I measured the spot coming out of the HAM3 viewport as was done by Robert in this entry. The process is replace the black glass guillotine with lexan guillotine, take off the illuminator, clip a lens on a stalk to the top of the guillotine and align this with the beam coming out of the viewport. Not all the light is now captured by the lens as the spot is now more a semi-circle of a clipped beam. We moved the power metre behind the lens till we found the max power we could get on the power metre. This was 8mW and the PR3 yaw slider was at around -74 microradians.
After we came back to control room the IFO lost lock so it was decided to move towards the centre of PR2 which had been measured by Sheila using an A2L measurement at the start of the commissioning period.
Matt tuned down on PR3 yaw in 3 microradian steps to -232.4 microradians. Each step he tuned the 8X picomotor to bring back the DIFF and COMM ALS beatnotes. Every so often it is also neccessary to step up the pitch on PR3 to compensate for the cross-coupling of yaw to pitch. The ndscope image for the moves is here. Matt left the picomotor like this and the sliders like this.
Before today's move PR3 yaw slider was at -74, where we measured the Y2L coefficent to be -3, which corresponds to 6 mm.
We moved using the procedure in 82670, and we decided to move to -230urad on the PR3 yaw slider based on the table in 82688.
We did go to ISCT1 ad fix up the beatnotes, and TJ stopped at PREP_DC_READOUT where I pico'd to center on the POP QPDs. The centering actually could be better, with POP A well centered POP B is at -0.5 in pitch and -0.1 in yaw at 2W with all ASC on. We can fix this another day, but didn't want to take the time today.
I've set the POP A offsets to 0, accepted this in safe.snap, and added PRC1 and PRC2 in the guardian.
FAMIS 31072
Since our work in the enclosure last week taking pump diode slope measurements (alogs 82636 and 82635), several trends have changes. A majority of the pump diode monitors are at different levels, power out of both amplifiers is higher (AMP2 seems slightly noisier), PMC transmitted power is higher, PMC reflected power is lower and has not been increasing since last week. This is the first time I can recall it not having a steady increase since immediately after the last NPRO swap late last year.
Mon Feb 10 10:18:24 2025 INFO: Fill completed in 18min 21secs
Gerardo confirmed a good fill curbside. TCmins [-38C, -37C] OAT (-3C, 26F) DeltaTempTime 10:18:24
The lock loss occurred during commissioning time but no activity was going on at the time.
TITLE: 02/10 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 11mph Gusts, 6mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.32 μm/s
QUICK SUMMARY: Recent lock loss, IFO just finished up an initial alignment. Planned commissioning today from 1630-1930 UTC.
There was a vacstat alarm this morning, attached is the blip it alarmed off of. The height of this peak seems fairly normal when trending back, happening once every few days or so. It also doesn't coincide with a lock loss, we were in low noise during this time.
We had a BSC3 gauge glitch at 00:59:17 which caused the VACSTAT alarm. I have restarted the service to clear it.
TITLE: 02/10 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: After relocking we stayed locked the whole shift. 6 hours as of 06:00UTC, the range has been fairly stead just under 160 Mpc.
LOG: No log
00:00 UTC Observing
00:55 - 01:35 UTC We survived some earthquakes, 5.9, 5.4, 4.9 from the Soloman islands area
TITLE: 02/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 4mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.22 μm/s
QUICK SUMMARY:
TITLE: 02/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Start of shift the IFO was relocking, it made it up without issues. It held for a 6 hour lock, then another lock loss recently. Each reacquisition has needed an initial alignment.
LOG:
The quad L2 outs seem to see it first?
00:00 UTC Observing
Sun Feb 09 10:07:09 2025 INFO: Fill completed in 7min 5secs
TC temps were high, just cleared the -30C trip. TCmins [-36C, -34C] OAT (-1C, 29F) DeltaTempTime 10:07:08
When verbals announced an earthquake I checked the SEI screen the earthquake was listed as an 8.0 Mag!
I then quickly checked USGS and they also had listed it as an 8.0 Mag but it seems like it has since been demoted to a 7.6?
https://earthquake.usgs.gov/earthquakes/eventpage/us7000pcdl/executive
When it struck all the ISI's trip before verbals could finish announcing the earthquake.
I immidiately called Jim and ask him if I should hit the very large Earthquake button, but he said if things were already tripped then it doesn't really matter.
Attached are monthly TCS trends for CO2 and HWS lasers. (FAMIS link)
Sheila and I are continuing to check various PD calibrations (82260). Today we checked the POP A LF calibration.
Currently there is a filter labeled "to_uW" that is a gain of 4.015. After some searching, Sheila tracked this to an alog by Kiwamu, 13905, with [cnts/W] = 0.76 [A/W] x 200 [Ohm] x 216 / 40 [cnts/V]. Invert this number and multiply by 1e6 to get uW/ct.
Trusting our recalibration of IM4 trans, we have 56.6 W incident on PRM. We trust our PRG is about 50 at this time, so 2.83 kW are in the PRC. PR2 transmission is 229 ppm (see galaxy optics page). Then, the HAM1 splitter is 5.4% to POP (see logs like 63523, 63625). So we expect 34 mW on POP. At this time, there was about 30.5 mW measured on POP according to Kiwamu's calibration.
I have added another filter to the POP_A_LF bank called "to_W_PRC", that should calibrate the readout of this PD to Watts of power in the PRC.
POP_A_LF = T_PR2 * T_M12 * PRC_W, and T_PR2 is 229 ppm and T_M12 is 0.054. I also added a gain of 1e-6 since FM10 calibrates to uW of power on the PD.
Both FM9 (to_W_PRC) and FM10 (to_uW) should be engaged so that POP_A_LF_OUT reads out the power in the PRC.
I loaded the filter but did not engage it.
More thoughts about these calibrations!
I trended back to last Wednesday to get more exact numbers.
input power = 56.8 W
PRG = 51.3
POP A LF (Kiwamu calibration) = 30.7 mW
predicted POP A LF = 0.054 * 229 ppm * 56.8 W * 51.3 W/W = 36 mW
ratio = 30.7 mW / 36 mW = 0.852
If the above calibrations of PRG and input power are correct, we are missing about 15% of the power on POP.
During commisioning this morning, we added the final part of the ESD glitch limiting, by adding the actual limit part to ISC_LOCK. I added a limit value of 524188 to ETMX_L3_ESD_UR/UL/LL/LR filter banks, which are the upstream part of the 28 bit dac configuration for SUS ETMX. These limits are engaged in LOWNOISE_ESD_ETMX, but turned off again in PREP_FOR_LOCKING.
In LOWNOISE_ESD_ETMX I added:
log('turning on esd limits to reduce ETMX glitches')
for limits in ['UL','UR','LL','LR']:
ezca.get_LIGOFilter('SUS-ETMX_L3_ESD_%s'%limits).switch_on('LIMIT')
So if we start losing lock at this step, these lines could be commented out. The limit turn-off in PREP_FOR_LOCKING is probably benign.
Diffs have been accepted in sdf.
I think the only way to tell if this is working is to wait and see if we have fewer ETMX glitch locklosses, or if we start riding through glitches that has caused locklosses in the past.
Using the lockloss tool, we've had 115 Observe locklosses since Dec 01, 23 of those were also tagged ETM glitch, which is around 20%.
Since Feb 4th, we've had 13 locklosses from Observing, 6 of these tagged ETM_GLITCH: 02/10, 02/09, 02/09, 02/08, 02/08, 02/06.
Jim, Sheila, Oli, TJ
We are thinking about how to evaluate this change. In the meantime we made a comparison similar to Camilla's: In the 7 days since this change, we've had 13 locklosses from observing, with 7 tagged by the lockloss tool as ETM glitch (and more than that identified by operators), compare to 7 days before the change we had 19 observe locklosses of which 3 had the tag.
We will leave the change in for another week at least to get more data of what it's impact is.
I forgot to post this at the time, we took the limit turn on out of the guardian on Feb 12, with the last lock ending at 14:30 PST, so locks since that date have had the filters engaged, but since they multiply to 1, they shouldn't have an effect without the limit. We ran this scheme between Feb 3 17:40 utc until Feb 12 22:15 utc.
Camilla asked about turning this back on, I think we should do that. All that needs to be done is uncommenting out the lines (currently 5462-5464 in ISC_LOCK.py):
#log('turning on esd limits to reduce ETMX glitches')
#for limits in ['UL','UR','LL','LR']:
# ezca.get_LIGOFilter('SUS-ETMX_L3_ESD_%s'%limits).switch_on('LIMIT')
The turn off of the limit is still in one of the very early states is ISC_LOCK, so nothing beyond accepting new sdfs should be needed.