New problem?  This is showing that it has shut off.  This is very recent and will show up as a pressure increase soon if it is real -> I will monitor and make comment to this entry when data confirms or refutes.

Tonight we power up to 20 watts and were locked for 5 hours.

I measured the CARM OLG (UGF ~ 15kHz) and error spectrum from 0.5 Hz to 5 MHz in response to Stefan and Hang looking for CARM saturations. (PDFs 1 and 2)
They may have been correct to worry: the noise is worst at 100 kHz, a full factor of 10 above where it is at 8 kHz, with peaks a factor of 10 above that.  I'll run some RMS calculations later, but high frequency definitely dominates this spectrum.  We'll need to think about the saturation limits of the common mode board, and the kind of signals we are sending through it to control the laser.

I also ran some bandlimited frequency noise injections with different DARM offsets.  I found that as I reduced the DARM offset, the frequency noise coupling to DARM got worse.  (PNG 1)
This result was counterintuitive to me.  It makes sense for the high frequency noise around 4.1 kHz which masks the OMC dither to cause the low frequency DARM noise to increase with reduced DARM offset, since there is less light in the OMC. But I would have expected the linear Freq to DARM coupling to decrease with reduced DARM offset.  
This prompted me to run a suite of injections which will be analyzed at a later date.

Summary:

We were able to lock the squeezing angle using the 3MHz signal from the OMC DCPD's, and we have caused a few lockloses.  We have found that our locking scheme is introducing a lot of noise, so our next step is to lock the OPO length to the laser frequency.  

Locklosses:

In our first attempt we used the interferometer locked at 2W DC readout to look for the LO error signal.  We caused a lockloss then, and so we then changed to working with the interferometer locked on RF and the OMC locked.  We caused a couple of other locklosses this afternoon, one when the interferometer was locked on RF and the OPO became unlocked with the beam diverter open.  After this we added closing the beam diverter to the OPO guardian DOWN state, and the state CHECK_EOM (which we enter when the TTFSS EOM is railed).  

After successfully locking the squeezer angle, we transitioned to DC readout.  When we attempted to close the beam diverter we lost lock, which we also don't understand.  

We have been injecting ~10uW of CLF (measured on SQZT6), which gives us about 10 dBm of RF on the 3MHz demod.  We are wondering if this is too much and might be part of our lockloss problems.  We tried reducing it by a factor of 2.  

Locking:

Nutsinee will post details of the squeezing angle lock configuration that we used tonight, even though we don't plan to keep using this scheme. 

The basic steps:

• allow the laser temperature servo to bring the beatnote close to the correct frequency. (OPO guardian in down state)
• Lock the squeezer laser to the OPO using the TTFSS (OPO guardian to OPO_LOCKED_CLF)
• Lock the CLF using it's guardian.  
• We then could see that the frequency of the 3 MHz sidebands were not quite right.  We wrote an epics servo, which zeros the difference between the squeezer vs PSL sample (ref cavity) beatnote and twice the IMC VCO frequency, using the timing system frequency readbacks (which update once per second).  This is currently in the guardian called SQZ_PLL in a state called CHECK_BEATNOTE_2, but it will be moved somewhere else and given a more descriptive name.  This can hold us within 100kHz of the correct frequency.  
• We sent the 3MHz signal to both the OPO PZT and the additive offset of the TTFSS.  The additive offset was needed because of a large peak in the noise at around 1 kHz, which is similar to what was seen with the homodyne locking.  Because our locking scheme where the laser follows the OPO (rather than the other way around) introduces a lot of noise, especially at high frequencies, we have a lot of phase noise which means that we need a bandwidth higher than we can get with the PZT only to lock the squeezing angle.  For this reason we introduce an offset in the OPO PDH locking, which allowed us to lock but is obviously terrible. 
• Injecting squeezing in the IFO with this situation resulted in adding a lot of noise.  (See first attachment)

Uncontrolled squeezing:

• The interesting thing is that when we left the beam diverter open but blocked the CLF field and let the squeezing angle rotate, it actually rotates slowly and the large added noise is gone. The second attachment shows the same reference as the first, but with two traces captured with 4 exponential averages at 1Hz, 75% overlap, one showing close to the highest noise that we saw and one showing close to the lowest noise that we saw.  This seems like squeezing and anti-squeezing based on how flat the noise is, but there are two things that are surprising.  While it might be possible that this isn't anti-squeezing at all, it continued for more than 10 minutes without drifting away.  (We were sitting with CLF blocked and the beam diverter open from 4:45 to 4:55, with the OPO locked and the slow servo keeping it's frequency approximately correct.)
  • The level of anti-squeezing seems too high.  Looking between 1100Hz and 11400 Hz, this is almost 17dB of anti-squeezing.  Nutsinee measured the non linear gain to be 3.6, so with our expected total efficiency of 80%, we would expect at most 8dB of anti-squeezing.  (I know, this sounds like I am making a factor of 2 mistake, but I don't think I am.  I'm attaching the dtt file and my script in case anyone wants to double check.)  You might think that the extra noise we see is just some additional noise that we are adding with the squeezer other than anti-squeezing, but at times the noise level drifts down to just a few dB above shot noise. 
  • This squeezing angle is rotating slowly.  With a nonlinear gain of 3.7 and the efficiency of 80%, this would mean that over the 2 seconds of the low noise measurement the squeezing angle only rotated by about 610 mrad, which would be about 100nm of path length change.   We should compare this with the calibrated squeezing angle error signal which Nutsinee will post, but it seems strange that we needed 10's of kHz bandwidth to lock the squeezing angle with  such a slowly drifting system.  

J. Kissel

Now armed with a set of DARM loop model parameters that accurately predict the DARM Open Loop Gain transfer function (see LHO aLOG 45726), we can update the reference model values at calibration line frequencies, colloquially referred to as simply the "EPICS records" by the CAL team. These facilitate the calculation of time-dependent correction factors (see T1700106). I've also made sure that all demodulating oscillators are on, running, and at the correct amplitude.

For consumption by the GDS and SLM tool team who need these values as well, I've committed these new records to 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/CALCS_FE/epicsrecords_H1_20181205.txt
and attach them here for convenience.

I've generated these EPICS records with the following model parameter set,
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/modelparams_H1_20181205.py
and the following script
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE/createEPICS_for_20181205.py

I'm a little bit nervous about the systematic error in these EPICs records, namely:
    (1) We haven't updated the sensing function "ERR" filter, so we're still using the 2018-10-04 model for the sensing function.
    (2) We haven't updated the actuator replica chain to match the updated actuation strength for the ESD after the bias reduction, but maybe we might be getting away with it, because the replica L3 / TST DRIVE_ALIGN gain is still set at -40, when the real thing is -80, and the actuator strength is still the 4.505e-12 N/ct when the real thing is 2.294e-12. 
    (3) The whole system hasn't worked since the upgrade to split kappa_PU into kappa_P and kappa_U. # details
but we'll see.

J. Kissel

While trying to ponder the mysteries as to why the time-dependent correction factor calculations aren't working, I made a few minor clarifying modifications and bug fixes to the line demod screens. Attached are screen shots. They've been committed to 
    /opt/rtcds/userapps/release/cal/common/medm/CAL_CS_TDEP_SUS_LINE.adl
    /opt/rtcds/userapps/release/cal/common/medm/CAL_CS_TDEP_PCAL_LINE.adl
L1 can update at their leisure.

Here is a table of the most recent 30W (or similar) locklosses, and what we could find so far:

1228172266   25W
                       This was a radiation pressure compensation instability that hit us even after going back down to 25W from 30W. We believe Hang's new gain table (alog 45750) should prevent that now.
1228198761   30W
                       POP_LF starts dropping away 2 seconds before lock-loss (and REFL_LF starts rising)
                       OMC length locking loop shows an oscillation for the last 15 seconds
                       REFL_RIN sees a burst every ~8sec (microseism). All LSC signals also show significant microseism motion.
                       This lock has the boost10W filters in the ASC HARD loops off.
1228201480   30W
                       PRC2Y has a large excursion. Not clear whether it is a runaway.
                       13Hz oscillation visible in SCRL/MICH/PRCL/REFL RIN in REFL_RIN it looks like a sawtooth
1228203545   30W
                       ASC looks perfectly fine. 
                       POP90 increases 2 seconds before lockloss. POP18 start dropping at the same time.
1228205888   28W
                       ASC looks perfectly fine. 
1228247359   30W
                       0.5-ish Hz ring-up in ASC: CHARD_Y, CSOFT_P/Y

Given that a number of them seem to suggest a fast CARM loop problem, we also looked at the CM and IMC boards. Note that during POWER-UP we lower the gain at the IMC board output (MCL gain and FAST gain), so the signals through the board increase. However, we looked at the read-backs - all signals are less than 1V. But we should still check for high-frequency saturations.

S. Ballmer, J. Kissel

Using the data from Marc's independent bench-top measurements of the new OMC DCPD Whitening Chassis (LHO aLOG 42361; upgraded to swap out the 2nd whitening stage for a low-pass filter), I've finally fit*** the response of the three stages and updated the digital compensation. Recall there are high frequency poles (> 5 kHz) that we do not compensate (but do have non-negligible phase impact below 1 kHz, so we need to compensate for them in the a-causal low-latency pipeline). I did not formally fit these.

Check out the last three plots of the attached for how much the compensation changed, but the message is that at ~100 Hz, depending on the stage and channel, there's as much as a 1-3 % change per stage.
Remember, we've typically only been using the 1st stage, so the biggest change is the 3% decrease in DCPD A's compensation. This (I believe; math to follow) means a ~3% decrease in BNS range.

We should:
(a) Now repeat Stefan's measurement of the DCPD balance, updating the DCPD balance matrix, (see LHO aLOG 45734)
(b) Remeasure this whitening chassis in-situ in order to 
    (i) improve the data quality on the DCPD measurement, and 
    (ii) better fit (especially the uncompensated) the poles and zeros, similar to Kiwamu's methods in LHO aLOG 28087.

*** The data quality of some of the measurements are poor (maybe some sort of export bug), so I just quickly fit the TFs by hand, and ignored learning new or shaking off the bit rot of old fitting code. The data analysis script lives here:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/plot_omcdcpdwhiteningmods_20180604.m

Design strings for the new compensation:
DCPD A
    ST1: zpk([10.42],[0.993],0.975,"n")
    ST2: zpk([52.7;  35.448 + 35.263i; 35.448 - 35.263i; 353.55 + 353.55i; 353.55 - 353.55i], 
             [531.0; 35.355 + 35.355i; 35.355 - 35.355i; 354.48 + 352.63i; 354.48 - 352.63i],-0.9995,"n")
    ST3: zpk([10.33],[0.894],1.1,"n")

DCPD
    ST1: zpk([10.135],[0.966],0.975,"n")
    ST2: zpk([52.32; 35.448 + 35.263i; 35.448 - 35.263i; 353.55 + 353.55i; 353.55 - 353.55i], 
             [527.2; 35.355 + 35.355i; 35.355 - 35.355i; 354.48 + 352.63i; 354.48 - 352.63i],-1.0004,"n")
    ST3: zpk([10.445],[0.896],1.11,"n")
The extra complex pairs of poles and zeros in the design for the ST2 (new low passes) are to take out a small wiggle at about 50 and 500 Hz that the single pole compensation couldn't fix. Also remember that this low pass dubiously does in fact have a sign flip, which is compensated for here.

Looked at Coherence between the Cartesian DOFs of the L4C [X RX RY & Z] and many ASC & LSC channels along the REFL_A & B path.  Looked during the 30 or so minute long 80Mpsec lock last night [11:03 utc 7 Dec]

1) Essentially everything is coherent with all DOFs at the useism but the X much less so than all the verticals.

2) Outside of the secondary microseism frequencies, ASC_DC1_P has the most presence seen in all L4C DOFs from <2hz thru 8+hz.

3) PRC2_P & Y show up in the vertical L4C DOFs from 6 & 10hz.

4) There is a notable lines for POP_A_RF9_I/L4C_Z at 1.47hz.

** Likely more of interest probably already seen/know to many.

Attached are the DDT Coherence plots: The first has the X DOF standouts at the bottom and the Z DOFs (essentially all) in the upper two plots.

The second attachment has the TILT coherences in four panels; these basically show the same as the Z (maybe makes sense) with the Z coherence showing up in a few more channels than the Tilts, for example DC2.

18:30 Kyle to HAM1

18:45 Kyle & Chandra to MY

18:45 Betsy & Travis to LVEA

22:45 Gerardo Kyle to MY

20:00 Nutsinee and others start going out to ISCT6

I know Arnaud has tried this long ago, but I've been meaning to try reducing SRCL motion by sending signal from ground STS2 Z to the HAM4 Y sensor correction path.  I tried this in June of 2017, but had limited time and the microseism was really low. Yesterday, while the IFO was locked and the commissioners were at a meeting, I was able to collect the tfs I needed to design the filter and install it. I found that it worked, but I did some more tweaks today and I have something I think we should try.

First attached plot is one of my design plots. The solid blue trace is the ratio of two transfer functions, SRCL/GND_Z and SRCL/HAM4_DRIVE. The solid gold and red traces are a couple of attempts to fit it. The dashed lines are estimates of the suppression for each filter (i.e 1 + fit filter / meas tf ratio).

My second plot is the before/after SRCL to GND Z transfer function, red and blue are with the sensor correction on, green and brown are with it off, you can see between .1-.3 there is less SRCL length for GND Z motion.

Third plot are the asds for the different measurements, blue, red and pink are the SRM M3 drive, CAL SRCL and ITMY GND Z with the sensor correction off, brown, green and light blue are with the sensor correction on. Most of the improvement is still between .1-.3hz, the SRM drive is reduced by almost a factor of 10, I think most of the difference below .1hz is due to less tilt at the chamber. 

I would like to leave this on, but if people are worried this is screwing stuff up, ramping H1:ISI-HAM4_SENSCOR_GND_STS_Y_WNR_GAIN to 0 will shut it off, i.e. typing in a terminal:

caput H1:ISI-HAM4_SENSCOR_GND_STS_Y_WNR_GAIN 0

will turn it off.

• Initial alignment, no problems after IFO had cooled down from TCS work.
• Tried some PRMI to DRMI (alog 45756) since DRMI didn't want to catch.
• Locked, increased power to 28W, sat there for several minutes. Had opened SRC ASC loops, Hang was adjusting the rad press comp gains, Danny put TCS CO2s to new values found last night.  Other than that, no adjustments to configuration (ISS was never DC coupled during this lock).  Some low frequency angular something blew the lock, not a fast lockloss. 

[Jenne, Stefan]

The DRMI acquisition has been frustrating enough lately that I spent a little time trying to get the PRMI to DRMI transition to work again.  Middling success, but not enough to code it up yet.

Here's what semi-worked:

Lock PRMI.  Put in 2500 count MICH input offset, to move to a gray fringe.  Remove SRM's pitch misalignment, leaving the 1290 urad yaw misalignment.  Walk the SRM yaw misalignment to 400 urad misalignment.  At this point you can start to see the fringing on the AS camera.  Move the SRM a little closer, to about 300 urad.  Zero the SRCL1 gain (noting its nominal value of -30 for DRMI acquisition), and enable the input and output.  Ramp SRCL1 gain to -1, then -3.  Bring SRM yaw misalignment down in steps of 20 urad. 

Once, this worked, and we had a SRCL lock with SRM still misaligned in yaw by 270 urad, and once we lost lock.  We should try again some day, starting with this knowledge.

I calibrated the DARM offset at 20 watts input power.  The calibration of the H1:OMC-READOUT_X0_OFFSET channel counts into picometers is 0.636 pm/cts.  

I did so using the antisymmetric power on the OMC DCPDs [mA] compared to the DARM optical gain [W/m] as calculated by the ratio of the 331 Hz PCAL line [m] and OMC SUM [mA] response at the same frequency.  The math looks the same as here but I have accounted for the slight drop in response from the DARM pole.


Numbers used:
-------------------------------
DCPD Responsivity = 0.858 A/W
DCPD Quantum Efficiency = 0.98
DARM pole = 421 Hz
PCAL Line Frequency = 331.8 Hz


Plot 1 is the antisymmetric power vs the DARM offset.  (I also did this at 2 W.)  Things here are consistent with very little contrast defect light in full lock, we'll have to lock RF DARM and the OMC to carrier to see what our actual contrast defect is.
Plot 2 is the DARM optical gain vs the DARM offset.

I put this calibration into the H1:OMC-READOUT_X0 filter module but did not engage it.

---------------------------------------------------------------------------------------

What's interesting here is that if you work out Kiwamu's theoretical calculations from page 8, eq 11 of here, things don't line up at all (~factor of 4 difference in calculated DARM offsets).  I'll need to think more deeply on this, because we could learn something about the state of the IFO (signal recycling gain, arm reflectivity derivatives).  In the real IFO there are some power losses here and there (OFI trans, OMC trans, OMC mode match, etc) that could confuse us as well, we can use 20 W vs 2 W to eliminate those.

Hang, Dan, Craig

While powering up from 20 W to 30 W tonight, we've been losing lock after about 10 minutes.  It seems to coincide with a certain thermal state of the interferometer (i.e. when POP18 hits around ~50 cts, we always lose lock), see an upcoming alog from Dan.
In one lockloss, we saw a ~17 Hz oscillation ring up in all the LSC error signals.  
In another two, we saw the DARM error signal float away to infinity, causing saturations in all LSC PDs/error signals.

I took a quick DARM OLGTF while in ADJUST_POWER with 20 watts input.  Our problem could be the changed DARM phase from when the reference in this plot was taken, which was apparently September 12, 2018.  Jeff K seems to understand our DARM OLG to better than 5 percent, and our measured DARM OLGs match his.

Our phase crossover is now at 17.25 Hz, which is super close to the L2 actuation stage calibration line.  I've turned off the L2/L3 calibration lines for now just to see if this makes a difference in the next lock, probably isn't an issue.

Dan, Craig, Jenne, Stefan, Hang

We were able to power up to 30 W and stayed there for ~ 10 mins. Both the ARM ASC and the SRC ASC were fine at 30 W without growing oscillation nor run-away error point. However we kept losing locks due to some fast locklosses.

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

1. Radiation pressure compensation (RPC):

We remeasured the HARD loops at 20 W w/ RPC on. It turned out that due to the TCS improvements, the DC gains for those compensation loops we set months ago was no more accurate, and we over-compensated the loops. 

The new RPC gains should be 

In the attached plots we showed some OLTF measurements for the hard loops at different power levels and with the RPC DC gains listed above. In order to be compared with old references (the 10 W/23 W measurements), the boosts for the hard loops were turned off during the measurements. We only measured at 20 W and 25 W. The values at 30 W were more just an extrapolation. Nonetheless the ASC seemed to be stable with those numbers at 30 W.

2. Boosts in the HARD loops:

As our knowledge on the RPC gains were improved, our effective plant did not change much during the power up, and we could actually leave the boosts (the "boost10W" in the hard loop filter banks) on during the power up. Those boosts turned out to be quite helpful as today's microseismic level was high.

Also previously the boost in CHARD YAW (FM4) was not turned on. This filter was designed for a 10 W plant and due to our previous poor RPC gain settings, it made the loop unstable. Now as we made our CH Y plant more 10 W-like, we could actually turn the FM4 back on.

3. Soft loops:

We also increased the soft pitch loops gain to have more tolerance to the potential dP/dtheta instability. This was done by turning off the FM1 in DS P and increasing CS P gain from 30 to 40. Now the soft pitch loops should have a BW of ~ 1 Hz and matched to the old reference.

We also implemented the RPC for the soft pitch loops based on our loop measurements. The values we used were

 We did not exactly measure the loops at different input powers yet the settings seemed to be stable. Also to compensate for the soft mode we create digital hard mode which would stabilize the system. As a result the soft mode radiation pressure subtraction had a large error tolerance.

4. SRC ASC:

We opened the SRC loops before the power up and then measured the step responses of SRC1 error to SRM P/Y misalignment at both 20 W and 30 W. The step responses turned out to be very similar, and no sign flip was observed. We were able to re-engage the SRC ASC loops at 30 W and they seemed to be stable before the unknown fast lock losses. We also tried to leave the SRC loop on and powered up to 30 W just fine.

Stefan, Craig, Sheila

Stefan and I changed the DARM offset and looked at the noise earlier this evening.  The first attached screen shot shows the resulting change in the DARM noise, there is a large difference above 1kHz, but also a small difference which was repeated in the one on/off test we did from about 90-180Hz.  Craig has repeated this on off test a few more times, and the same pattern is holding. 

The noise gets better for larger DARM offsets, which might suggest that we are limited by some kind of sensing noise. Our noise budget shows that the DCPD dark noise isn't as far as we'd like it to be below DARM at high frequencies.  I took the dark noise measurement used in the noise budget, and scaled it for the expected change in optical gain from the change in DARM offset.  The second attachment shows the noise for these different darm offsets with the dark noise estimate subtracted.  The point is that the dark noise that we measure when there is no light on the DCPD's can't explain what we are seeing.  

We would like to engage more whitening filters to see if that changes this noise, but ran into problems described in 45720. 

Craig and I repeated this test with the OMC dither line reduced by a factor of 2, because the OMC length sensing noise should also depend on the DCPD power.  The noise introduced by a small DARM offset isn't changed by reducing the dither, so it doesn't seem like it is OMC length noise.