J. Kissel (B. Weaver, S. Dwyer) FRS Ticket 6852 It was recently identified that a Dec 05 lock loss looked suspiciously cpoincident with a glitch in the H1 SUS SR3 M1 T1 and LF OSEMs (see LHO aLOG 32220). The same OSEMs were suspected in a subsequent Dec 06 lock loss (LHO aLOG 32251), and thus an FRS ticket was filed (FRS Ticket 6852), but was later deemed too confusing to draw conclusions (see brief mention of it in LHO aLOG 32279). Betsy then went back to find the minute trends of the SR3 OSEM noise appeared suddenly louder after the Dec 05 glitch/lock loss in a 5 day trend surrounding the glitch (split into LHO aLOGs 32280 and 32281). In this aLOG, I investigate further by zooming into 10 minutes surrounding the Dec 05 glitch. I attach three plots: - A 10 minute trend of second trends for the suspect channels, both in terms of uncalibrated EPICs records (the same that Betsy chose to use in her aLOG) and in calibrated fast channels (stored at 256 Hz). The EPICs records show a similar sudden increase in amplitude of max and min trends, but the calibrated fast channels do not. T1 shows a much larger increase in max/min noise than LF. - A full-data time-series of the same to channels in the same two formats. Same thing here regarding the sudden increase in noise in T1 INMON, but only a brief glitch in LF's INMON. Again, no such obvious change in behavior on the fast channels. Interestingly, it looks like there's smaller glitch in T1's fast channel 107 [sec] earlier. - An amplitude spectral density of the calibrated fast channel before and after the glitch happens (15:57 UTC vs 16:06 UTC, 0.04 Hz BW ASD). There's no obvious difference between these spectra. This points to either the excess noise showing up in the INMONs is at higher than ~100 Hz, or the EPICs records are just reporting bogus information. Because I'm suspicious of the apparently incredibly low microseism, I also attach BLRMS of the microseism on the ground and on the ISI around this time. Indeed, the GS13s seem to confirm that the RMS velocity is somewhere around 5 [nm/s], which is roughly equivalent to ~5 [nm] at 0.15 Hz, which in the right ballpark of what the OSEMs report of 2-4 e-3 [um] or 2-4 [nm] or 2-4 [nm/s]. In conclusion -- still no evidence for anything more than a one-time glitch, and there is now little-to-no evidence for permanently different noise behavior after the glitch. We need to wait for more occurances of this issue with obvious evidence before we go for making any change to the instrument.
This is something that I think has definitely happened twice:
In the example from Dec 5th, it is clear that there is a glitch in T1 and LF, on Dec 6th it is not clear which osem to blame, but it is clear that SR3 moves before the lockloss (see this plot). We don't send any ISC feedback to SR3, and I already checked that the cage servo isn't glitching in either case, so this is most likely a problem that comes from the top mass damping.
TITLE: 12/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68.7782Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.29 μm/s
QUICK SUMMARY: Observing for 23 hours now.
0:10 Intent bit set to commissioning so Evan can turn off high frequency PCal line for HW inj.
0:11 Evan accepted the new SDF diff for PCal, so we went back to Observe.
0:17 Injection gain ramping dropped us out of Observe, Evan set this gain to 'Not Monitored', and we were back to Observe within the minute
0:34 PCal HF line turned back on, out of Observe. I am running a2l since it looks like it is time, and Sheila is opportunistically working one of her work permits.
Back to Observing at 0:48 UTC.
I turned off the 4301.3 Hz Pcal line at 00:10 Dec 8 2016 UTC for the planned stochastic injection. This dropped us from observing intent for a brief time. I updated the SDF and we returned to observing. I will turn the line back on once the stochastic injection has concluded.
Pcal line turned back on at 00:35 Dec 8 2016 UTC.
I've scheduled a coherent stochastic injection for 00:20 UTC (16:20 PT). It will take 13 mins. The update to the schedule file is:
1165191617 H1L1 INJECT_STOCHASTIC_ACTIVE 1 1.0 stoch/Waveform/SB_ER10_{ifo}.txt
The PINJ_TRANSIENT_GAIN change from 0 to 1 for the stochastic injection knocked us out of observing intent before the start of the injection. We made this channel now unmonitored and went back to observing before the injection began.
The stochastic waveform was successfully injected into both IFOs. The log file for H1 INJ_TRANS is attached.
'Double modes' seen in some PI mode bands are not from test mass resonances, in agreement with model conclusions. Follow up on this .
I've looked at frequency shifting of the peaks seen in the 15060 - 15090 Hz range during 11 hours of the current lock.
Attached plots:
3:48 pm local
Took 30 sec to overfill CP3 by raising LLCV from 18% to 50% open. I lowered back to 17% since there was some pressure at exhaust and fill time was so fast.
The dust monitor alarm levels have been set to their correct values. All future alarms should be treated as valid and should be investigated. Please open an aLOG and notify Jeff B.
CP4 appears to have joined with the disfunctioning CP3 and is now being investigated by Kyle and Chandra. Until further notice operators should expect false level indications at CP4.
CP4 bottom sensing line plugged up this morning after alarming all night. Kyle and I applied up to 180 psig of N2 to the sensing line in an effort to clear the blockage but so far no luck (we've left sensing line under pressure for several hours while watching exhaust pressure).
We performed a manual overfill at 11am by turning LLCV bypass valve 1/2 turn open. Overfill took 1 hour.
I started to install thermocouples at the exhaust line similar to CP3 so we can monitor and fill from control room as we do CP3.
Attached is a trend of the corner EtherCAT Device0 channels while there was a broken module on 11/26, see alog 31854. The error can be seen in the ERROR_FLAG, SLAVE_COUNTERROR and the FRAMEWORKINGCNTs. The SLAVECOUNTACTUAL dropped from 345 to below 50—indicating a broken link or module.
On Nov 1 chassis 3 was pulled for some repairs, see alog 31081. The Device0 channels showed similar behavior.
On Nov 15 the power supply was changed for the baffled PD controllers, see alog 31509. This temporarily removed 4 modules from the EtherCAT chain. Again, we can see this clearly in the Device0 channels.
The last plot shows frame rates. Most frames seem to be lost during the above repairs and modifications.
No errors were detected in the end stations.
Reveived a second GRB Alert at 20:50 (12:50PT). Both sites in Observing mode. Will extend the hold until 21:50 (13:50PT)
Received GRB alert at 20:05 (12:05PT) - LLO received same. Both IFOs in Observing mode. Will observe hold until 21:50.
Hold will last until 21:05 - Not 21:50
With the ASC IMC model now running at 16384 Hz we look at the coherence of jitter as measured by the IMC WFS and other channels up to 7.4 kHz. Not sure we can conclude anything except that pointing errros contaminate everything.
We can compare this with an older 900-Hz bandwidth measurement from alog 31631 which was taken before the piezo peak fix (alog 31974).
Note that 1084Hz thing doesn't have coherence with IMC WFS.
Can you check the DC sum channels for the IMC WFS as well? They are the ones that hVeto keeps finding as related to the 1080 Hz noise, and they see a modulation in the noise rather than a steady spectrum.
Done, again nothing for the bump in question though there are coherence bumps for f>1100Hz and f<800Hz.
TITLE: 12/07 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 70.7388Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Pretty smooth shift as far as locking goes. Some excitement regarding CP4 (see aLog 32283). Also, set some arbitrarily high thresholds for most dust monitors to stop alarms. JeffB will reset them tomorrow. Locked for over 6 hours now.
LOG:
3:35 CP4 alarm
5:24 GRB alert, contacted LLO who verified that they received the alert, begin standdown
6:24 GRB standdown end
7:10 PI mode 27 ringing up, changed phase from 20 to 120. Did not go out of Observe. Are we supposed to go out of Observing to make PI mode changes??
As of now, you do not need to drop out to change either PI phase or gain. We unmonitored these so they wont drop you out anyway. If PI ever gets so high that it takes more than a phase flip, gain flip, or couple thousand gain increase, you're seeing it in DARM, and you're worried about losing lock, you 'd want to drop out.
As a benchmark against which to compare upcoming O2 data, I have compiled a list of narrow lines seen in the H1 DARM spectrum up to 2000 Hz, using 107 hours of ER10 FScan 30-minute SFTs. There are no big surprises relative to the lines and combs Ansel and I have reported on previously from ER9 and later data, but below are some observations. Attached figures show selected band spectra, and a zipped attachment contains a much larger set of bands. Also attached for reference is a plaintext list of combs, isolated lines, PEM-associated lines. etc. In the attached spectra, the red curve is the ER10 data, and the black curve is the full-O1 data. The label annotations are keyed to the height of the red curve, but in some cases, those labels refer to lines in the O1 data that are not (yet) visible in accumulated current data. For the most part, lines seen in O1 that don't show up in ER10 nonetheless remain for now in the lines list and still have labels on the graphs that end up in the red fuzz. If they fail to emerge in O2 data, they will be deleted from future line lists. Observations:
Here is a plot of the violin mode harmonics around 1kHz, comparing the amplitudes today to the amplitudes right after the damping efforts of Nov 30th.
We don't actively damp these by default, only when someone manually engages damping do they get damped. Durring the first part of ER10 ISI trips caused by tidal problems were ringing them up, but that problem is fixed now and most modes are ringing down. ETMX modes (between 1003 and 1006Hz) have increased in amplitude since the 30th.
The largest peak here is the pair on ETMY that Keith points out, we have settings that work to damp both of these modes using the mode9 filter bank on ETMY, and it would not be difficult to turn this damping on automatically in the guardian.
Our question for Keith and detchar is is this (the current spectrum) good enough? Or should we continue to try to add automatic damping for some of these modes?
Automatically damping the violin modes would reduce up-conversion contamination at the starts of lock stretches, making more data usable for CW searches. Even small excess powers in narrow bins leads to unnecessary outliers in analysis that waste computing and manpower. Unless there is a downside to such damping, it seems warranted. thanks, Keith