I noticed that DBB interface was on,  PeterK and I went to the floor to turn it off.

For locking DBB PMC, it uses a 1MHz oscillator of some sort (probably just a canned crystal). The oscillator is ON all the time even when modulation is disabled as far as it is powered but its frequency is not monitored.

J. Kissel

I've process Craig's sensing function from last night (LHO aLOG 47354), in which he states, the data lives here:
     2019-03-07_H1DARM_OLGTF_5to1100Hz_20min.xml
     2019-03-07_H1_PCAL2DARM_TF_5t1100Hz_8min.xml
I had to finagle the exported data a bit -- the PCAL to DARM TF result appears to have 1 less frequency point (at ~5 Hz) than the DARM OLG TF result, so I just stripped the DARM OLG TF data of that frequency point. Also, there seems to have been a data point with coherence of identically zero which confused the data processing software, so I modified it to be some small non zero value.

The comparison of model to measurement is attached. The numerical answers are
   Optical gain, H_c (ct/m)                 | 3.426e+06 (+1799,-2153) or (+0.0525%,-0.06285%)
   Optical gain, H_c (mA/pm)                | 4.236     (+0.002224,-0.002662) or (+0.0525%,-0.06285%)
   Cavity pole, f_cc (Hz)                   | 394.6     (+1.418,-1.17) or (+0.3594%,-0.2965%)
   Detuned SRC spring frequency, f_s (Hz)   | 2.353     (+0.06679,-0.08249) or (+2.839%,-3.506%)
   Detuned SRC spring quality factor, Q_s   | 0.01186   (+0.003069,-0.001373) or (+25.87%,-11.58%)
   Residual time delay, tau_c (usec)        | -0.4223   (+0.9933,-0.8277) or (+-235.2%,--196%)

The systematic error above ~100 Hz is great -- likely attributed to Stefan's good work compensating the DCPDs (LHO aLOG 47257) and some further good results from fitting the high frequency poles of the OMC DCPD whitening chassis by Lilli (see LHO aLOG 47377). Impressively, the residual time delay (which can be either real unknown delay, or uncompensated high frequency poles) is consistent with zero, within 1 [us].

Low frequency is still a problem -- at the 5% level below 20 Hz, with a 1% wiggle around 80-100 Hz. The good news is -- due to my template tuning (mentioned at the tail end of LHO aLOG 47206), we're now able to resolve some of our detuning again -- and the message is, we definitely have it. given the wiggle at ~90 Hz, I'm wondering if we're on the opposite side of the SRC detuning such that we're seeing pro-spring -- so much so that the ~90Hz wiggle may be the right-half plane poles not perfectly canceling the left real zero, that normal reduce to a single pole frequency when the RSE detuning phase is very close to 90 deg (see discussion of this effect in P1600295, Section 5.2).

I'd like more data with more dense frequency points around 90 Hz and between 20 and 8 Hz to really make conclusive statements about all this, but the message is that the "simple" O2 model of the detuning is failing to replicate the features seen in this plant below 100 Hz -- at the 5% level below 20 Hz.

Most of you will argue this level of systematic error is "good enough" for the sensing function.

If you insist, then populate the CAL-CS_DARM_ERR filter (preferably in new pair of filter banks, please) with the following two filter modules.
    SRCD2N: zpk([394.6064;2.3389;-2.3668],[0.1;0.1;7000],1,"n")gain(553.54)
    Gain: gain(2.919e-07)
and set the CAL-CS_DARM_ERR gain to 1.0.

Since Craig updated the CAL-CS gains on the actuator paths (LHO aLOG 47354) with the numbers from LHO aLOG 47331 (which I argued were good on TST, but still bad on PUM), then we can also run and process the DARM Open Loop gain measurement against the model, and predict the level of systematic error that would remain if we updated the sensing function as above.

See that result attached second.
Unsurprisingy, the residual systematic error looks exactly the residual systematic error in the PUM stage reported in LHO aLOG 47331.

However, the flaws are are all below 30 Hz. So theoretically, this he above sensing function is pushed, we should have little-to-no remaining systematic error above that frequency region.

And one more thing -- you'll have to update the delay between the sensing and actuation paths to 7.0 clock cycles.
See that result attached 3rd. This is consistent with what we've used for O1 (LHO aLOG 22117) and O2 (LHO aLOG 33924). The real delay is 6.89 [16kHz clock cycles], and the difference shouldn't result in that much systematic error. I haven't yet had the time to figure out the Joe Betz / Shivaraj generation of a thiran filter (see hints at LLO aLOG 28268) that allows for non-integer delays.

There is some kind of a problem with our front end estimation of the cross power spectrum, we are still investigating. 

We found that there was a discrepancy in the inverse sensing gain applied to the sum and null channels for several days, including the time Craig is using above.  We also today found that the calibration of CAL_DELTAL external into meters saved in the dtt template we were using was out of date.  I've updated the calibration using the one that is in the DARM FOM, and saved the new cross corelation template in userapps/isc/h1/templates/ as well as updated the one in the noise budget directory. 

The attached plot shows the problem, the cross corelation seems to be below thermal noise at 200Hz, this was taken at a time when the settings in the front end were correct for the inverse sensing and there was no squeezing.  The blue trace is the DARM noise according to GDS calib strain, while the purple trace is based on CAL DELTAL with the transfer function in the DARM FOM template applied, there is a discrepancy around 200 Hz between the two traces.  We will try to investigate further by running the LLO cross corelation script.

Any time that there is either a big measurement, or any kind of glitch (including when the squeezer beam diverter is opened / closed, or our regular mysterious glitches), the ADS dither lines around 20 Hz get drowned out, and the ADS starts to pull the PRM and the arm SOFT degrees of freedom to weird places. 

We've put turning off the ADS loops into the NLN_CAL_MEAS state, which we (should be) going to for any measurements, but if there's a glitch or other unexpected noise that lasts for more than a few seconds it's possible that we won't notice (to turn the ADS off) and we'll lose lock.  In the attached screenshot of a glitch time versus a quiet minute later, we see that the lower frequencies that we'd been trying to go to aren't as effected by the glitch, so we could perhaps survive some fraction more locklosses. 

Having said this, let me emphasize that most glitches are brief enough that the arms will get a bit of a wobble, but then we'll have good ADS error signals again, and be back in business without any trouble or lockloss.  Moving the dither lines should't become our new #1 priority, since lockloss  from them happens fairly rarely.  However, it should remain on our to-do list for during the run.

TITLE: 03/07 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

Rode through a few earthquakes at beginning of the shift and went through the EARTH_QUAKE STATE state in SEI_CONFIG (see Jim's alog).  It was cool to toggle between this state and be able to lock AND also stay locked at POWER_30W.

ISC Locking Note:  Violin modes have been noisy lately so have been skipping the OMC_WHITENING state: 

• so get to LOWNOISE_LENGTH_CONTROL. 
• Select MANUAL. 
• Select state REDUCE_RF9_MODULATION_DEPTH, and
• Quickly return to AUTO

While in NLN later, Sheila mentioned SRC1 P&Y signals are biggest out of the ASC Control signals; Sheila mentioned a boost filter might do the trick for optimizing these signals.
LOG:

• 15:52 Begin tweaking up ALSy alignment to relock (w/o trying a full alignment) & eventually got to NLN.
• 16:35 Switched to EARTH_QUAKE state on SEI_CONFIG guardian node (because of Chile & New Zealand quakes which passed through a little before our last drop in lock.
• 17:55 Nominal Low Noise (where we hit BNS range up to 105Mpc a few times with Squeezing).
• 20:01 Lockloss
  • Not able to make it past DHARD_WFS after multiple attempts, so
  • Ran alignment
• 21:43-22:20 Initial Alignment 
  • ALS ASC convergence took a long time.
  • For locking, touched up 
  • Made it back to NLN on first attempt post-alignment, but only stayed locked for about 30min.
• 23:54 Single bounce measurements (Sheila, Nutsinee)

J. Kissel, (R. Savage, S. Karki,  Y. Lecoeuche #PCALTeam), (J. Driggers, S. Dwyer #CommissioningTeam)

This afternoon, after the commissioning team hard-coded the information about the calibration lines into the Guardian such that they stick (47369), they found that the PCAL had gathered all sorts of nasty combs and harmonics, and was actually causing physical displacement in DELTAL_EXTERNAL.

Upon review by myself and the PCAL team (suspecting come terrible amount of clipping because the transmitted beam mount had become misaligned again; see LHO aLOG 47336), we tried
- turning OFF all PCALY calibration lines (all features disappeared, but returned when re-engaged)
- turning OFF all PCAL calibration lines, and turned off the Optical Follower Servo (this turns OFF the entire PCAL demodulation system so all light disappeared, but features returned after re-engaging the OFS and calibration lines)
- turned OFF 9.73 Hz line, leaving others on -- some harmonics of the nastiness disappeared.
This clued in Rick / Sudarshan to suspect that the optical follower servo's OFFSET that keeps the modulated output in the middle of the range of the AOM driver, had been set too high, or potentially, equivalently, the PCAL Y laser was dying (such that the existing offset was too high for the now lower power laser).
However, similarly, it could be that we simply were requesting too much drive level, equally saturating the linear region of the OFS / AOM.

So, I compared the current requested amplitudes, against what I want them to be (changed Sep 2018, but since then there has been no reason for them to change) -- see LHO aLOG 43964. This was the problem:
PCAL Line (Hz)       Should be (ct)     What it was (ct)      Channel that controls it
    7.93                 5000               5000                  H1:CAL-PCALY_PCALOSC4_OSC_SINGAIN
    36.7                 1000               1000                  H1:CAL-PCALY_PCALOSC1_OSC_SINGAIN
    331.9                20000              20000                 H1:CAL-PCALY_PCALOSC2_OSC_SINGAIN
    1083.7               5000               20000                 H1:CAL-PCALY_PCALOSC3_OSC_SINGAIN

I attach ASD of the RXPD in several configurations. 
Gray -- what we were seeing that caused everyone to launch this investigation. Lots of non-linear harmonics.
Green -- "what it should be" from above, but with the amplitude of 7.93 Hz line reduced by 5. No non-linear harmonics.
Red -- "what it should be" from above. Some non-linear harmonics, but none peaking above the noise floor.

We're now running in the Red configuration.

We all checked the SDF system which should have caught this mistake but it did not reveal that the amplitudes were in error, which means, somehow, the higher amplitude settings were accepted into the SDF system. Who knows. I've now accepted the "should be" amplitudes into both the safe.snap and OBSERVE.snaps.

Since there are some non-linear harmonics in this configuration (in which the 7.93 Hz line is at the higher, 5000 ct amplitude, which we need at this SNR of ~10 in order to resolve the SRC detuned spring frequency), we should probably see if the OFS OFFSET can be tuned a bit, so we're not skating along the non-linear rails.

When I arrived on site this morning, Corey had just lost lock due to a couple earthquakes, one 5.5 from New Zealand and a 5.7 in Chile, which arrived on site at about the same time. The ground was still settling down, he was not really trying to lock, but ALS was having difficulty. I asked him to switch SEI_CONF to the EARTH_QUAKE state (this is NOT the big red button, this is a state in the SEI_CONF guardian) , which changes the sensor correction path to a sensor correction path that uses a local differential ground for isolation. The differential signal is calculated by subtracting a common ground, which is the average of all 3 VEA (ends and corner) ground seismometers, from the local ground sensor. Because of the way this subtraction is done, this reduces the isolation at the microseism, so this state will probably only help when the microseism is low. After making the switch, Corey was able to start locking again, even though the ground motion was still well over 100 nm/s rms in .03-.1hz band. We usually wait for the ground to get below 100 nm/s. After he got to somewhere around DC Readout, we switched back and forth from WINDY to EARTHQUAKE and were able to stay locked through both transitions. Around this time we got another earthquake notification from New Zealand. When this earthquake started affecting the the interferometer, we switched back to the EARTH_QUAKE state, and were able to ride this second, somewhat larger quake out with the interferometer in a robust state.

Here is a timeline:

March 7 2019, times are UTC

16:12 First set of earthquakes arrive

16:25 Lockloss

16:29 Switch SEICONF to EARTHQUAKE

16:33 ALS locks, RMS ground motion is around 300nm/s

17:00 Transition back to WINDY

17:05-17:07 Transition to EARTH_QUAKE and  back to WINDY. EARTHQUAKE is noisier, but in POWER_30W this doesn't break the lock. Around this time we get another earthquake notification from New Zealand, a 5.7 this time, we got something like 15 minutes early warning for the R waves.

17:15 We start seeing more low frequency noise in the IFO (I think I was watching the LSC CPS FF channel) as the second earthquake arrives, so we transition to EARTH_QUAKE again. IFO sees more microseism in ASC, IMCF, ETMX SUS length drive, but I don't think we see as much low frequency as we would see in the nominal configuration. This earthquake is a little bigger than the first earthquake, but we ride it out. ISC_LOCK stays in POWER_30W for the duration.

17:39 Ground RMS is back down to about 200nm/s rms, we transition SEICONF back to WINDY.

All of these steps are shown in the attached trend. 40 is the WINDY state for SEICONF, 20 is the EARTH_QUAKE state number.

A few notes:

All earthquakes were in the 5.5-6.0 magnitude and roughly 10,000 km away. Peak eq band rms velocities were around 1 micron/s.

The only seismic configuration change was selecting the EARTH_QUAKE state in SEI_CONF, not the big red button or the LARGE_EQ state. This state also doesn't change the added gnd Z to HAM3 and HAM4 feedforward. I tried turning the HAM3 ff off and on during the second earthquake, but I didn't see any difference in IMC F.

The IFO stayed in POWER_30W for the second earthquake, which is before low noise coil drivers and low noise ASC, so the IFO controls were in a pretty robust state. Jenne suggests we can look at various drives to see if this we could stay locked during low noise.

This will probably only work with low microseism. Right now peak rms velocities are about .3 micron/s. I would guess that this might work up to around .5 micron/s rms, we more or less loose all of our microseismic isolation, and .5 micron/s was about the highest velocity we could handle during O1 with blends that similarly didn't suppress the microseism.

Both of these earthquakes were just under 1 micron rms in the .03-.1hz band. During the lock with the second earthquake we got a notification of some IMC SERVO voltage being high, which I think means that something in CARM may ultimately be the limit on our ability to ride out an earthquake.

The wind was also up around 20 mph during this time, I'm sure it didn't make this easier, but it didn't seem to be a problem for us.

The sensor correction ramp times are set at 15 seconds, this seems to work ok, might be ok to go shorter. Because the EARTH_QUAKE state changes the BSC ST1 Z blends to 250mhz blends form 45mhz blends, it takes around a minute for the total SEICONF transition to complete. Going the other way takes 2 minutes to turn the 45mhz blends back on. This didn't seem to cause any problems for the IFO. No other blends are changed going from WINDY to EARTH_QUAKE.

• HAM CPS:  Nothing to note for spectra at high frequencies.
• BSC CPS: ETMy Stage-2 V2 and ITMx Stage-2 H3 are both subtly high (the script also lists both of these signals as high).

We have been trying to use SDF to manage the settings for the calibration lines, but they keep getting turned off which means that we are often missing our optical gain and cavity pole monitors.  I've hard coded the settings for ETMX cal lines in NOMINAL_LOW_NOISE, and it is enabling the excitations on PCAL X and PCAL Y.  

Georgia, Craig, Danny, Sheila

Here are some updated noise budget plots, made for 9:30 UTC March 5th, when there was no squeezing injected. 

Some notes:

• shot noise: Although the pcal monitors at this time suggest that kappa_c (scale factor for optical gain) is  and that the DARM cavity pole, I found that the shot noise is more accurate based on the cross correlation with a cavity pole of 440 Hz, and kappa c of .  For the last few weeks I have consistenly been using cavity poles higher than the pcal monitors have said and optical gains lower than what the pcal monitor says.  
• The OMC length noise is Geogira's measurement posted here: 47286
• The frequency noise is based on Craig's projection 46864  Note that we are doing a pretty generous interpolation here, sometime we would like to get better frequency resolution for the measurement.  
• 73 Hz line: This was a time before the grounding change at EX got rid of 73 Hz line and some features around 280 Hz, so those peaks which are unexplained in this budget are no longer in DARM.  47323
• MICH P:  The MICH P ASC noise is very small in this noise budget, but will need to be updated again. We are rethinking this loop 47352 since we found that it was causing a lot of motion at 0.5Hz and contributing to the sidebands on the 60Hz line. 
• The centering loops haven't been re-measured so they aren't included here yet. neither is the SRC1 (AS 72 to SRM loop).
• MICH LSC coupling has been changing a bit while things thermalize, the ones that are included here are measured a few hours into a lock.47333

On March 6th:  Crystal Chiller:  150mL added.  Diode Chiller: OK. 

Both filters looked fairly clean (Crystal on left was slightly darker).

M. Wade

We found a problem with the configuration for setting the injection bits in the GDS-CALIB_STATE_VECTOR.  The configuration bug crept in on Feb. 26 and the configurations were correct before this time.  I fixed the configurations and restarted the pipeline around GPS time 1236011968.  The new configuration file is in the calibration SVN under

aligocalibration/trunk/Runs/ER14/GDSFilters/H1GDS_1236011968.ini

The difference in this configuration file and the last one is the CBC, Burst, DetChar, and Stochastic HW injection bitmasks are now configured to look for bits 9, 17, 33, and 65, respectively, to be OFF in CAL-INJ_STATUS_OUT_DQ instead of ON.

Since the restart, the GDS-CALIB_STATE_VECTOR is now correctly reporting that HW injections are OFF.

After modifying the CM board, see alog 47294, the CTRL readout has become significantly better, whereas the ERR readback has gotten a lot worse. However, the CTRL still has extra noise below 100Hz. 

The slow readback was already good, but may have gotten a little better around 20-30Hz.

Compare against alog 47130.

I wrote some python code to create cross-correlated DARM spectra over long, glitchy locks.
Stefan balanced the PDs recently, and we saw our correlated DARM noise was fairly high at high frequency.  Stefan supposed this was from glitches, but from this alog, this seems to not be the case.

The info we want from the cross-correlated DCPD spectrum is the correlated noise from the IFO.  We can average away the shot noise like 1/sqrt(N) where N = number of ASD averages.
The problem is we need many averages to integrate away the shot noise.  However, during these locks, we have frequent, strong ESD saturation glitches which spoil the spectrum.  
DTT is not able to "gate" the glitches, i.e. remove them from the timeseries.  This code solves this problem.

Attachment one shows a DARM ASD and DARM CSD between the OMC DCPDs during the lock last night.  I have 2000 averages with a binwidth of 0.2 Hz and 50% overlap, or 1.4 hours of data.  During this time there were 4 glitches which spoiled the spectra (the blue, purple, and green traces).  With gating we have the red and orange traces.
Attachment two shows a zoomed in gate function of one of these glitches.  The gate I apply is just a logistic function with the mean of the data added in.  The glitches are witnessed via the DARM BLRMS increasing to huge values, specifically H1:OAF-RANGE_RLP_3_OUT16 going above 100 counts.
Attachment three shows the DARM OMC DCPD data with and without the gate applied.  

Code lives in /ligo/home/craig.cahillane/Git/IFO/Crosscorrelations/scripts/gated_DCPD_CSDs.ipynb.  To run you'll have to run:
$ setupanaconda (or $ source /opt/rtcds/userapps/release/cds/h1/scripts/setup_anaconda if your .bashrc alias isn't set up)
$ source activate cragenv
$ jupyter notebook /ligo/home/craig.cahillane/Git/IFO/Crosscorrelations/scripts/gated_DCPD_CSDs.ipynb

Shoutouts to TJ Massinger for help with understanding gating.

see alog 43530 for howto

Stefan, Peter, Rich

It was found that the overall DC gain, and the pole-zero location associated with the second filter module of the OMC DCPD Whitening chain, was somehow dependent on input signal level.  A parametric study was done on the OMC DCPD whitening chain for different whitening filter combinations with and without DC offset.  Notes detailing the parametric study are attached to this entry.  

There were two causes of these phenomena:  
1.  Gain Change - As the DC input to the OMC DCPD Whitening amplifier (D1002559 Chassis S1101627) is varied, the DC level causes saturation in some of the DC coupled gain stages.  This saturation causes the normally high-impedance amplifier input to be fairly low due current flowing into the input protection diodes internal to each opamp stage.  This lower input resistance in conjunction with the series resistance of the FET switches produces a voltage divider with a division ratio dependent on signal level.
2.  Pole-Zero Change - The second filter module had an ECR (E1500252) performed that required a 1uF capacitor to be used.  This type of filter function is supposed to be implemented with a plastic film dielectric capacitor, but a ceramic capacitor was used instead.  The piezoelectric nature of ceramic capacitors can result in a capacitance that will change with applied voltage.  This caused the pole-zero location to vary as a function of DC level.  This capacitor was changed to the proper type and the problem went away.

Data (attached) was taken for both OMC DCPD chains by injecting signals into the input of the OMC whitening chassis (DCPD Preamps disconnected), and taking the output differentially from the analog output of the whitening chassis with the ADC cable still attached (to account for any loading effects).  This data was taken with and without a 5V DC offset to verify that there is no longer any effect on the signal path gain.

We note that the above were all small effects, but significant in the world of 1% calibratin uncertainty. The DC gain reduction with a 5 V offset (similar to the offset in NLN operation) was 0.2 dB. The errors in the filter stage with offset were -- phase: 0.6-1 degree at 50 Hz; magnitude: 0.15 dB gain difference between 50 Hz and 200 Hz.

Danny, Dan

9MHz RIN line over locks

We put a line at 70.123Hz in the 9MHz for a few locks to see how it was behaving over time. When it was one we had a few short locks and two longer ones so far. It seems there are two states in which the coupling finds itself, one that peaks around "8" and another "6". This may coincide with going to LOWNOISE_ESD_ETMX (Guardian state 514) - the jump up in RIN coupling for red/green/orange seems to happen at roughly the same time after we go up to state 514. During the two long locks it's clear there's some long time constant to the RIN coupling, it takes around 4000s after going to 30W for this to settle. So depending on the thermal state we took the RIN measurements previously this might be a reason we got confused.

ITMY Mask

Last night we tried out the ITMY mask. The initial plan was to just apply the mask with the IFO unlocked to see how the induced OPD compared to what we expected. Then as we had the IFO to ourselves we decided to just go for it and try it out in a full lock to see what happened. Edit: this test was just to get the CO2 mask on at the expected power without causing a lockloss, the expected implementation requires changing ring heaters as well which is something to try another day.

Initially the OPD doesn't look quite like we expected. What isn't obvious is the crescent moon like shape seen in alog 46976 (Top right figure). This could be because the HWS probe beam isn't illuminating the full area so we just see a small section of it. I took the 30W point absorber OPD and added it to the offline mask OPD to get a rough idea of what might be the total effect, from this it reduces the overall optical depth and the larger spatial frequency heating from the absorbers.

From initial inspection the alignment of the minimum is not too far off from the point absorbers, we might want to try shifting the mask slightly in future. However it looked reasonably well aligned enough to try in a full lock.

FLIR image of mask

We powered up to the 30W state but didn't go to low noise ASC. We then put the mask in and stepped up in CO2Y power 100mW, 200mw, 400mW in 1000s intervals. We compare this with the 30W lock we had yesterday with the 9MHz RIN line on where we also didn't go to a low noise state. Looking at the RIN coupling we can see an improvement as the mask is introduced, then when we switched it off it goes back to as it was before. I injected a line that was 10x larger than the previous day by accident so the amplitude is rescaled and the line is less noisy. In hindsight we should have left it on a bit longer to see how it affected the steady state after 4000s, however we wanted the thermal state to return to normal for the night shift commissioning. From the data it looks as if the RIN coupling levels off between 3000-4000s. It looks to be at roughly the same level as the steady state case without the mask. Perhaps there is another dominating coupling effect at that stage where the mask no longer helps.

RF90/RF18/PRG/HWS traces with and without the mask.

Comparing with and without the mask we can see:

• RF18 looks slightly higher, RF90 slightly lower
• PRG maybe a little lower
• ITMY spherical power drops 155uD to 148uD

Things to try next:

• Alignment of the mask. The mask OPD needs  ~-0.5cm in x to align it better with the point absorbers. Assuming the CO2 telescope images the mask with a magnification of 23 on to the compensation plate, that means we need to move the mask ~200um
• Could try adjusting CO2X or RH Y to change differential lensing and see if we see similar drops in RIN coupling, RF18, etc. Perhaps we just need to tune the current TCS actuators better.
• Try mask after 4000s and at nominal low noise to see if it actually improves the sensitivity and drops below the steady state RIN we see