Last night the IFO was locked stably for a long period of time, so I had a look of the coupling of the HPO jitter into DARM.
I measured the transfer function from DBB_Q1Y (the largest one) with CAL_DELTAL every ten minutes, over the entire lock. It turns out that the shape of the transfer function is quite constant over time, while the overall gain was clearly changing, and increasing during the lock. The first attached plot shows a time-frequency plot of how the transfer function changed, with respect to the mean. In other words, the plot shows TF at a give time divided by the mean TF over the entire period. There is a clear trend to increase. This is also visible in the second plot, which shows the value of the TF in three selected bands, as a function of time. All three bands moves roughly in the same way.
As done before, I computed and fitted the transfer function from DBB_Q1Y to CAL_DELTAL. Figure 3 shows the coherences for all DBB signals, and figure 4 shows the transfer function from Q1Y and the fit. Note that the coherence was somehow smaller than what measured yesterday. I converted the fitter transfer function to an IIR filter and computed the time domain subtraction. The improvement in sensitivity is there, but not quite as impressive as yesterday (see 30300), see figure 5. However, coherence with Q1Y is reduced basically to zero, see figure 6.
SInce there was some small coherence with Q1X, I measured and fitted that transfer function too, and then subtracted Q1X. The result is shown in figures 7 (spectra) and 8 (coherences). The improvement is small, but there is clearly no more coherence with any DBB signal.
At that point I looked at the coherence of the double subtracted DARM with the IMC WFS centering signals. As shown in figure 9, this coherence is very large and could explain a lot of the noise in the 100-1000 Hz region. Figure 10 shows a coherence-based estimation of the subtracted noise. Unfortunately, the transfer function from IMC-WFS to DARM is very complex, and a time domain subtraction is not easy to do.
We should work on improving the IMC alignment, this used to be the right cure to reduce the coupling of jitter peaks into DARM.
State of H1: unlocked, relocking, needing some alignment, currently on it's way to DRMI_LOCKED
On Site: me, Robert, and Gabriele
I checked the IOT2 tables for scattered light. The beam on IOT2R was hitting an optic mount, so I blocked it. However, the beam was reflected from the black glass dump on the top mirror so it was already small. I also checked the tables by shaking them and got no coupling. I shook the output arm vacuum enclosure, no evident coupling. I shook several HAMs. Shaking HAM2 seemed to significantly increase the jitter peaks, periscope and HPO, while shaking HAM 3 did not. This may suggest clipping on HAM2. Ill look into this more in the morning.
Jeff B., Kiwamu, Gabriele, Daniel, Robert Note for next operator: The power setpoint is set to 20 W in the lscparams.py file. 23:44 UTC Lost lock during power up. Kiwamu, Daniel and Gabriele diagnosed problem with ASC loops. Changed power setpoint in lscparams.py to 20 W. Stepped up through the LASER_PWR node states ~ 5 W at a time to 45 W. (50 W reported in). This seemed to bypass the ASC difficulties. Kept lock and made it to NLN. 00:53 UTC Robert to LVEA to turn on injection 00:57 UTC NLN 01:01 UTC Robert moving SRM to reduce jitter peaks 01:24 UTC Robert to LVEA 01:29 UTC Robert back 02:05 UTC In the process of damping PI mode 26, PI mode 17 rang up and got almost immediately suppressed 02:06 UTC Robert to IOT1 02:11 UTC Kiwamu left 02:52 UTC Damped PI mode 2 by reversing sign of phase 03:01 UTC Verbal alarm that TCSY chiller flow is low. Apparently just a glitch. 03:25 UTC PI mode 17 rang up and damped itself 05:01 UTC PI mode 26 slowly started coming up. Picked various phases and it started coming down, but not sure if there is a causation. 05:59 UTC Started testing connection of conlog-test-master to channels 06:27 UTC Robert leaving. Stopped Conlog test. Could not put into observing mode due to 'waiting for node: LASER_PWR'. Leaving IFO at NLN
yesterday Jamie, Jim and myself discussed the ramp down issues which were reported by Jenne in alog 30258 Link
here are some notes we made describing the problem.
In the figure attached, the diaggui program running on the workstation sends commands over the network to the model's awgtpman process (running on the general core on the front end machine). Inside this process there are three components of the excitation; the excitation itself, an optional user-supplied filter and an output gain stage. The output of the gain stage is sent, via shared memory, the the front end model which writes the excitation signal into the EXC input of the appropriate filter module.
When diaggui completes its measurement or the user presses the abort button, the excitation is ramped down to zero amplitude over the user supplied ramp-time. Normally at this point the output of the gain stage is also zero. The excitation is then stopped, and the EXC input to the filtermodule is zeroed.
In Jenne's case the filter running on the awgtpman rang up even with the excitation writing zero to it. This meant that at the conclusion of the excitation ramp down the output of the gain stage was non-zero, resulting in a sharp step to zero when the excitation was stopped.
Assuming that at the conclusion of the measurement (or if the measurement is aborted) it does not matter whether the excitation ramp-down does or does not go through the filter, then one solution is to ramp the excitation down by ramping the gain to zero. This ensures the output of the gain stage is zero when the exitation is stopped. Jim is reviewing if this is possible and how much programming time this change would take.
We came up with a short term solution in cases where the filter does not zero in the ramp down time. It is possible to run awggui to the excitation test point in order to manually control the gain stage, and diaggui to the same excitation test point to control the excitation. In such case, when the excitation should be stopped the user can ramp the gain down to zero using awggui and then abort the diaggui measurement.
We think this must be set up in advance of the measurement, with awggui started first. The awggui configuration should set the frequency as non-zero (e.g. 1Hz) and the amplitude as zero. When we tried running awggui after diaggui had been started we got errors.
Title: 10/07/2016, Day Shift 15:00 – 23:00 (08:00 - 16:00) All times in UTC (PT) State of H1: IFO is unlocked. Wind is mostly a Fresh Breeze with gusts up to Near Gale (19 to 38mph). Seismic is slightly elevated but well below the 0.5 line. Microseism is elevated at the corner stations. Unsuccessful locking and the look of the spots indicate an initial alignment is in order. Outgoing Operator: N/A Activity Log: All Times in UTC (PT) 15:40 (08:40) HFD driving inspection along Y Arm 16:05 (09:05) Evan – LVEA to check REFL9 signal chain 16:18 (09:18) Robert - Into LVEA setting up to look at tables 16:30 (09:30) Evan – Out of the LVEA 16:35 (09:35) Robert – Out of the LVEA 17:54 (10:54) Richard & Daniel – In CER working on RF9 & RF45 problem 18:05 (11:05) Marc - Going to Mid-Y to recover parts 18:22 (11:22) Marc – Back from Mid-Y 20:08 (13:08) Chandra – Going to CP3 for overfill 20:19 (13:19) Peter & Dave – Going into CER 22:19 (15:19) Robert – Going into LVEA 22:35 (15:35) Robert – Out of LVEA 23:00 (16:00) Turn over to Travis Shift Details: 10/07/2016, Day Shift 15:00 – 23:00 (08:00 –16:00) All times in UTC (PT) Support: Daniel, Peter, Kiwamu, Terra Incoming Operator: Patrick Shift Summary: After commissioners finished working on the REFL9 signal chain through an initial alignment. Locking has been very difficult. First – Trouble with the ISS First Loop. There was an oscillation at 1.6KHz, which was flipping the ISS lock on/off. Kiwamu put the ISS into Manual Mode and was toggling the First Loop on/off until the First Loop came on with no oscillations. This has happened before but not very often and not for some time. Second – When going from DC_READOUT to INCREASE_POWER PI Mode18 would start to ring up very quickly. Twice the lock was broken before I could suppress the ring up. On the third lock, Mode18 started to ring up during RESONANCE. This time was able to damp it before breaking lock, but could not suppress the mode. Spoke with PI Help Desk – Conclusion the mode was rung up past the system’s ability to damp it. The fix was to set the gain to zero and wait for the mode to ring down low enough to where the damping can work. Once things had settled down will bring the gain back on and work with phase to further suppress the mode.
In relation to Sheila's investigation on the increased noise in the aux length loops, I ran BruCO on the loop error signals LSC-PRCL_IN1, LSC-SRCL_IN1, LSC-MICH_IN1.
The BruCo report can be found here:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_srcl_1159781057/
Beside some expected coherences, there are quite some ASC signals that are coherent in the 10 to 100 Hz region. Of course, it might as well be that the angular signals are polluted by the LSC control.
Coherence with IMC WFS below 100Hz is an indication of coherence with HPO jitter. The attached spectra were taking at 22W. Arbitrary units on the PSDs.
In relation to Sheila's investigation on the increased noise in the aux length loops, I ran BruCO on the loop error signals LSC-PRCL_IN1, LSC-SRCL_IN1, LSC-MICH_IN1.
The BruCo report can be found here:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_prcl_1159781057/
Beside some expected coherences, there are quite some ASC signals that are coherent in the 10 to 100 Hz region. Of course, it might as well be that the angular signals are polluted by the LSC control.
Just for now. It's outputing 2M of useless data every minute (since green lights are shuttered for the most part). I'm saving disk space for the cornor station HWS. For those you might care, I took a new reference centroid when the IFO is cool ish with arms locked in green.
1:15pm local Took 21 sec. to overfill CP3 with 1/2 turn open on bypass LLCV. Left bypass exhaust valve open. Next fill due Monday.
Evan, Daniel
17:12:30 UTC Oct 7 2016:
17:16:30 UTC Oct 7 2016:
17:18:30 UTC Oct 7 2016:
17:24:30 UTC Oct 7 2016:
17:32:00 UTC Oct 7 2016:
17:34:30 UTC Oct 7 2016:
18:06:30 UTC Oct 7 2016:
Spectra attached.
Coherence (modulation on)
Using 2600 V/W for the demod gain and transimpedance, and 29 mW of dc PD power, this implies the following AM depths:
I | Q | |
9 MHz | 0.95×10−4 | 2.4×10−4 |
45 MHz | 1.9×10−4 | 8.2×10−4 |
Using 0.22 rad and 0.28 rad for the 9 MHz and 45 MHz modulation depths, this implies the following AM/PM ratios:
I | Q | |
9 MHz | 0.43×10−3 | 1.1×10−3 |
45 MHz | 0.67×10−3 | 2.9×10−3 |
The attachment contains a budget of the expected CARM residual. The in-loop error point is taken from the CM board control signal, as was done previously. Here I used 2600 V/W for the transimpedance and demod gain.
The other measured traces are taken from the REFL9I readback (not from the CM board), so in principle there could be some extra dark noise at the error point from the summing node board or CM board. However, based on the O1 level this is of the same order as the shot noise (so we are not missing a huge amount of extra noise in this estimate).
Attaching earlier RAM plot, this time with informative labels
Here is a time series of REFL LF during the modulation depth reductions that happen during lock acquistion.
During the 9 MHz depth reduction (from 0.22 rad to 0.11 rad), the dc power changes from 4.83(3) mW to 4.27(3) mW. That means that after the modulation depth reduction, 4.08(4) mW of the dc light is from the carrier and 0.19(2) mW of the dc light is from the 9 MHz sideband (this assumes the 45 MHz contribution is negligible).
Note that the dc level is still settling to its final value of ~3.7 mW, so it's possible that these power ratios are evolving during the lock.
Just a quick report. Broadband noise in 200-1000 Hz was also visible at a mid-high input power of 27 W.
I did not insert the cutoff filters in the hard ASC loops. ISS 2nd loop was fully engaged with a gain of 19 dB and the boost on. TCS was held at the lock acquisition settings, i.e. [CO2X CO2Y] = [500 mW 1000 mW]. The period when the interferometer was low-ish noise is in 8:15 - 8:25 UTC which was followed by lockloss due to me failing to handle PI mode 27.
Synopsis -- Not surprisingly, the broadband noise in terms of RIN at the DCPDs seems to grow proportionally to the carrier field amplitude in the interferometer.
[Cross correlated noise in DCPDs]
Here is a plot of cross-correlated noise between OMC DCPDs A and B. DARM loop suppression is removed by a post process.
For comparison, I overlaid the cross correlated spectrum of a 50 W lock which is from Sep 30th (30115). For both data, the OMC DCPD sum current was held at 20 mA by the DARM loop. It is clear that the mid-power lock (27 W in blue) has a slightly lower noise level in 200 Hz - 2 kHz. The high power lock has a much higher noise level above 2 kHz. I attach the plot in fig format as well. The pcal calibration line at 331.9 Hz for the mid-power lock was smaller than the high power lock by 20 %. Qualitatively, this is due to the higher optical gain in the high power lock although the ratio ideally should be sqrt( 27 W / 50 W ) = 36% instead of 20%. Probably this discrepancy can be partly due to the smaller recycling gain for the high power lock.
Now, if one scales the mid-power spectrum so that both the pcal lines have a same height at 331.9 Hz, it gives you the following plot.
The two curves overlap more in 200 Hz- a few kHz. This simply means that the broadband noise scales with the field amplitude of the carrier light circulating the arm cavities. Because the DARM optical gain also scales with the carrier field amplitude in the same way, this unfortunately means that the calibrated displacement noise does not change regardless of the laser power level. This rules out some local electronics pickup/cross-talks, but does not rule out laser noise couplings (jitter, intensity, frequency) or displacement noise.