Seems like there was one short period, lasting 2 or 3 minutes around 2015/10/03 16:23 UTC, where RF45 AM became glitchy.
Except that one it has been quiet for 5 days since we tap-tested the problem connectors.
TITLE: 10/5 DAY Shift: 15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC
STATE of H1: In Observation Mode (19+hr stretch) at 65Mpc
Outgoing Operator: Patrick
Support: Occupied Control Room, Usual Suspects
Quick Summary: Going on 45+hr lock segment. The range had been at ~75Mpc, but it has started a downward trend (at about 8am), which probably corresponds with increased activity of the work week started (which started increasing about 4-6hrs ago.
Summarized H1 issues from last Fri/Sat & how we did over the weekend: Combination of environment & ALS glitching possible culprit for issues Fri/Sat. However we've been locked since about noon on Sat (going on 45hrs).
RF45 appears stable (will prob hold off on swapping cable until/if issue comes back & NOT address during Maintenance. Only address if needed).
Also discussion of "Freeze". Sounds like we are still in a partial freeze.
There was discussion about allowing Beam Tube repairs (will be discussed offline).
Commissioning & Any Invasive Activities:
Regular Tues Maintance Activities
There are activities which occur every week and these do not require a Work Permit, but need to be done on a recurring basis. A short list of these (also on whiteboard) is:
Ed is Operator on shift (& TJ is available as a secondary operator, if needed)
TITLE: 10/05 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC STATE Of H1: Observing, ~75 MPc SHIFT SUMMARY: Remained locked in observing for entire shift. A few SUS ETMY glitches. INCOMING OPERATOR: Corey ACTIVITY LOG: 07:54 - 07:59 UTC Stepped out of control room. SUS E_T_M_Y saturating (Mon Oct 5 8:52:2 UTC) SUS E_T_M_Y saturating (Mon Oct 5 8:52:4 UTC) SUS E_T_M_Y saturating (Mon Oct 5 14:56:49 UTC)
The SSD RAID has failed on h1tw0, so the trend writer has been halted. This will affect the ability of h1nds0 to get recent raw minute trend data.
Still locked in observing at ~ 78Mpc. A couple of SUS ETMY saturations.
TITLE: 10/05 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC STATE Of H1: Observing @ ~ 78 MPc. OUTGOING OPERATOR: Cheryl QUICK SUMMARY: From the cameras the lights are off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell if they are off at mid Y. Seismic in 0.03 - 0.1 Hz band is around .015 um/s. Seismic in 0.1 - 0.3 Hz band is around .1 um/s. Winds are less than 5 mph. I noticed on the CDS DAQ Overview that tw0 restarted itself. I see that Corey noted this occurring on his shift as well.
TITLE: EVE Shift, Oct 4th-5th, 23:00:00UTC to 07:00:00UTC, 16:00PT-00:00PT.
STATE OF H1: locked since yesterday, 77Mpc
SUPPORT: MikeL
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: quiet
IFO Activity:
Intention Bit: Undisturbed (Sun Oct 4 21:1:58 UTC)
SUS E_T_M_Y saturating (Sun Oct 4 21:22:44 UTC)
SUS E_T_M_Y saturating (Sun Oct 4 21:37:16 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 0:18:31 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 0:57:11 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 2:30:11 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 4:23:13 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 4:34:1 UTC)
TITLE: 10/4 DAY Shift: 15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC
STATE OF H1: In Observation Mode at 72Mpc
SUPPORT: Vinny, Robert
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Quiet shift with only small a small break for PEM injections.
Shift Activities:
Raw minute-trend writer, h1tw0, has been popping up medm message windows warning of "virtual circuit disconnects" (and h1tw0 boxes on the DAQ Detail go WHITE for a few seconds every few minutes).
LLO has had a GraceDB querying Failure for last few shifts/days.
Want to reiterate importance of contacting them whenever we receive an Alert on VerbalAlarms. The Alert/Trigger Site Response Checklist (L1500117), laminated at the Ops Work Station, states operator at each site must contact each the other to confirm they received the alarm (current state [LLO GraceDB Failure] is an example of the importance of this step).
Received GRB Alert at 18:11UTC. Going through the checklist (L1500117).
We've both restarted our sessions on TeamSpeak (I rebooted computer since ours would not allow me to open anything. Upon reboot, TeamSpeak opened automatically [thanks, Ryan!].). We are both now re-connected.
Yesterday when taking H1 to Observation Mode, Evan & I noticed a RED SDF on video0 (I think it was for PEMEX or EY), but we did not see it on our SDF screens on our work stations. I reopened the SDF and the RED went away. The medm was not frozen, because we were Accepting channels & it would go green before noticing this errant PEM RED. Just thought it was something interesting.
TITLE: 10/4 DAY Shift: 15:00-23:00UTC (00:00-8:00PDT), all times posted in UTC
STATE of H1: Observation Mode with Avg of 74Mpc
Outgoing Operator: JimW
Support: Vinny
Quick Summary: useism continues a slow trend down (at about 0.15um/sec). Winds hovering around 12mph.
Terramon has just come up with a RED warning of a 5.6 Peruvian earthquake who's Rayleigh wave is due here in a minute (0.7um/s), due at 15:30:38UTC. We'll see what happens.
L1 just went down at 15:30. Terramon said the EQ's Rayleigh waves (of 1.4um/s) would arrive there at 15:17UTC.
So we might not be out of the woods yet...watching 0.03-0.1Hz (all three axis have yet to move up at the same time and all are still under 0.1um/s...I've seen us drop out when all three go above that velocity...but that was a few weeks ago before the DHARD filter).
No signs of anything on tidal or ASC control strip tools either.
It's been 15min since the R-wave arrival estimate, I'm assuming we rode through the EQ. (it was barely observable in here on seismic bands, range, striptools). Time to make breakfast/coffee.
I started to look at our locking attempts over the last two weeks, especially trying to understand our difficulty yesterday. I will write a more complete alog in the next few days, but I wanted to put this one in early so that operators can see it.
We've known for a long time that at LLO they always pull the OMC off resonance durring the CARM offset reduction, and they've told us that they can't lock if it is flashing. We know that we can lock when it is flashing here, which might be because our output faraday has better isolation.
In the two weeks of data that I looked at, we've locked DRMI 64 times, 33 of these locks resulted in low noise locks and 31 of them failed durring the acquistion prodecure. Of these 31 failures, about 9 happened as the OMC was flashing. We also had about 12 sucsesfull locking attempts where the OMC flashed. OMC flashing probably wasn't our main problem yesterday, but it can't hurt and it might help to pull the OMC off resonance durring the CARM offset reduction.
Operators: If you see that the OMC is flashing (visible on the OMC trans camera right under the AS camera on the center video screen) you can pull it off resonance by opening the OMC control screen, and moving the PZT offset slider which is in the upper right hand quadrant of the screen. Even if you don't see the OMC flashing on the camera it might not hurt to pull the PZT away from the offset it is left at, which was the offset where it was locked in the last lock. I will try to add this to guardian soon and let people know when I do.
screenshot with slider circled in a red dashed line
Evan Sheila
Here is a plot of the 24 locklosses we had from Sept 17th to Oct 2nd durring the early stages of the CARM offset reduction. The DCPD sum is shown in red while the black line shows H1:LSC-POPAIR_B_RF18_I_NORM (before the phase rotation) to help in identifying the lockloss time. You can see that in many of these locklosses the OMC was flashing right before for as we lost lock. This is probably because the AS port was flashing right before lockloss and the OMC is usually nearly on resonance.
We looked at 64 total locking attempts in which DRMI locked, 24 of these resulted locklosses in the early stages of CARM offset reduction (before the DHARD WFS are engaged). In 28 of these 64 attempts the OMC DCPD sum was above 0.3mA sometime before we start locking the OMC, so the OMC flashed in 44% of our attempts. We lost lock 16 out of 18 times that the OMC was flashing (57% of time) and 8 out of 36 times that the OMC was not flashing (22% of the time).
We will make the guardian pull the OMC off resonance before starting the acquisition sequence durring tomorow's maintence window.
Way back on September 5th, I collected OMC mode scan data before and after the power-up step from 2.2W to 22.5W. The idea was to measure the time-evolution of the sideband and higher-order-mode content at the AS port as the IFO thermalizes and the alignment adjusts to the hi-power state. During the mode scans, I followed Koji’s beacon demodulation technique, and used a DARM excitation to tag the carrier light resonant in the arms. This lets us disentangle the junk carrier light (resonant in the corner) from the good carrier light (resonant in the arms).
There’s quite a bit of information in these mode scans, but the major results are:
- After the power-up step, the amount of 9MHz light at the AS port more than doubles, with a time constant of about 6 minutes. I’m not sure how this informs the studies by Elli & Stefan and Paul regarding the AS36 WFS sensing. Does this time constant agree with thermal effects in the SRC? Or is it from slow alignment loops responding to something like wire heating?
- The contrast defect (ratio of carrier junk light to total available carrier light) is very small, less than 70ppm.
- The mode-matching of the carrier light resonant in the arms into the OMC is excellent, better than 99%.
- Unfortunately, these data don’t completely solve the mysteries of the HAM6 power budget. The 45MHz sidebands saturate the DCPDs at 22W with the preamps in the Hi-Z state, and this makes it impossible to measure the 45MHz sideband power at the AS port using mode scans. But, we can accurately measure the DCPD photocurrent from the carrier and 9MHz sidebands. Carrier = 33.6 +/- 0.4 mA, 9MHz SB = 34.9 +/- 0.3 mA.
Measurement Procedure
Here’s an outline of how the mode scan data were collected:
With the IFO locked on RF-DARM at 2.2W, unlock the OMC, turn off the OMC-LSC_SERVO output, turn off the OMC LSC dither. Turn off all stages of the the DCPD whitening (important).
Check that OMC ASC is on and using the QPDs. Zero the OMC PZT2 offset. Make sure the DARM boost (FM1) is on (important).
Set the DARM offset to 1.2e-5 counts in the LSC-DARM filter bank (this should be about 16pm).
Use AWG to set up an excitation on OMC-PZT2, I used a 70V ramp, 70 second period. Use AWG to set up an excitation on DARM for the beacon scan, I used 1e-8 counts at 201.7 Hz.
I collected ten minutes of data at low power, then engaged the power-up step in the Guardian. After power-up I collected about an hour of data. The GPS times of the data are:
Lo-power start: 1 125 478 482
Lo-power stop: 1 125 478 992
Hi-power start: 1 125 479 058
Hi-power stop: 1 125 482 221
Mode Fitting
For each span of data, the analysis code looks at PZT2_MON_DC and finds times when the PZT drive was slowly increasing. During these periods it grabs the DCPD_SUM data and fits the modes, using the measured transverse mode spacing of the OMC and the known sideband frequencies. I use the measured FSR and f_HOM from Koji’s lab measurements of the H1 OMC:
FSR = 261.72 MHz
f_HOM = 0.21946*FSR
The peaks are fit using the usual Lorentzian function of the PZT voltage. It would be better to do this as a function of optical frequency, but the PZT nonlinearity is small enough that I’ve ignored it. Anyways there's a chicken-and-egg problem, you have to fit the PZT voltage before you can convert voltage to optical frequency.
Problem: 45MHz sideband saturation
At 2.2W, the 45MHz sideband peaks generate about 16mA of photocurrent in DCPD_SUM. In the Hi-Z state, the DCPDs saturate at 20mA (the precise value varies slightly depending on the preamp electronics, these values have been recorded in, for example, the DCPD filter banks). At 22W we expect 160mA in each 45MHz peak, so these saturate the DCPDs.
Weirdly, the 45MHz peaks saturate at a slightly lower value than expected. During the mode scans each of the DCPDs would always flat-top around 27500 counts out of the ADC for each of the 45MHz peaks. See Figure 3. To get around this in the mode fitting, I fit the data before and after the flat-top from the saturation. Unfortunately this doesn’t return the correct peak height: the total power doesn’t agree with what we expect, and it doesn’t agree with the power measured by AS_C. So we still don’t have a complete picture of the HAM6 noise budget.
We could try mode scans with the DCPD preamps in the Lo-Z state, but this only gains us a factor of four in headroom, and the 45MHz peaks would still be on the edge of saturation.
Results: Contrast Defect, Mode Matching, and the Time Evolution of Sideband Power
Using the beacon dither demodulation, we can tag the fraction of the carrier modes which are resonant in the arm. For each PZT sweep, the DCPD data was demodulated at the DARM excitation frequency. A multiplicative factor was applied to match the carrier 00 mode signal in the demodulated signal to the raw DCPD data. From there, we calculate the fraction of each carrier higher-order-mode that is resonant in the arms. The procedure is the same as described by Koji. After some testing I settled on a 10Hz lowpass after the demodulation.
The junk light in the carrier higher order modes is used to calculate the contrast defect: 66.2 +/- 4.5 ppm. The uncertainty is a combination of the statistical uncertainty from mode heights and the variation from sweep to sweep, and systematic uncertainties described in section 5.6 of P1500136.
The fraction of good light in the CR2 (bullseye) mode is used to calculate the mode-matching of the resonant light from the arms into the OMC. Mode-matching: 0.997 +/- 0.001. The alignment into the OMC was not so good during these measurements (a large fraction of the CR1 mode was from the arms), but this was expected since we were using the QPD servo.
The breakdown of DCPD photocurrent from the carrier is:
34.00+/-0.06 mA total carrier light
22.42+/-0.06 mA of light from the arms (note: this is not quite the standard DARM offset)
11.59+/-0.06 mA of junk that's not from the arms
Probably in typical low-noise operations, we have 20mA of carrier light from the arms (fixed by the DC readout loop), and 11.6mA of junk carrier from the corner.
The figures attached are the following:
Figure 1 is a GIF movie showing the evolution of the peak heights following the power up. Note the dramatic increase in lsb3, a higher-order mode of the 9MHz lower sideband.
Figure 2 is a GIF demonstrating the peak fitting procedure.
Figure 3 illustrates the saturation of the DCPDs by the 45MHz sideband peaks. The fit to the peaks (which is necessary for the subtraction of the peak shoulders from the surrounding data) is performed using the data on either side of the flat-top from the saturation. To the eye this looks pretty good, but the peak heights from the fit are way less than what we expect, so there's something bogus going on here.
Figure 4 shows the result of the mode fitting (the same data as Fig. 2).
Figure 5 overlays all of the hi-power mode scans and labels the peaks. Not all of the peaks that are labeled are fit in the analysis.
Figure 6 shows the fit of the peak locations (in PZT voltage) to the expected optical frequency, using a 4th-order polynomial fit of voltage to frequency. This is a sanity check that we correctly labeled the peaks. The error bars are the standard deviation of each peak location, across the few dozen mode scans. This is a crude measure of the statistical variation in the peak fitting.
Figure 7 shows the results of the beacon dither demodulation for one sweep. Black is the raw DCPD data, blue is the demodulated data at the frequency of the DARM excitation, and green is the background demodulation. This is a replica of Koji’s plot from April. The blue trace has been multiplied by a constant so it matches the black trace (raw data) at the CR0 peaks.
Figure 8 shows the fraction of each carrier mode that is tagged by the DARM excitation. The fraction of the 00-mode from the arms is unity, by definition. Except for the 01,10 mode (due to misalignment from the QPD servo), most of the carrier HOMs are due to junk light, i.e. the fraction of each mode from light resonant in the arms is small.
Figure 9 plots various interesting results as a function of time since power-up. This plot is probably the most interesting collection of results. The contrast defect is fairly stable (upper left). Notice how the carrier mode-matching into the OMC improves over time (middle left), and how the 9MHz power increases (lower right). The total photocurrent in the 45MHz sidebands (lower left) is bogus due to the saturated peaks. The time evolution of various measured quantities were fit with exponential curves, the time constants returned by the fits are:
Total photocurrent in 9MHz modes: 370 seconds
AS_C SUM: 400 seconds
Carrier mode-matching (using beacon scan): 830 seconds (note, data are noisy)
Total photocurrent in carrier modes: 320 seconds (note, data are noisy)
Figure 10 demonstrates the change in power in the carrier, 45MHz, and 9MHz modes around the power-up. Except for the 45MHz data (which is wrong because of the saturated peaks), this is a nice before-and-after picture of the power at the AS port. In this plot, I have normalized the total DCPD photocurrent in [carrier, 9MHz, 45MHz] modes by the input power (measured by IMC-PWR_IN).
Finally, Figures 11, 12, and 13 show the change in the individual mode heights over time. There is a large increase in the amount of 9MHz HOMs after the power up. (Since the 9MHz light is not well-matched to the OMC, it couples to higher order modes of the cavity.) The 45MHz LSB5 mode increases, but this is a small peak in a fairly noisy part of the mode scan, and might be sensitive to a nearby 9MHz mode. The 6th-order carrier mode loses a lot of power, this is responsible for most of the reduction in carrier power in Fig. 10.
Analysis Code
I have pushed a version of the mode-fitting code to git.ligo.org. This code can’t run on the control room workstations because of the crummy version of scipy that doesn’t have the peak-finding routines, but there is a script included that will download the data with cdsutils, and you can hack away at it on a laptop from there.
Since the beacon dithering required a high sample rate, across one hour of data, most of this analysis was performed on the LHO cluster. The code and results are saved in this directory.
Can you make something like Figure 12 without normalization?
For one thing I'd like to see the ratio of 0 mode VS higher order modes, and for another it seems to me that the SB imbalance is not small for 9MHz at t=4 and becomes worse as time goes, while 45MHz is just fine.
Here are AS LF, 18 MHz, 90 MHz and 36 MHz length signals during the most recent lock stretch. One can clearly see that the 9 MHz is in trouble.
Due to small finesse, only 00 and 1st order mode for 9MHz are anti-resonant. Especially, LSB 4th order HOM as well as USB 6th are very close to resonance.
"Transmissivity" of SRC against LSB4 and USB6 coming out of BS (which is due to differential mismatch from the ITMs or BS lensing) are about a factor of 7 larger than 00 mode.
In this comment I'll try to answer some questions about the calculation details, and post more data on the mode heights.
Parameters for the Contrast Defect Calculation
The contrast defect is calculated as the ratio of junk carrier light at the AS port to the total available carrier light incident on the beam splitter.
Available carrier light on the beam splitter:
P_carrier = p_in * J9^2 * J45^2 * tIO * g_cr = 673 +/- 40 W
Losses between beamsplitter and DCPDs (including photocurrent --> power calibration):
P_loss = tSRM * tOFI * rOM1 * rOM3 * tOMC * PDresp = 0.241 +/- 0.008 A/W
The uncertainties on the parameters above are guesswork, not motivated by any direct measurements. The dominant source of uncertainty turns out to be the recycling gain.
The total photocurrent in carrier HOMs measured by the DCPDs is about 12mA. Of this, about 0.7mA is tagged as good light from the arm cavities. Most of this is due to the CR1 mode -- this is expected, since the OMC alignment is not optimal on the QPD servo. The CR1 mode is quite small, so nearly all of the carrier HOM content is tagged as 'junk light' not resonant in the arms. This is the measurement used to calculate the contrast defect:
P_junk = 11.3 +/- 0.03 mA
contrast defect = P_junk / (P_carrier * P_loss) = 69 +/- 5 ppm
**Note: in the initial calculation I used a recycling gain of 38+/-2. Now I use 36+/-2, this has changed the result from what was presented in the main entry.
Mode Matching Worst-Case
While the calculation of the contrast defect is somewhat immune to mistakes in the beacon scan measurement (since the amount of carrier HOM content is so small to begin with), the calculation of the carrier mode-matching is highly sensitive to systematics in the beacon scan results. As is shown in Fig 8 above, the fraction of the CR2 mode that is tagged as 'good light' starts around 20%, but decreases as the IFO thermalizes to around 2%. If this is incorrect, we have overestimated the mode-matching into the OMC.
To calculate a worst-case scenario, the photocurrent in the CR2 mode for the last 15 mode scans is 2.6 +/- 0.3 mA. The fraction tagged as good light is 0.025 +/- 0.014. The carrier 00-mode photocurrent is 21.7 +/- 0.4 mA. If all of the CR2 light is from the arms, the mode-matching is 88%.
From the mode scans at low power, we know that a substantial amount of CR2 light can be present at the AS port even when the DARM offset is zero, implying the small CR2 fraction from the arms could be real. (Note: I think the low-power mode scans were taken with different TCS settings, certainly different ETM ring-heater settings.)
Mode Height Plots
In the attached plots, I try to answer Keita's question from above. These plots show the mode heights of the carrier, 9MHz, and 45MHz peaks over time, starting at the end of the power-up step. Some things to note:
I also attach two text files. The first has the median measured mode height, in mA of photocurrent, for all the modes fit within a single FSR. The value and uncertainty for each mode are calculated as the median and std() of the mode heights across the last 15 mode scans in the dataset. The final column is the measured frequency of the mode location, based on the fit of PZT voltage to optical frequency. (Remember, we use upper case LSB and USB for the 45MHz sidebands, lower case lsb and usb for the 9MHz sidebands.)
The second text file lists the carrier modes (zero through eight) and the measured fraction of the mode due to the 'good light' resonant in the arms, calculated from the beacon scan. Again, the uncertainty is calculated from the std() of the final 15 mode scans.
Just in case you're wondering why LHO sees two noise bumps at 315 and 350Hz (attached, middle blue) but not at LLO, we don't fully understand either but here is the summary.
There are three things here, environmental noise level, PZT servo, and jitter coupling to DARM. Even though the former two explains a part of the LLO-LHO difference, they cannot explain all of it, and the coupling at LHO seems to be larger.
Reducing the PSL chiller flow will help but that's not a solution for the future.
Reimplementing PZT servo at LHO will help and this should be done. Squashing it all will be hard, though, as we are talking about the jitter between 300 and 370Hz and there's a resonance at 620Hz.
Reducing coupling is one area that was not well explored. Past attempts at LHO were on top of dubious IMC WFS quadrant gain imbalances.
1. Environmental difference
These bumps are supposed to be from the beam jitter caused by PSL periscope resonances (not from the PZT mirror resonances). In the attached you can see that the bumps in H1 (middle blue) correspond to the bumps in PSL periscope accelerometer (top blue). (Don't worry, we figured out which server we need to use for DTT to give us correct results.)
Because of the PSL chiller flow difference between LLO and LHO (LHO alog, couldn't find LLO alog but we have MattH's words), in general LLO periscope noise level is lower than LHO. However, the difference in the accelerometer signal is not enough to explain the difference in IFO.
For example, at 350Hz LHO PSL periscope is only a factor of 2 noisier than LLO. At 330Hz, LHO is quieter than LLO by more than a factor of 2. Yet we have a huge hump in DARM at LHO, it becomes larger and smaller in DARM but it never goes away, while LLO DARM is deat flat.
At LLO they do have a servo to supress noise at about 300Hz, but it shouldn't be doing much if any at 350Hz (see the next section).
So yes, it seems like environmental difference is one of the reasons why we have larger noise.
But the jitter to DARM coupling itself seems to be larger.
Turning down the chiller flow will help but that's not a solution for the future.
2. Servo difference
At LLO there's a servo to squash beam jitter in PIT at 300Hz. LHO used to have it but now it is disabled.
At LLO, IOOWFS_A_I_PIT signal is used to suppress PIT jitter targetting the 300Hz peak which was right on some mechanical resonance/notch structure in PZT PIT (which LHO also has), and the servo reduced the noise between about 270 and about 320Hz (LLO alog 19310).
Same servo was successfully copied to LHO with some modification, which also targeted 300Hz bump (except that YAW was more coherent than PIT and we used YAW signal), with somewhat less (but not much less) aggressive gain and bandwidth. At that time 300Hz bump was problematic together with 250Hz bump and 350Hz bump. Look at the plots from alog 20059 and 20093.
Somehow 250Hz and 300Hz subsided, and now LHO is suffering from 315Hz and 350Hz bumps (compare the attached with the above mentioned alog). Since we never had time to tune the servo filter to target either of the new bumps, and since turning the servo on without modification is going to make marginal improvement at 300Hz and will make 250Hz/350Hz somewhat worse due to gain peaking, it was disabled.
Reimplementing the servo to target 315 and 350Hz bumps will help. But it's not going to be easy to make this servo wide band enough to squash everything because of 620Hz resonance, which is probably something in the PZT mirror itself (look at the above mentioned alog 20059 for open loop transfer function of the current servo, for example). In principle we can go even wider band, but we'll need more than 2kHz sampling rate for that. We could stiffen the mount if 620Hz is indeed the mount.
3. Coupling difference
As I wrote in the environment difference, from the accelerometer data and IFO signal, it seems as if the coupling is larger at LHO.
There are many jitter coupling measurements at LHO but the best one to look at is this one. We should be able to make a direct comparison with LLO but I haven't looked.
Anyway, it is known that the coupling depends on IMC alignment and OMC alignment (and probably the IFO alignment).
At LHO, IMC WFS has offsets in PIT and YAW in an attempt to minimize the coupling. This is on top of dubious imbalances in IMC WFS quadrant gains at LHO (see alog 20065, the minimum quadrant gain is a factor of 16 larger smaller than the maximum). We should fix that before spending much time on studying the jitter coupling via alignment.
At LLO, there's no such imbalance and there's no such offset.
The coupling of these peaks into DARM appears to pass through a null near the beginning of each full-power lock stretch, perhaps indicating that this coupling can be suppressed through TCS heating.
Already from the summary pages one can see that at the beginning of each lock, these peaks are present in DARM, then they go away for about 20 minutes, and then they come back for the duration of the lock.
I looked at the coherence (both magnitude and phase) between DARM and the IMC WFS error signals at three different times during a lock stretch beginning on 2015-09-29 06:00:00 Z. Blue shows the signals 10 minutes before the sign flip, orange shows the signals near the null, and purple shows the signals 20 minutes after the sign flip.
One can also see that the peaks in the immediate vicinity of 300 Hz decay monotonically from the beginning of the lock strech onward; my guess is that these are generated by some interaction with the beamsplitter violin mode and have nothing to do with jitter.
Addendum:
alog 20051 shows the PZT to IMCWFS transfer function (without servo) for PIT and YAW. Easier to see which resonance is on which DOF.
