david.barker@LIGO.ORG - posted 10:21, Saturday 20 May 2023 (69770)
Sat CP1 Fill
Sat May 20 10:08:21 2023 INFO: Fill completed in 8min 20secs
Images attached to this report
Sat May 20 10:08:21 2023 INFO: Fill completed in 8min 20secs
TITLE: 05/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: H1 is relocking, currently at ENGAGE_ASC_FOR_FULL_IFO. Lockloss this morning at 13:45; I'll start looking into the cause.
TITLE: 05/19 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Relocking
SHIFT SUMMARY:
Main Notes:
- The LSC feedforward measurements have been completed and results can be accessed in /ligo/home/elenna.capote/LSCFF on any CR computer - Tagging ISC
- nuc30 has been power cycling for some reason and when it comes back up the displays are mirrored instead of separate displays
- Just finished up recovery and an initial alignment from the EQ and leaving the IFO in the process of relocking (currently at OFFLOAD_DRMI_ASC) with the OBSERVATION bit set to automatic to hopefully go straight into OBSERVING once it acquires NLN
- IFO has been locked for 3:49 and in OBSERVING at the start of my shift
- Some SQZ changes came up that took us out of OBSERVING, talked with SQZ and accepted - ss attached
- EX saturation 0:18/1:05
- 1:44 UTC - I am taking the IFO into COMMISSIONING to run LSC FF tests (permission was granted from Jenne) - finished right before the EQ
- 1:58 - EQ from New Caledonia (same place as yesterday) - 7.1 mag
LOG:
No log for this shift.
Naoki, Vicky
In the recent noise budget in alog68912, the frequency noise seems very close to the measured DARM at high frequency. The frequency noise is 1e-20 m/rtHz at 1 kHz and the measured no sqz DARM is 3.2e-20 m/rtHz at 1 kHz in here. The ratio of the frequency noise and the measured no sqz DARM at 1 kHz is 0.31, which corresponds to the effective loss of (0.31)^2~10% due to the frequency noise.
We calculated the expected squeezing level and the effective total loss as a function of the ratio of the classical noise and the measured no sqz DARM in ASD (attached figure). We assumed that the injection loss is 7%, the readout loss is 20%, and the generated squeezing is 14dB. The phase noise is ignored in the calculation. When the ratio of the classical noise and the measured no sqz DARM is 0.3 as the current noise budget, the expected squeezing level is limited to 4.5dB. If we don't have any classical noise nor other additional loss, we should have ~5.5dB of squeezing. So the classical noise would be one of the main limitation of our squeezing level.
I didn’t get very far in the HVAC experiments because the EY chiller water pumps did not recover from the site-wide shutdown until I went to the chiller pad and reset them. The time lag and hot day meant that I had to wait a few hours for recovery (fortunately I reset it quickly enough that we didnt loose lock). While I was waiting for EY temperature recovery, SF-6 (lab area cold-deck) went off on its own and Richard brought Ken in to work on it - he says one of the wires connected to the breaker was burned through. Ken just got it fixed and we are both headed out.
I did learn a couple of things in the abbreviated experiments:
1) both the chilled water turbulence and the turbine plenum turbulence are contributing to the vibration background at 4 Hz at EX
2) side-wide shutdown of turbines, associated chillers, and water pumps increased the range from about 128 to about 138 Mpc
Since I couldn't complete the experiments, I tried just turning the turbine flows down to pre-pandemic levels. I was unable to do this for the CS and EX HVACs - to me it seemed like vane actuator slippage, like we have seen in the past. EY AHU-1 worked fine for me and I turned the flow down from 12k to 9k CFM as agreed with Bubba. Otherwise I have left everything the same. I did not get a chance to toggle the lead chiller at EX.
EX HVAC experiments all times May 19 UTC:
16:21:51 EX chiller un-enabled, AHU manually disabled
16:32:58 CHWP-2 disable
16:39:38 All systems back on
17:08:36 Manual chiller 2 enabled uncheck, AHU-2 Manual Disable checked
17:11:56 Chiller still on start so uinchecked chiller system enable
17:21:22 checked manual pump disable
17:35:30 system restored: AHU-2 disable unchecked, Chiller system ehable checked
18:43 AHU manual disable checked, Chiller system enable unchecked
~18:55 system restored
Site-wide HVAC off:
20:16:05 start of site off
20:23:32 back on
This plot is a bit out of date, but here is a DARM comparison for the time when the site HVAC was off. The range improvement from this HVAC shutoff that gained us about 10 Mpc appears to be a reduction in noise from 100-200 Hz in DARM. I think that region is mostly limited by jitter noise.
IFO is currently unlocked and in DOWN due to a 7.1 EQ from New Caledonia, with multiple aftershocks rolling in (4 so far).
Late entry, tests were done last Tuesday, May 16th 2023.
A functionality test was done on the corner station turbo pumps The scroll pump was started to take pressure down to low 10^-02 Torr, at which time the turbo pump was started, the system reached low 10^-08 Torr after a few minutes, the turbo pump system was left ON for about 1 hour. After the hour the system went through a shut down sequence, turbo is not spinning and power is turned off. No issues were encountered while performing the functionality test on the 3 turbo pump stations.
Findings below:
Output mode cleaner tube turbo station;
Scroll pump hours: 5554.0
Turbo pump hours: 5598.2
Crash bearing life is at 100%
X beam manifold turbo station;
Scroll pump hours: 776.0
Turbo pump hours: 772.8
Crash bearing life is at 100%
Y beam manifold turbo station;
Scroll pump hours: 1870.9
Turbo pump hours: 590.1
Crash bearing life is at 100%
TITLE: 05/19 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 129Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 10mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY:
- IFO has been locked for 3:42 and has been in OBSERVING since 20:29 UTC
- Double coincidence observing is the priority, but if we cannot, there are some tests that are slated - namely LSC FF tests, SQZ angle changes, and potential CAL suites
TITLE: 05/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 127Mpc
SHIFT SUMMARY:
IFO set to relock prior to my shift; NLN reached @ 15:02 and Observation Intent Bit set to OBSERVE @ 15:27
Lockloss @ 17:31 from PI mode 29 ringup. This is a mode we have not had success damping in the past, but recently has not been an issue. I went to lower the OMC whitening to give it some room, but I was too late.
Upon trying to relock, we discovered the ALS beatnotes were very poor (-16 COMM and -19 DIFF). After a discussion with Sheila and TJ, I ultimately moved PR3 by 1.6 µrad to see improvement in the beatnotes and reran initial alignment. Relocking after this went smoothly; NLN reached @ 19:38, Observing @ 20:02
We dropped Observing for about a minute at 20:28 from the CO2 X laser on ITMX losing lock and having to reacquire using the TCS_ITMX_CO2 guardian, creating SDF diffs. Before I could take a screenshot, the diffs cleared themselves and we were able to return to Observing.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 13:19 | ifo | Jenne | home | n | locking | 15:28 |
| 16:31 | VAC | Janos. Jordan | MY | - | Picking up pump | 17:01 |
| 17:01 | VAC | Janos, Jordan | CP1 | - | Pumping CP1 | 17:42 |
| 17:45 | VAC | Janos, Gerardo | LVEA | - | Untrip breaker | 18:31 |
| 17:45 | PEM | Robert | EX | - | Troubleshoot magnetometer | 18:31 |
| 20:35 | FAC | Randy | EY | - | Pick up tool | 21:09 |
| 21:10 | PEM | Robert | EY | - | Troubleshoot chiller pumps | 21:52 |
I wonder if the 80 kHz ETMX PI lockloss this morning was due to the HVAC testing; we haven't seen an 80 kHz PI lockloss in a while. This time, as the EX VEA temp increased by 0.5degC (w/EY temp constant), the 80 kHz ETMX PI rung up about 2.5 hours into the lock. Maybe the EX HVAC change served as sufficient thermal change to ring up the 80 kHz PI on ETMX? Is it possible we are this marginal on the TCS for ETMX? Elenna has looked at the HOM spacing, and it is noticeably different with the HVAC changes.
In any case, next time I'll try to send the ETMX ESD PI drive to damp the mode in Diff, with LL/UR = 1/-1 (specifically, LL = H1:SUS-ETMX_PI_UPCONV_OUT_MTRX_1_3 = 1, UR = H1:SUS-ETMX_PI_UPCONV_OUT_MTRX_2_3 = -1). I think LLO:64490 has seen that this 80kHz mode is asymmetric, so maybe driving in diff helps. The PI damping guardian tried to damp the 80 kHz PI for 4-5 minutes with a common ESD drive to ETMX (first guardianized late April), but it wasn't able to. I confirmed the PLL integrator was locked to the correct frequency when trying to damp. Not sure if we'll be more successful with differential ESD driving, but we'll try.
To clarify, there was no TCS tuning, just in case anyone is wondering why we were doing that (we weren't). There were thermal changes due to HVAC-off tests (which were done today, and have been done in the past, in Observing since they are guaranteed to only improve the data quality). But those thermal changes were not related to our Thermal Compensation System.
EDIT: This comment was in reply to a previous version of this log post that referred to the TCS. The top alog post has been corrected, so please disregard :)
When IFO was down from an earthquake, I changed it to differential ESD driving as stated above and saved the change to SDF.
Evan Goetz noticed that there is a mismatch between the Pcal injected frequency and "matching" demodulator for PCALY line 4. This line at 24.5 Hz is in place for temporary monitoring of the thermalization effects on calibration, eg, alog 69478. I don't think that this is detrimentally affecting our calibration at this time, so I'm not going to call Jeff while he's on vacation. He can take a look Monday morning to make it more clear which frequency is supposed to be where.
Ya, unfortunately, because the PCAL oscillator numbers and DEMOD oscillator numbers within their name are defined by front-end code, then you have to do some nasty MEDM trickery that results in this confusing display. In short -- the DEMOD can demodulate any arbitrary frequency, and as long as the *local* oscillator within the DEMOD matches the real signal, then you'll get a sensible answer. In this case, we're using the PCALY LINE4 demod to demod the 24.5 Hz line that's driven by awg with the CAL_AWG_LINES gaudian, so there *is* no end station OSC frequency we can display on this user interface. So, the former mapping of the PCALY LINE4 DEMOD to the PCALY OSC FREQ still shown on the screen (which drives the 2084.01 Hz line), but is meaningless.
Same goes for the PCALXY comparison line display that's shown in the background.
Jenne concluded the right thing -- that this does not impact the output of the calibrated data:
(a) The front-end demodulation of the systematic error pipeline is NOT the primary monitor (produced by GDS)
(b) the 24.5 Hz line is temporary, and (hopefully) will be turned off once the run starts
(c) the PCALXY comparison is, this far, just a monitor and not used to correct any live data.
In the fullness of time this user interface will be cleaned up, but in the mad scramble to make sense of all of these new features some things have been sloppy and confusing. I promise those commissioning the systems are aware of this sloppiness and successfully dancing around it for the time being.
I've committed the local changes to the MEDM screen that resolve this confusion. See
/opt/rtcds/userapps/release/cal/common/medm
CAL_CS_PCAL_COMPARISON.adl
as of rev 26174.
HOWEVER -- we should really modify this screen to use a local-to-each-IFO macro file, since the oscillator number used to drive these PCAL lines (and any PCAL line) is pretty arbitrary, and not, in general, synchronized between sites.
IFO has just reached NLN again @ 19:38 following a lockloss from PI mode 29 ringing up and a move of PR3 to fix ALS beatnotes. Currently waiting for ADS to converge, then I'll flip the intent bit to OBSERVE to get double IFO coincidence with LLO.
Fri May 19 10:08:53 2023 INFO: Fill completed in 8min 52secs
Gerardo confirmed a good fill curbside.
TITLE: 05/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: IFO has just relocked; NLN @ 15:02 following initial alignment earlier this morning.
No problems with green initial alignment, after I touched the optics' sliders to get good flashes.
I was a little unsure about how low the ALS beatnotes are, and it looks like PR3 may have drifted in yaw a teeeny bit according to SUS-PR3_M1_DAMP_Y_INMON over the last few days (well, 0.2 urad which isn't so tiny for PR3), and the green cameras look more clipped than normal (although they were also like that yesterday). So, I did the thing that we "never" do, and touched PR3's yaw slider. It didn't have any obvious beneficial effect, so I immediately put it back.
The rest of initial alignment seems to have gone well while I stepped away. Starting to relock now.
During this round of OMC locking, the pzt scans were getting two sets of our sideband, carrier, sideband "tridents". The current code didn't know how to handle it when it found more than one good place to go. We had a lockloss before I was able to make some smart code, but I quickly threw in a bandaid solution to just choose the second set. This is currenlty running, but I have smarter code ready and tested outside of Guardian that I can load and try on the next lock loss.
OMC locking not going so well. I have stopped ISC_LOCK at PREP_DC_READOUT_TRANSITION.
I set OMC_LOCK to DOWN, changed the ramp time on OMC-PZT2 to 0, then manually found the carrier. I manual-ed OMC_LOCK to OMC_LSC_ON, then requested READY_W_NO_WHITENING. Once it was there, I set ISC_LOCK back to requesting NomLowNoise.
When we achieved low noise, I had to REVERT the OMC-ASC_MASTERGAIN in SDF as Jenne had taken the OMC_LOCK guardian to manual mode and skipped the steps for the automated OMC scan and carrier search. Screenshot attached of the reversion.
