Naoki, Vicky - we've walked through and cleaned up the area around the squeezer tables SQZT0+7 and racks and removed dangling unused cables. There were some viewport covers under SQZT7, which we've now put back to the racks at the LVEA entrance, in bottom right corner of this photo.
The ~1.6611 Hz comb visible in H1 data for some the last few months seems to have disappeared on May 19. This is obviously good news. However, note that it has disappeared in the past only to reappear later, and we still don't know its cause. (See alog 68261) We now have two clearly observed change points (on March 18, and off May 19) and one approximate change point (between Feb 8 and Feb 17th).
May 18 spectrum (first attached image, 1.66 Hz comb in yellow triangles)
May 19 spectrum (second attached image)
State of H1: Observing at 128Mpc
After troubleshooting DRMI alignment and ASC issues, H1 has been locked for 1.5 hours and Observing for 1 hour.
Mon May 22 10:06:56 2023 INFO: Fill completed in 6min 55secs
Travis confirmed a good fill via camera.
TITLE: 05/22 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: 21mph Gusts, 17mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: H1 was locked for ~2.5 hours this morning following an initial alignment. Locking since then has been a struggle with wind gusts up to 30mph, but I'll see what I can do.
Gabriele and I have fit some new filters for the LSC feedforward based on measurements taken recently in a thermalized interferometer. These fits look reasonable and we think they are ready for testing. I am hesitant to put them in the guardian because the last time we tried this we made the noise worse and also caused a lockloss because of some unexpected high frequency behavior. We don't think that will happen again, but I want to be able to supervise the test.
If someone enterprising wants to check it out, the new filters are FM9 of the MICH FF and SRCL FF bank. They should be engaged with a gain of 1. It would be nice to see how they perform at the start of the lock and after thermalization.
Corey tried out these new filters at the start of a recent lock. I ahve attached a set of plots made by Evan. It appears the noise in DARM from 10-40 Hz is worse, while there is some improvement 60-100 Hz. The improvement seems to come from the slight reduction in SRCL coherence. My understanding is that the reference traces are the old feedforward, while the live traces are the new feedforward.
The injections we used to fit the feedforward were done after 6 hours of lock, once the thermalization has settled. This could be why the feedforward seems to be worse early on. I'd like to see this feedforward tried one more time later on, maybe around hour 6 if possible. If the feedforward still worsens the noise, there is some other coupling present that we do not understand.
One more note: comparing the new SRCL FF fit to the current settings, it appears the biggest change is the gain. We could maintain the same SRCL FF filter, but try adjusting the overall gain by a small amount and see if that improves the subtraction.
Concerning the evolution of MICH coupling during thermalization. This plot looks at a 7 hour long lock some days ago, with the old FF filters. I used NonSENS to estimate the optimal TF to subtract MICH on top of the running LSC FF. So this measures the residual MICH coupling to DARM after the reduction due to the FF. It's clear that the residual coupling gets lower with thermalization: this is expected since those FF were tuned with a hot thermalized IFO.
The bottom line is that we cannot have a MICH FF filter that works both for the cold and hot IFO. The same is true for a NonSENS online subtraction
I tried a bit to poke the PRM to convince it to do better with PRMI, but it seems that things are off enough (even after having watched guardian do MICH_FRINGES when I hand-selected MICH) that PRMI ASC can't do enough. So, I've requested initial alignment.
Initial alignment went smoothly, with no interventions.
It seems like the bottom scope on the front wall center TV is frozen. Daytime operator, please restart it.
Requested NomLowNoise. DRMI caught quickly. As folks have been talking about in the control room the last few weeks, we should look in to why PRM in particular seems to move between locks more recently than it used to. I'm not yet sure what exactly to trend, but maybe an operator can have a look at the PRM top mass osems at the start of locking for the last few lock attempts, versus the top mass osems after initial alignment completes, and maybe also versus after DRMI ASC is offloaded.
DRMI ASC did bad things and got wobbly, but then seems to have recovered itself.
Things are overall going well (we're just about to power up), so I'm going to sign out for lunch. I'll try to check back in later.
Conclusion from this lock: As soon as the analysis pipelines have suffiicient double coincident data, we (I) should go back to giving more time for commissioing TJ's IFO Manager, that will know when it is time to do an initial alignment before continuing to attempt locking.
TITLE: 05/21 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY:
Locking:
Other:
LOG:
16:00 - Mike and film crew onsite (brief trip in LVEA while down for EQs, CR, overpass)
H1 has not been locked all day due to multiple earthquakes (see my earlier log for details). Currently waiting for the 5.6 from California to pass, then I'll untrip ISI watchdogs for ITMX, ITMY, and ETMX and realign.
Sun May 21 10:08:35 2023 INFO: Fill completed in 8min 35secs
Relocking this morning has been near impossible with multiple earthquakes rolling through (4.9 from Tonga, 6.8 from Prince Edward Islands, and now a 6.1 from Soloman Islands as I'm writing this) and wind speeds picking up, so I'm going to leave H1 in DOWN and the observatory in Earthquake operating mode until the ground calms down a bit. Seismic configuration has been in EARTHQUAKE since 15:21 UTC this morning.
Ground motion has calmed down enough; starting initial alignment now.
Never mind, 5.4 off the coast of northern California tripped ITMX, ITMY, and ETMX ISIs. We are now in LARGE_EQ seismic configuration
TITLE: 05/21 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: 11mph Gusts, 8mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: H1 lost lock three times last night; one of them from an earthquake, the others I will look into. Each time H1 has been able to fully relock itself and flip the Observation bit except for this morning, where it's been stuck in LOCKING_ARMS_GREEN due to an ALS PLL beatnote problem (since fixed by Sheila) and misalignment, which I will fix now.
We had a similar problem to what Austin reported here: 69712 which seems to have kept the IFO down for the last few hours.
In the attached trend you can see that the beatnote dropped suddenly and then returned to normal strength a few times.
I lowered the threshold for the beatnote strenth to -30dBm now, (had been reset to -10dBm after the beatnote recovered). To get the PLL to lock this time I had to disable the automation (using the request on the ALS overview and on the PLL screen), then manually adjust the crystal temp until the beatnote was close to 40MHz. It seemed as though the laser temperature had drifted to the wrong side of the PSL, which the automation can't recover from without help.
Sounds more like the laser is near the edge of a mode hope region. Maybe one should try to adjust the laser current and temperature.
TITLE: 05/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 130Mpc
SHIFT SUMMARY:
Locking:
Other:
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 17:12 | PEM | Robert | EY | - | Changing EY AHU speeds | 19:12 |
Since I could only change the flow at EY the way I wanted to, I manipulated only that flow rate. I turned it down from 12k CFM to 9.5k CFM last night to test stability (looks good), and so it is at 9.5k when I start and that is where I have left it. I think we should set all fans, except SF5 and SF6 to 9k or 9.5k CFM when we can. Here are the times:
EY:
17:02:30 From 9500 CFM (Vane position 40%) to 12000 CFM (70%)
17:14:15 Back to 9500 CFM
17:28:00 Change to 12000 CFM
17:41:56 Change to 9500 CFM
17:54:00 Change to 12000 CFM
18:08:00 Change to 9500 CFM
18:24:49 Change to 12000 CFM
18:39:10 Chnge to 9500 CFM
18:52:50 Change to 12000 CFM
19:09:15 Change to 9500 CFM
As noted above, I was unable to change the flow rates at the CS and EX, the two places that PEM injections suggested would be most sensitive to HVAC noise; I was able to change air flow rates at EY. There appears to be more scattered light at EY now than when I tested the damped cryobaffle in Sept. 2022 (Fig 1). But our PEM injections suggested that ambient vibration at EY would, nevertheless, not normally be limiting. This is consistent with my air flow manipulations – Fig 2 shows that there was very little if any improvement in range between 12000 CFM and 9500 CFM flow rates at EY.
PEM injections did, however, suggest that vibration at the corner station and EX may limit our range, always or on occasion. The 8 or 10 Mpc increase in range from the site HVAC shutdown is probably mainly associated with EX and CS. I suggest for now that the air flow rates be reduced to about 9k for each turbine, and I will study reduction in water flow etc. on my return.
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.