h1susey has crashed. Similar to h1lsc0 this morning it looks like the models are still running and the suspensions are still being damped. We have lost DAQ data from this machine and EPICS monitoring/controls.

If we need to restart this system, please call me on my cell phone and I can do this remotely.

Continuing the activity described in 44366, I measured the response of REFL WFS in yaw to CHARD, INP1, PRC1 and PRC2. Here's the sensing matrix, measured with a line at 8.5 Hz (CHARD ampl. 1.0, INP1 ampl. 1e6, PRC1 ampl. 0.01, PRC2 ampl. 0.3). The units are REFL_WFS units / ASC filter bank output. Therefore a direct comparison of the different degrees of freedom is difficult, since the actuator response is different in all cases (I can't see the excitation in the OPLEV signals, so I don't have a calibrated motion sensor).

If we use this matrix and the ASC yaw input matrix currently in use for CHARD and INP1, we get the following response

This is quite different from the sensing matrix currently in use. I plugged those numbers into the CHARD_Y_B row of th input matrix, and measured the response to a CHARD sweep. If the new combination and the old one were equally sensitive, one would expect that CHARD_Y_B_IN1 / CHARD_Y_IN2 = CHARD_Y_IN1 / CHARD_Y_IN2 and that CHARD_Y_B_IN1 / CHARD_Y_IN1 = 1. This is not the case... Actually the new combination shows even less phase margin than the old combination. So the CHARD_Y sensing mystery deepens.

I left the IFO locked in DC_READOUT, with a CHARD_Y sweep sine going, measuring the coupling to all other yaw loops.

h1lsc0 general core looks like it has crashed. The models continue to run. No IPC problems on receiving models, no DAQ problems outside of h1lsc0.

Gabrielle is on site and is taking a picture of h1lsc0's console before we start the recovery process.

The IFO is locked at a state that looks like PREP_DC_READOUT_TRANSITION, but:

1. many GUARDIANS are in error, they can't access most of the EPICS channels (see fig. 1)
2. the CDS screen shows connection problems (white fields) in H1IOPLSC0, H1OMC, H1LSC, H1LSCAUX, H1OMCPI, H1SQZ (see fig. 2)
3. All MEDM screens related to LSC are whited out (see fig. 3)

I can't find any instruction on how to fix this in the wiki...

In the attached plot we show the refl pd power as a function of power recycling gain (PRG). Here the x-axis is the PRG, the y-axis is the refl PD power, normalized by the power when the carrier is anti-resonant in CARM & PRC. In generating the plot we vary the arm losses as a parameter to compute the PRG and refl power simultaneously.

Georgia, TVo

We walked the picomotors on the periscope for ITMX HWS in order to get rid of the prompt reflection and reduce the clipping on the baffles.  Attached are the before and after photos.  

During about 30 minutes of DC Readout when no transient heating is being applied so we expect very small changes in spherical power as a function of time, the ITMX HWS is still noisier than ITMY HWS by about a factor of 3 just looking at the time series.  This is better than before when we had a prompt reflection that was screwing up the fitting for the spherical power, maybe we can go back to the same alignment but digitally subtract the beam and keep the useful HWS beam, this is in progress.

After this alignment adjustment the noise got better but attached are the gradient plots for about 5 minutes for both HWS, it show that ITMY sees much less optical path distortion than ITMX and there seems to be a very large gradient vector for ITMX around coordinates=[+0.01, +0.05].  At first glance, this may be dust somewhere in the optical path so we'll investigate the optical table with an ion gun.  This "dot" remains persistent for multiple time frames and was present both before and after the pico-ing

There is also a large amount of contours in the upper left hand section, which looks like it's due to the single gradient arrow at coordinates=[-0.1,+0.75]. It is not obvious the root cause since it doesn't look like a normal fringe pattern and we only have one real data point there but we can try to pico away from the left hand side of the baffle and see if this improves the contour plots.

Jeff K., Evan G.

Summary:
We've reprocessed the measurement transfer function sweeps taken yesterday, and have found the coupled cavity pole was measured to be 429 Hz +/- 6 Hz, quite consistent with computing the pole from the arm reflectivities reported in galaxy (and use Eq 12 from T1500325) -- 433 Hz. We've since identified that Craig's single pole MCMC model (see LHO aLOG 44351) did not include detuned spring, and had a flaw in its log likelihood function resulting in an incorrect fit. The other physical parameters are fit with this process as well and described in the details below.

Details:
We used the new pyDARM infrastructure that has been developed over the last several months to analyze the transfer function sweeps taken yesterday evening. These measurements were quick 'n dirty; leading into and during an observing run, we would have more careful measurements to reduce any uncertainty. So we expect some reduction in uncertainty in future measurements.

pyDARM can perform MCMC fitting to the physical parameters of the coupled cavity optical response. The results of that fit are listed below:

Optical Gain                K_C         [ct/m]        3.552e6 +/- 3e4
Couple Cav. Pole Freq.      f_c         [Hz]          429 +/- 6
Residual Sensing Delay      tau_C       [us]          2.75 +/-1.7
SRC Detuning Spring Freq.   f_s         [Hz]          5.815 +6/-4
Spring Qual. Factor         Q_s         [ ]           4.2 +/- 6.5


A Gaussian process regression was used to establish potential unknown systematic errors, but this is merely for practice. We know
   - This was a quick 'n dirty measurement with poor uncertainty and limited frequency range, and
   - This is only one measurement, and we really want several to many measurements to nail down real unknown systematics

Here's the resulting design string we have put into Foton and loaded into the CAL-CS model (in the H1:CAL-CS_DARM_ERR filter bank) to improve on what was installed yesterday
    SRCD2N (as "O3_D2N" in FM9): zpk([428.9869;5.1756;-6.5327],[0.1;0.1;7000],1,"n")gain(3380.64)
    Gain (as "O3Gain" in FM10): gain(2.815e-07)

We fit these results with the following code:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/process_sensingmeas_20181004.py

I injected a line at 8.5 Hz in both CHARD yaw (amplitude 1.0) and INP1 yaw (amplitude 3e6) and measured the response of the REFL WFS (in units of WFS / loop output)

The RF9 signals have a slightly better SNR than the RF45 signals, so I inverted the 2x2 RF9 matrix (and rescaled so that the response should be the same as the input matrix in guardian)

For comparison, now we are using the following input matrix:

This matrix has the same response as the new ones for the diagonal CHARD > CHARD and INP1 > INP1 elements, but the off diagonal element from INP1 to CHARD is much larger.

Finally, to have a complete picture we should measure the PRC1 and PRC2 response in the REFL WFS.

I've updated the HWS code so that the gradient field data is saved as HDF5 files instead of PICKLE files. I also updated the wavefront viewing utility so that it correctly extracts data from the new HDF5 files. I tested this at CIT on the HWS system and it worked pretty seemlessly.

Per work-permit 7857, I pulled the latest version of the code from the GIT repo on H1HWSEX and tried running it on that machine. It didn’t work because the H5PY package isn’t installed. I didn't have time to fix this issue so I reverted the version of the code to the earlier (working) version on GIT and restarted the HWS code.

Updating files:

Failure during execution:

Restoring earlier version of HWS_code

I created an improved script to analyze the Optical Spectrum Analyzer data [the script can be found in /opt/rtcds/userapps/release/isc/h1/scripts/osa.py]

In summary:

• the script grabs the OSA data and performs two kind of peak extraction
  • simply look for the upper and lower 45 MHz sidebands and integrate the power around them. Then look for the highest peak around the mid point of the two sidebands, call it the carrier, and integrate all the power.
  • using the 45MHz sidebands, calibrate the OSA scan in units of modulation frequency, and then fit peaks at +/- 45 MHz, +/- 9 MHz and 0 MHz, to extract also the 9 MHz sidebands.
• the script can save the processed peak amplitudes to a file, with the GPS time
• the script can also save a second-long average of the OSA scan to a folder, for future post-processing
• the script can read the saved scans and reprocess them offline

When running online, the script produces a plot like the one below, taken during a power up.

The two left panels contains the time traces of the peak powers. The top panel shows the "simple" peak reconstruction as explained above (simply identify the 45MHz peaks, integrate their power, find the largest peak in the middle and integrate its power). The bottom panel instead shows the more "advanced" reconstruction of the 45 MHz, 9 MHz and carrier peaks, by fitting peaks at the correct frequencies.

The right panel shows the latest averaged scan (blue dots and trace) plus some fitting and peak identification traces: the red, green and magenta X show the peaks used for the "simple" reconstruction (time traces in the top left panel); the dashed curves show the individual fits to the sidebands and carrier peaks (time traces in the bottom left panel); the black trace shows the sum of all fitted sideband and carrier peaks.

The 9MHz sidebands are very close to the carrier peak. When at low power, it's hard to resolve them. Even at 10W, they barely make bumps on the side of the carrier peak. So their power measurement has a quite large uncertainty and should be taken with care.

Our DARM shot noise calibration has been off by a factor of 4.  I took a PCAL to DARM sweep and DARM OLG and got a rough measurement of the DARM optical plant while locked at 10 W.  Templates saved in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/.

I then fit a simple pole model to the measurement:
Gain:    3.642e6 cts/m   (cts are DARM error cts)
Pole:    381.83  Hz

Our expected DARM pole with 32.3% SRM transmission is 433 Hz, so we are 12% low.  Our SRC is poorly aligned, though, and the SRC ASC loops were off during this measurement.  According to Hang's SRC misalignment simulation, if SRM misalignment was totally responsible for this low of a DARM pole, the SRM would be far more than 10 microradians misaligned, which is probably not the case.  Another culprit could be ITM differential lensing, which is high for us right now.  Together these could explain our measured DARM pole.

I added new filters in the CAL-CS_DARM_ERR filter module to put our latest inverse sensing calibration into the front end:
O3_D2N: zpk([382.0;6.7496;-7.0660],[0.1;0.1;7000],1,"n")gain(4768.4)
O3Gain: gain(2.7473e-07)

We have a dip at 180 Hz because we haven't updated the control signal calibration yet.

Edit: Also interesting is jitter at 300-350 Hz appears to be reduced.

Craig, Sheila, Georgia

This evening we had a fast lockloss from 10W. The IMC did not lose lock however we saw on the beam on the reference cavity reflection and transmission cameras jiggling at something like 3Hz, as if the ref cav was swinging around.

We ran the lockloss tool and included some PSL channels; sure enough see a 3Hz oscillation in the ref cav transmission and reflection, starting 3 seconds before the lockloss. The oscillation is just visible in the IMC-F, but we don't see it in the mixer, vco, or eom monitors (see bottom two rows of plots in the attachment).

Maybe this is a clue for our past fast locklosses?

We tested again the digital compensation of the Sidles-Sigg torque at 10 W. 

========================================================

For yaw the subtraction was pretty successful. Please see the first attached image.

The cyan trace is the DHARD YAW OLTF measured at 2 W.

The pink is the OLTF measured at 10 W without any digital subtraction. We can see the OLTF changes as the radiation torque modifies the plant.

Lastly the blue is the OLTF for DHARD YAW still measured at 10 W, but this time with a digital path to create a torque canceling the radiation torque from the Sidles-Sigg effect. It successfully reduced the OLTF to look like the 2 W one. The gain for the subtraction at 10 W is -0.8, and we expect it to scale roughly linearly with respect to the arm circulating power.

========================================================

Although yaw was successful, pitch was not. As we tune the gain for the subtraction path we saw in the DHARD PIT error peak a peak showing up at ~ 0.8 Hz or so, consistent with the main resonance frequency shifted by the radiation pressure. The same peak did not show up if we did not turning on the compensation, indicating it should be suppressed by the ctrl loop. Thus we suspect the original of the peak was due to I poorly measured the sus plant and the fitted main resonance peak was slightly off compared to the real one. As we subtract two resonant peaks with slightly shifted frequencies, we created a sharp zero in the OLTF. The peak then caused strong gain peaking in the closed loop system.

The solution is therefore to take a more careful measurement of both the L2 torque to L3 pitch, and the L3 torque to L3 pitch suspension plants.