This morning I measured and fit again the SRCL feed-forward. Measurements attached.

The new feed-forward filter is effective in reducing the SRCL coupling (indeed the old feed-forward was amplifying the SRCL noise in DARM between 10 and 20 Hz) (figure 2)

To improve the feed-forward between 10 and 30 Hz I designed a new AC coupling, with less phase rotation at 10 Hz, and with a band-stop between 0.8 and 1.2 Hz. Using this AC coupling I could fit a good filter down to 10 Hz (figure 1).

The band-stop reduced the feed-forward output at around 1 Hz well below the previous version (figure 4).

Unfortunately, the new feed-forward triggered again an instability that was slowly growing in many ASC signals. This time the instability is not at 1.1 Hz (the BS pitch mode) but at 1.2 Hz, which is exactly the corner frequency of the band-stop. So it seems this instability is not due to a too large control signal exciting a mode, but due to a spurious unstable loop. This makes it much harder to understand whether a given feed-forward is stable or not.

Coherence between DARM and ths ISS second loop out-of-loop sensor is at the 1e-2 level (below a few kHz). Similar coherence with the first loop sensors.

The IMC_LOCK guardian was missing a path from ISS_ON or ISS_DC_COUPLED to LOCKED that opened the ISS second loop.

Now it's been added. The ISC_LOCK DOWN state should request IMC_LOCK to got to LOCKED, and thus open the ISS second loop.

After the earthquake in Greece I thought I was going to be able to recover lock with no problems. But before beginning the lock sequence I accidentally pressed the load button on ISC_LOCK. Briefly after, I tried going through the lock sequence and ISC_LOCK crashed so I restarted the ISC_LOCK guardian. After this, it was obvious that the green alignment did not look good. After attempting initial alignment for a while I noticed that the OPS_OVERVIEW had many red triangles on the screen. I do not know how long the screen was in this state. I figured I would not make things worse as I do not know how to recover from this so I restored the alignment to what it was before the earthquake. I am leaving the interferometer in initial alignment. I apologize in advance to the early morning commissioners if I have caused you any woes. 

Not a huge deal but I changed OFI OSEM input/output matrix for L and increased L damping gain in FM6 of H1:SUS-OFI_M1_DAMP_L from 20 to 4000 because they didn't make sense (and because IFO was down due to EQ).

What was wrong?

OFI OSEM input/output matrix for L were nonsensical, L mostly sensed and actuated on T.  See the first attachment where L was mostly just about 4*T. L and T were perfectly coherent even at noise-dominated frequency.

SD OSEM is sensitive to L as well as a bit of Y(=LF-RT), thus L should be linear combination of SD and LF-RT. In reality L was configured to be mostly LF+RT(=T) with much smaller SD mixed in as shown in the second attachment.

These matrices were set in Jan 2018 (alog 40204).

What was done?

SD sensitivity to YAW is proportional to the position offset of SD OSEM from the longitudinal (i.e. Y-arm direction) center line of the bread board, which seems to be 2.18" according to D0900136.

Similarly LF and RT offset from the X-direction center line of the bread board seem to be 4.38". Due to OSEM locations, the sign of Y sensitivity for SD and LF  are the same.

SD=-L+2.18"*Y

LF=T+4.38"*Y

RT=T-4.38"*Y

L=-SD +(LF-RT)* 2.18/4.38/2 = -SD + 0.249 LF - 0.249 RT.

Actuation math should be the same (if I ignore potential difference between COG and the center of the bread board). 

I changed both of the matrices accordingly. Since there's no good reason for L damping gain (was 200) to be much smaller than T damping (4000) any more, I increased the FM6 ("gain") filter bank in H1:SUS-OFI_M1_DAMP_L from 200 to 4000. In the third attachment, right plot is before increasing the damping gain, left is after, both with a new set of matrices and both during the earthquake.

It seems like Y is mixing into L a bit (look at 1Hz Y resonance), I won't bother to fix it for now.

Here's an updated version of the noise budget with injections made over the last couple of days.

Also attached is a plot of the individual ASC noises, including the soft P injections Hang made from 44800

This noise budget normally relies on the measured cavity pole and optical gain from the Pcal lines, but since they aren't available yet I compared the shot noise estimate to the difference (in quadrature) between the DARM noise and the correlated noise (using the template Geogria updated 44807.  I estimated that kappac = 0.9 at the time of this measurement and the cavity pole is 430 Hz.  (Third attachment)

The other noise traces are up to date, except for the OMC length noise for which I am using the measurement from O2.  

We also measured coupling of HAM1 Hepi excitations to DARM, MICH, SRCL and PRCL.  We will add some plots to the alog tomorrow: there is a contribution of HAM1 X +Y motion to all of these DOFs, but the coupling is not through CHARD.  

We did more DARM noise projection based on f-domain MISO coherence (i.e., linear couplings). The noise showed up in this study are in principle removable, ideally using online FF in real time, or using offline noise subtraction as did by Jenne et al. for O2 data.

This time we studied 3 different freq bands:

    1). 8 ~ 128 Hz (LF), including all the LSC (MICH/SRCL/PRCL/CARM), arm ASC (C/D HARD/SOFT), and jitter (PSL bullseyes & IMC WFS) channels as the witnesses.

    2). 8 ~ 512 Hz (MF), including all the LSC and jitter channels.

    3). 8 ~ 4096 Hz (HF), including all the LSC channels.

The noise projections to DARM are attached for each freq band. Also attached are the MISO coherence with DARM for the HF case (as LSC channels dominates the linear couplings for now), and noise projection for the LSC channels for the HF band, jitter channels for the MF band, and ASC channels for the LF band.

Some observations:

    i), While our current real-time DARM noise is very similar to the post Montana EQ level from 40 to 100 Hz (which I believe Sheila et al will show in more details), there is room for improvement in that band by removing linear couplings.

    ii). Right now SRCL dominates DARM sensitivity below 40 Hz, and it contributes roughly equally as LSC-MICH in the 40-80 Hz region. In the 100-300 Hz range we can still see a significant amount of SRCL in DARM. Thus to improve BNS range, we should definitely improve our SRCL FF.

    iii). A significant amount of frequency noise/CARM is linearly coherent with DARM above 1 kHz. We should fix this excess HF freq noise but in the worst case we can still remove it by doing CARM FF/offline subtraction.

    iv). CHARD Y is the largest contribution for the ASC noise. For other DOFs we are not yet able to see them with the current high SRCL noise.

    v). No significant amount of jitter noise showed up.

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

Details: the data we used for this study were starting from gps 1224541306 for 256 secs. For each FFT we took 1 sec (i.e. 1 Hz BW) of the data with 50% overlaps between adjacent pieces. We had ~ 500 averages for this study, thus we can see coherence down to ~ 1/500 =0.002 level. This further means we can probe linear noise projection to DARM roughly 20 times below its sensitivity.

The analysis code lives in

/ligo/home/hang.yu/Desktop/LSC/DARM_NOISE/darm_coh.ipynb

Hang, TVo

Hang had most of the tools written up to run the spectrograms using jupyter notebook so i helped tune the notch filtering to get the normalized spectrogram of CAL-DELTAL_EXTERNAL_DQ

The first plot shows broadband DARM, and the second plot shows a zoomed in version from 30 to 200 Hz. By eye, there's not an obvious correlation between the amplitude square wave of DB9 modulation depth to DARM, except there's some extra noise at the 57-58 Hz region which might come from the Hartmann sensor sync frequency.  The third plot shows a zoomed-in time version during one of the glitchy times, there's an obvious broadband spike but there is also a long lasting one at the 57-58 Hz that lasts for a few minutes.

Summary

In brief, the ISS second loop could not be engaged because the gain of the FIRST loop was too high, resulting in a large gain peaking at 88 kHz, which made the ISS second loop unstable for high gain or high power. Indeed, the  gain of the first loop was 8 db: increasing the gain to 8.6 dB made the FIRST loop unstable even without the second loop. I reduced the gain to 4 dB and now the ISS second loop transfer function looks ok. I could engage the second loop at 2 W with AC coupling, increase the power to 25 W, DC-couple the second loop and engage three boosts.

I tested once the following procedure

1. go to 2 W input power
2. request ISS_ON in the IMC guardian
3. go to 25 W
4. request ISS_DC_COUPLED, which engages the first two boosts

Below the RIN with 25W, ISS second loop closed, DC-coupled and boosted.

Details

The plot below shows the open loop transfer function of the ISS second loop, at 2 W, with a second loop gain of 20 W. The traces correspond to various gains of the first loop. The gain was originally set to 8 dB, giving a large gain peaking at 88 kHz. The gain is now set to 4 dB, which gives a reasonably smooth transfer function.

Once this issue was fixed, I could engage the ISS second loop and power up to 25 W. I measured the open loop gain of the second loop while powering up. At 25 W I D-coupled the ISS and switched on all three boosts. Open loop gains are shown below.

Some additional final remarks of other things I did today

SLOW SERVO

With the output switch open, the slow reference servo will maintain the board output near zero.
I offloaded the output of the slow offset servo H1:PSL-ISS_SECONDLOOP_REFERENCE_SERVO_OUT16 to the "bottom" offset H1:PSL-ISS_THIRDLOOP_OUTPUT_OFFSET so that the slow offset servo is around zero.

When the second loop will be engaged, the slow offset servo will switch to keeping the diffracted power near the desired value. Therefore the offset H1:PSL-ISS_SECONDLOOP_REFERENCE_DFR_CAL_OFFSET must be set to minus the diffracted power.

AC COUPLING AND PREDICTOR

In this condition, the AC coupling is off, but the "predictor" will update the AC decoupling output following the ISS second loop power, rescaled to the first ISS loop power. Set the gain of the "predictor" normalization H1:PSL-ISS_PD_NORM FM2 so that the output of the predictor normalization is near one (H1:PSL-ISS_PD_NORM_OUT16)

When the ISS second loop input is switched on (with output off) the AC coupling servo starts to work. The bias H1:PSL-ISS_SECONDLOOP_AC_COUPLING_INT_BIAS was adjusted so that the AC output when the AC coupling is off (coming from the predictor) is equal to the average value of the AC output when the AC coupling is on (meaning that H1:PSL-ISS_SECONDLOOP_AC_COUPLING_OUTPUT does not change, in mean value, when toggling the ISS input on and off).

In this configuration, with the ISS second loop input and output open, the input error signals is near zero H1:PSL-ISS_SECONDLOOP_ERR1_MON, and the output is also near zero H1:PSL-ISS_SECONDLOOP_OUTPUT_MON.

I don't understand the use of the AC coupling input offset H1:PSL-ISS_SECONDLOOP_AC_COUPLING_OFFSET

Notes
 

H1:PSL-ISS_SECONDLOOP_AC_COUPLING_INT_BIAS and H1:PSL-ISS_PD_NORM_OUT16 ensures that the predictor works to keep the input error signal near zero, by compensating the sum of the ISS diode signals, when the second loop is open.

even in this condition, there is an input offset in the ISS second board, so if you don't compensate for it, with the output open the board will rail. H1:PSL-ISS_THIRDLOOP_OUTPUT_OFFSET plus H1:PSL-ISS_SECONDLOOP_REFERENCE_SERVO_OUT16 is used in this configuration to keep the board output near zero when the input is near zero. Of course H1:PSL-ISS_SECONDLOOP_ERR2_MON is not zero, since that's afer the addition of the compensation offset.

I have modified a large quantity of models today, as part of ECR E1800304 / FRS 11676. The goal is to provide a front-end way to shut off ISC-related outputs when we have a lockloss, even if some of the EPICs connections are failing (which causes guardian to not be able to execute the full DOWN reset state).

The trigger of lock or not-lock is generated using a new row of the LSC trigger matrix.  That trigger is passed to all of our main IFO suspensions, as well as the ASC and OMC models.  Everywhere the trigger is used, it goes through a ramping code written by JoeB some time ago, so that signals can either be ramped to zero or immediately set to zero (by setting the ramp time to 0 seconds, as usual).  Each of these trigger blocks also has an Enable switch, so that we can chose to bypass use of the trigger for any particular set of outputs (eg, if we want to be triggering the output of the LSC model but not the ASC model, we'd bypass the trigger on the ASC model). 

To enable more flexibility, there are many different locations where the trigger can be used or bypassed. Some of these may seem somewhat redundant, but I wanted to give each site flexibility and also the ability to disable either inputs or outputs of the suspension filter banks. I list the groups here.  For each group, there is only one trigger / ramp that controls them all.  All of these channels should be initialized properly with their ENABLEs set to 0 by default, which should give no net effect when we first install them, so that we can decide which ones we want to utilize.  Each of these also has a monitor channel _IS_RAMPING.

• All LSC dof outputs [controlled by LSC-TRIG_IFO_{TRAMP, ENABLE}] This is ANDed with the old LSC-CONTROL_ENABLE.
• All OMC model LSC outputs to the quads [controlled by OMC-TRIG_LSC_{TRAMP, ENABLE}] This is ANDed with the old LSC-CONTROL_ENABLE.
• All ASC dof outputs (includes the ADS servo outputs, but not the dithers) [controlled by ASC-TRIG_IFO_{TRAMP, ENABLE}]
• All OMC ASC outputs to the OMC, OM1, OM2, OM3 [controlled by OMC-TRIG_ASC_{TRAMP, ENABLE}]
• For all suspensions listed, the LOCK filter banks have triggers, one for the length, and another for the combination of pitch and yaw, for each stage.  Channel names are of the type: SUS-{optic}_{stage}_TRIG_LSC_{TRAMP, ENABLE} and SUS-{optic}_{stage}_TRIG_ASC_{TRAMP, ENABLE}.
  • ITMX, ITMY, ETMX, ETMY:  M0, L1, L2, L3
  • BS, SRM, PRM, SR2, PR2, SR3, PR3: M1, M2, M3
  • IM1, IM2, IM3, IM4, RM1, RM2, OM1, OM2, OM3: M1
  • OMC: M1
  • TMSX, TMSY: M1
• Quad suspensions also have separate triggers on their violin damping outputs [controlled by SUS-{ITMX, ITMY, ETMX, ETMY}_L2_TRIG_VIO_{TRAMP, ENABLE}]

Note in particular the things that I have not given triggers to: the IMC mirrors, or the IMC ASC dof outputs, since we want those to be active separately, and don't want a lockloss to kick the IMC out of lock if it wasn't already going to be. I also did not give triggers to the ADS dithers.  I can add these if we think it's important.  I also did not include any squeezer-related optics, since that is a pretty independent system.  We can give the squeezer suspensions their own trigger if its needed.

I have not yet made any screen modifications (that will be tomorrow, hopefully).

When we are ready to implement this, we will need to restart:

• h1lsc (first, since it has the IPC sender)
• h1asc
• h1omc
• h1susitmx
• h1susitmy
• h1susetmx
• h1susetmy
• h1susbs
• h1susim
• h1sustmsx
• h1sustmsy
• h1sushtts
• h1susomc
• h1sussrm
• h1susprm
• h1suspr2
• h1suspr3
• h1sussr2
• h1sussr3

For LLO, we will need to svn-up to get all of the modifications to the suspension library parts, then add the IPC receiver to the top model for each sus.  We will also need to hand copy the modifications to the LSC, ASC and OMC models.

EDIT: I have compiled all of the models, but not installed.  h1asc has an error, which I will work on debugging in the morning.

TITLE: 10/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioning continues through elevated microseism. BRSX seems like it may drift back off after Jim's rebalancing today. Nighttime commissioners should keep an eye on DIAN_MAIN for any notifications, and then bring the SEI_CONFIG to WINDY_NO_BRSX.
LOG:

1526 Vanessa to LVEA to start a cleaning
1545 Jim to EX to rebalance the BRS
1630 Vanessa out of LVEA and heading to the ends to clean main areas
1641 Jeff B to LVEA to take pictures of the ITMs
1650 Jim back from EX
1706 Jonathan to H2 CDS room and disconnecting phone
1707 Peter to LVEA to join Jeff B
1736 Terry to LVEA to ISCT6
1806 H2 phones back online
1827 Ed to LVEA to grab alignment laser
1835 Ed, Peter, Jeff B
2000 Terry out
2058 Terry back in

I realized today that our updates to the inverse sensing FOTON filter would yield slightly incorrect DARM FOM curve in DTT, especially in the ~5 kHz range. This is because the DARM FOM DTT template has a calibration that corrects for "warping" from a correct inverse sensing filter compared to what we are able to install in the front end using an IIR filter. I updated the H1_DARM_FOM.xml file with this new calibration and committed the changes to the SVN.

This curve was computed using the following script located in the calibration SVN:
aligocalibration/trunk/Runs/O3/H1/Scripts/darm_FOM_calibration.py

Attached is a figure showing comparison with the old curve (with slightly incorrect calibration) to the new curve (with correct calibration).

Also attached is the current DARM FOM DTT template calibration transfer function that is now being applied to H1:CAL_DELTAL_EXTERNAL_DQ (columns are frequency, magnitude (dB), phase (deg.)).

Lilli S., Jeff K., Evan G.

We processed the measurements made in LHO aLOG 44766 using an MCMC to fit the data for the unknown parameters. Below are the maximum a postiori values and their 1-sigma quantiles.

Parameter                              | Quantiles (0.15, 0.50, 0.84)
---------------------------------------------------------------------
Cavity gain, H_c (ct/m)                | 3.309e+06, 3.321e+06, 3.332e+06
Cavity pole, f_cc (Hz)                 |  419, 421.7, 424.6
Detuned SRC spring frequency, f_s (Hz) | 5.54, 7.037, 8.212
Detuned SRC spring quality factor, Q_s | 66.63, 37.57, 21.87
Residual time delay, tau_c (usec)      | -3.887, -2.821, -1.734

The results are typical for what we now expect for an O3 aLIGO interferometer.

Attached are the measurement compared against the best fit model values and the corner plot output from the MCMC analysis (first and second attachments).

The final attachment is an updated Gaussian Process Regression plot showing the residuals from the Oct. 12 measurement and the Oct. 23 measurement propagated back to the Oct. 12th time. We would normally propagate the values using time dependent calibration factors derived from the calibration lines, but the front end calculation of these values is still in disarray. Since we couldn't use these values, we simply made MCMC fits to each measurement and divided out the changes that are caused because of drifts in alignment. The two sets of residuals (data points) are used in a Gaussian Process Regression algorithm to search for and quantify unknown systematic errors. The best fit using the GPR algorithm is shown as a dark line with the 1-sigma uncertainty given by the shaded region We expect that with further, higher precision measurements, the uncertainty on the GPR will be reduced.

Evan Goetz, Lilli Sun

The DARM loop sign conventions and the definitions of open loop gain, closed loop gain, and response functions are documented here -> T1800456

We revisited the signs in the DARM control loop and the response functions. In O2, we did all actuation in Y arm. For O3 the TST actuation was switched to X arm. Hence there are two separate sign issues: (1) is the actuation in UIM/PUM (push) or TST (pull), and (2) is it in X (+) or Y (-) arm. We had too many sign definitions in the code. The arm signs and the output matrix signs can be combined together. This has been fixed in actuation.py

By definition, we have G=A*D*C and the negative feedback "-" is not included in "A". We fixed the code to keep things consistent with this convention. Correspondingly, we have open loop gain = -G (fixed in the open loop gain processing script), closed loop gain = -G/(1+G), response function R = (1+G)/C (fixed in computeDARM and RRNom).

After all these changes, our model matches the measurements. The phase at unit gain frequency is near -180 deg (see meas vs model plot).

We processed the new calibration measurements taken by Jeff on Oct 23, and ran GPR using the both sets of measurements (Oct 12 & 23) after the model files are updated with MAP values.

At last, we tested RRNom with reference model. The plots do not look good because the measurements we have are poor (see corresponding sensing corner plot and actuation GPRs).

There's a comb visible in recent DARM data at multiples of 0.996795 Hz (last digit uncertain). This is suspiciously similar to a comb seen before O2 (then measured at 0.996798 Hz), which was due to the HWS. Just as before, the comb appears strongly in corner station magnetometer channels.

I've attached an image showing teeth of the comb below 100 Hz (Oct 24, ~50 minutes starting at 9:30 UTC). It is also visible in other lock stretches within the past few weeks. When this comb was seen before, it coupled only intermittently to DARM; its presence seems steadier now.

Relevant past alogs:

• September 2016 post on comb updates (see first heading, and second comment)
• HWS cameras at X and Y were placed on a separate power supply October 25, 2016. This got rid of the comb in magnetometer channels, and it wasn't seen in DARM again until now, as far as I can tell.
• Potentially related recent thread about 57 Hz comb with an HWS connection

[Craig Hang TVo Rana Danny Keita Georgia]

Following up on alog 44781, we had a look at the OMC DCPD cross-correlation as a function of RF9 modulation depth, using Kiwamu’s handy DCPD cross correlation infrastructure and DTT template (35156, T1700131). The cross-correlation allows us to look below the sensing noise of the OMC DCPDs and the photon shot noise.

In the first attachment, the brown and dark green traces show the DARM and cross-correlated spectra before the RF9 modulation depth decrease. Above 100 Hz the cross-correlated noise is below the DARM noise, indicating that we are limited by uncorrelated noise, eg photon shot noise, at these frequencies.

We used a Craig modification on Jenne’s script to turn the RF9 modulation depth down by 6dB for 10 minutes. Surprisingly, it looked like we had a significant reduction of noise in the bucket, from ~100 to 500 Hz in both the DARM and cross-correlated spectra, shown in blue and red, with no significant change to the noise above 500Hz. However when we brought the modulation depth back up the noise seemed to remain closer to the before-modulation-depth reduction level.

In the next lock stretch it seemed like the noise in the bucket crept back up to the original level. The two pale green traces in the right plot are cross correlation spectra from different times in the next lock where the RF modulation was not changed (03:47UTC and 04:30UTC). Similar behaviour was seen in the DARM spectrum, omitted from the plot for clarity. The second attachment shows the DARM BLRMS while we changed the RF9 modulation depth,  this also has the timestamps for this test.

Before generating these cross-correlated spectra I updated normalisation and inverse sensing filters in the H1:CAL-CS_DARM_ERR_NULL filters to match the H1:CAL-CS_DARM_ERR. That is, I copied the O3_D2N and O3gain filter banks to the NULL channel. I have not updated the DTT frequency domain calibration (a transfer function in the templates calibration), and am still using the calibration from 2017.

Other locking notes:

DARM BLRMS - Added 57 Hz and 114 Hz notches to the relevant DARM BLRMS filters (found in sitemap>LSC>OAF Calib>OAF BLRMS>RBP1-5) to get rid of the peak which we identified as the ITM HWSs. These notches removed the ~30 minutes period sinusoid seen in the BLRMS 3 and 4, and its harmonic in BLRMS5.

Glitches - After Hang implemented his DHARD PIT mircoseismic filter (44801) the regular glitches we were seeing in DARM are less frequent and less severe, compare locks before and after 1224468886.

Danny, TJ, Georgia, TVo

Big ups to Sheila for running our measurement after ISC was finished with their work for the night.

Yesterday Georgia and Danny put in an iris on ITMX to crop out a prompt reflected beam from an in-chamber lens so that we can try to compare the spherical power on both ITMX and ITMY HWS when injecting 6 Watts of power into the ring heaters (3 top, 3 bottom):

Note that there is still a bit of clipping on ITMX on the top right corner.  Using the results of a COMSOL model here, where it quotes

Model Prediction
HWS ITMX Measured
HWS ITMY Measured