TITLE: 03/07 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:

H1 dropped out just before I came in after being locked since 2am-ish PST.

[Craig, Georgia]

Tonight we checked on the OMC ASC coupling to DARM. We re-ran a template which Sheila used in 2017 (alog 35664), injecting broadband noise into each degree of freedom (POS_X, POS_Y, ANG_X, ANG_Y), and measuring DARM. In previous measurements an offset was added to the ASC loops, linearising the coupling. We did not add an offset tonight, instead just comparing our excitation to previous data.

The first attachment shows DARM with no excitation in yellow, DARM with an excitation in each degree of freedom in mint green, and the a reference from 2017 of DARM with the same level of excitation in dark green. For 3 out of 4 degrees of freedom the coupling was similar to this measurement in 2017. POS_Y stands out as showing additional coupling to DARM, perhaps suggesting some offset in the loop.

Concerned about POS_Y, we did a quick linear projection to DARM using the control signal with and without the excitation. Craig did some quick calibration magic to make the control signal with the excitation on line up with DARM. He scaled the control signal (OMC_ASC_POS_Y_OUT_DQ) by a factor of 3e-12 and added a pair of poles at 0.1 Hz to simulate the control loop, resulting in the dark purple trace in the second attachment. If we then apply the same scaling to the ambient control signal we see that it is well below DARM (light purple trace).

I measured ASC MICH pitch this afternoon.  The 6Hz lowpass was off (Sheila and I put this in the guardian, since it seems to clearly help the buildups be more smooth, and scatter things go away).  I think that we should re-look at the noise budget to see if we can afford to increase the bandwidth of this loop a bit, because right now it's pretty small.  After we increase the bandwidth of MICH (if we can), we should see if DHARD's noise coupling is still modulated by something that is witnessed by the POP QPD (as Gabriele indicated). 

In the attached figure, I show the same OLG data set, keeping data points with coherence above 0.7 or 0.9 respectively.

Borja sent an updated list of mode frequencies (this time 31 of them) for the fundamental violin mode, by comparing a high resolution spectrum for long locks at LHO. Using this data I was able to compare (with ours) and identify 28 of the modes (out of total 32). Please find attached a.pdf file below for details. There are 4 more modes which still needs to be identified. All 8 modes for the ETMY has been identified. For the ETMX, Borja found a mode at 511.19, which was in his initial list (LHO alog 46597) but later deleted it since he wasn't sure. However we are able to see a mode at 511.18 at ETMX. This needs further investigation, along with the hunt for the remaining violin modes. 

 
 

TITLE: 03/06 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 EQs during today's shift.
LOG:

• Alignment Work In Morning:  Arrived to see the ALSy with no light, so started investigating (Ed, Jeff, and I tag teamed this).  Ed was able to get us a beam on the camera, and I then steered the BS in yaw (as Jenne pointed to the ASAIR yaw which was visible).  After alignment, took H1 to Nominal Low Noise.
• 16:07-16:27 EY to Chiller yard (Bubba)
• 16:20-16:42 Junction box for RFPD (WP#8114)(Richard)
• 19:47-21:30 SRM Heater work begins (Danny & Dan)
• 19:50 At Nominal Low Noise
  • Violin Modes [ETMx,/M9, and ITMx/M1were a little rung up, so focused on them a bit (Rahul & I).  Ed is working on the 2nd harmonic.]
• 21:06 Lockloss most likely due to a New Zealand EQ rolling through.
• 23:30 PSL Chiller topped Off. (corey)

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.

Dan, Danny,

To test the SRM CO2 heater we first needed to get it aligned correctly. The method was similar to before when we tried this (42254, 41724):

• Lock IFO to ensure we align to the nominal SRM beam position (Previous attempts were done with single bounce beam)
• Perform an initial alignment of the beam with the red beam to visually see we are hitting the SRM HR baffle plate. Trace out the edge of the baffle hole and center ourselves in pitch on the hole
• Pulse the CO2 heater
• Position the beam on one side of the baffle hole then scan across in yaw
• Look at SRC2 pitch and yaw output to see how the point of the output beam has to change to keep it aligned on AS_C
• Adjust positions to see a sign change in SRC2 signals, i.e. the thermal lens has moved to the other side of the beam

To speed up the searching we hooked up the CO2 controller to SQZ LO SERVO EXC channel and drove it with a 30s square wave with a 20% duty cycle. We also connected the periscope picomotors to the ISTC6 picomotor driver using channels 5 and 6. This was to speed up the alignment by just being able to initially hand align the beam to one side of the baffle hole and then just continuously scan across to look for the pulses, occasionally adjusting pitch to keep it zeroed and pitch up/down to check we are still at a zero. We also connected the Thorlabs power meter to SQZ EXTRA AI 1 to monitor the pulse powers, there are two filters there to convert into Watts measured on transmission of the first beamsplitter (Most of the CO2 power gets dumped through this so only ~1.2W can ever go into the chamber, when the Thorlabs power meter reads 6W).

Last time we tried this the alignment with the single bounce beam it was awkward and took awhile but achievable. We have tried to align it several times over the last 5 days but have had no luck in finding a good yaw alignment. Pitch was relatively easy to find.

Yaw however always seemed to end up clipping. Here you can see us trying trying to sweep over the error signal, a slow increase is seen, then we peak, then we start decreasing in a linear way which looks like we are heading for a sign flip. That didn't happen. We then moved the bottom periscope mirror to try and shift the beam horizontally to get around whatever might be clipping but nothing. We then resorted to shifting the table around, but still no luck.

We were never able to align the beam to get a negative SRC2 yaw pulse, despite some pretty bold alignment changes with the table and picos. Given how hard it is we are wondering whether the hot IFO SRM spot position is positioned in such a way that we just can't get to the other side of the beam?

Next things to try here would be to look at the SRM IFO beam spot position and see if it moves much from a2l gains perhaps. Maybe we could also try aligning this in single bounce again and aim for a similar alignment as seen here with the illuminators on.

Follow up to 47274. As explained there, I trained my non-stationary noise subtraction algorithm on 60 seconds of data (1235434291 + 60s).

Then I implemented the noise subtraction with time-domain IIR filters, and tested the performance.

First of all, the time-domain on-target performance (i.e. using the same data used for training) is good as expected. In the left plot below: blue is the original DARM during a DHARD_P injection, red is the best stationary and linear subtraction, yellow is the sum of all non-stationary contributions, green is the subtraction using the non-stationary estimate. In the right plot, blue is the coherence between DARM and just DHARD_P, while yellow is the coherence between DARM and the estimated non-stationary signal obtained from DHARD_P 

Similar performance is obtained using the same filter parameters, but on a different noise injection later in the same lock (1235434490 + 38s). Same color scheme as the first plot above

Finally, the performance during a quiet period (no noise injection) during the same lock. It looks like there wasn't much DHARD_P noise to subtract, but the non-stationary subtraction is a teeny bit better (not very significant...)

NikoL, RickS

Following up on the work we did at Yend last week (see this Link), Niko inspected the beam positions at the input aperture of the Rx sensor at Yend yesterday after completing calibration measurements at Xend.

He found that the Outer (lower) beam had again drifted to the right (see attached photo), this time by a few millimeters.  This likely did NOT impact the calibration because it did not appear to be clipping at the Rx sensor aperture.

Given that it was near the end of the Tuesday maintenance period, we did not have much time to improvise a potential fix.  But we end up trying a kind of "flying buttress" approach.  We used a second ThorLabs base and some 5-minute epoxy we found in the toolbox (it was WAY beyond its expiration date of 1/21/2013, but it was unopened, so we gave iit a try) - see second attached photo.  If this epoxy actually hardens, it should help stabilize the post holder.   If this is the source of the alignment drifts, this may help.

We also tightened the set screw that holds the 1" diameter beamsplitter in place in the Newport U100 mount.  Slight tightening of the set screw resulted in the beam at the Rx module moving by more than the 1" diameter of the power sensor aperture.  This might indicate that the optic was not seated properly to begin with.  Maybe this is the real source of the alignment woes at Yend. We did not want to risk removing and re-seating it yesterday, but may try that in the future if this problem persists.

We carefully aligned both beams to the center of the Rx power sensor aperture before leaving the end station (see last attached photo). 

To follow up with the measurements described in 47289, Craig added two MICH length lines, at 12.3 and 100.0 Hz. They were both on for the entire duration of a long lock stretch yesterday night. By demodulating both lines in H1:SUS-BS_M3_ISCINF_L_IN1_DQ and H1:LSC-DARM_IN1_DQ we can track the evolution of the MICH to DARM coupling over time. The reason to have two lines is that looking at the transfer functions plotted in 47289, one can see that the high and low frequency components change in a different way.

The plot attached shows the DARM / MICH transfer function at the two lines, as a function of time, in hours from 1235873679. The coupling changes over time both at 12.3 and 100.0 Hz.

At 12.3 Hz there is a monotonic change from 4.6e-10 to 4.5e-10, with a phase rotation of about 5 degrees. This trend settles after a hour or so.

At 100.0 Hz the evolution is more complex. There seems to be an initial trend similar to the 12.3 Hz trend (except that the phase seems to be increasing), but then there are large fluctuations in both amplitude and phase. It would be interesting to understand what was happening to the IFO during those excursions.

J. Kissel (with help from L. Sun, E. Goetz, L. McCuller, E. Bonillla, R. Kumar)

I've been processing the actuation function data from 2019-03-01 (see LHO aLOG 47206), and have some updates. Not were I want it, but since the heat is on I'll give a status update.

Recall from LHO aLOG 46806,
Steps to success:
    (i) Find out why ETMX L1 and L2 doesn't work, and fix it, such that we can go forward with full ETMX DARM actuation. 
        DONE (see fixes to UIM and PUM crossovers in LHO aLOGs  47164 and 46861)
    (ii) Measure the PUM and UIM coil drivers, and update the compensation. 
        DONE (see LHO aLOG 47167)
    (iii) Truly identify ETMX all 8 violin mode fundamentals and their harmonics to update the PUM dynamical model (needs IFO time), finish fitting the UIM transfer function data to update the UIM dynamical model (needs Kissel time)
    (iv) Remeasure all stages of ETMX with the full IFO 
        DONE (see LHO aLOG 47206)
    (v) Update the front-end calibration (including reference model parameters at calibration line frequencies such that time-dependent correction factors are accurate), and 
    (vi) confirm success with the full IFO (needs IFO time).

So, I'm currently working on (iii) [with the help of Edgard, Rahul, Borja (#TeamSUS) along with Lee and Lilli #TheFittingCrew] and this aLOG is reporting the progress on fitting the results from the 2019-03-01 measurements, i.e. (iv) [working with Evan #TeamPyDARM].

Check out the attached .pdfs from each stage below, which are the output of the following script, 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOActuationTFs/process_actuationmeas_20190301.py
after creating a new pyDARM model parameter file,
    ^/trunk/Runs/O3/H1/params/modelparams_H1_20190301.py

TST: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 4.734e-12 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 4.433e-11 (N/V**2)

    Actuator gain, H_c (N/ct)              | 4.734e-12 (+2.09e-15,-2.102e-15) or (+0.04415%,-0.0444%)
    Residual time delay, tau_A (usec)      | 10.79 (+0.7573,-0.76) or (+7.02%,-7.045%)


Comments: Except for the sign flaw in the "intermediate results" plot, I'm very happy with the state of the systematic error, I believe the MCMC fit, and I think we're ready push to front-end.

PUM: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 6.223e-10 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 0.03038 (N/A)

    Actuator gain, H_c (N/ct)              | 6.223e-10 (+3.339e-13,-3.33e-13) or (+0.05367%,-0.05352%)
    Residual time delay, tau_A (usec)      | 4.096 (+1.568,-1.571) or (+38.28%,-38.34%)


Comments: There's still something very fishy going on below 20Hz. I don't understand it, and this is under investigation by Evan and I.

UIM: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 7.498e-08 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 1.597 (N/A)

    Actuator gain, H_c (N/ct)                   | 7.498e-08 (+2.842e-11,-2.869e-11) or (+0.03791%,-0.03826%)
    Residual time delay, tau_A (usec)      | 57.81 (+1.218,-1.215) or (+2.107%,-2.101%)

Comments: the low frequency data (below 10Hz) is pretty un-informative, and this is where the UIM matters -- BUT I'm not sure we've ever got any better. I'm dividing out the high frequency dynamics of the OSEM bracketry and UIM to PUM violin modes based on old H1 ETMY data for now CSWG aLOG 11212, and that has significantly flattened out the systematic error, so we can now use all the data from 10 to 100 Hz for the fit of the actuation coefficient instead of what we did in O2 which was only use 3-5 points between 10 and 20 Hz. I'm working with Lee to get an updated fit on data that I took on 2019-01-25.

Finally, I show one of the plots from the latest output of 
    https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Common/pyDARM/darm_loop_critique.py
which, unlike the scripts from above is a function, which I called using the following command line,
    python3.6 darm_loop_critique.py --run=O3 --IFO=H1 --DARMmodelfile=modelparams_H1_20190301 --modelFunction=modelPars --outputfile=2019-03-01_critique

This shows the relative contribution of each stage. to the overall actuator to give you a feel for what matters where (now that things have been updated to reflect Sheila's latest work with the PUM crossover).

Comments: 
    - Only the phase is shown, so take the plot with a grain of salt. 
    - In the calibration band (a bit larger than the detection band, between 5 and 5000 Hz), excitingly, the UIM is now *very* unimportant to get perfect. However, I'm interested to see how this plot shapes up once we've fixed the dynamical model (which is currently all this plot has to go on)
    - It is far more important to get both the PUM and the TST stage right.
    - We'll need to resolve this reported frequency-dependent systematic error in the PUM, since it's right in the phase/magnitude mixing region ("the crossover" implies the hand-off between stages only happens precisely at a single frequency. No bueno.)

So -- I continue my work on the PUM as priority.

We also need to retake a sensing function sweep suite, so I can compare the results against and open loop gain model.

The adapter box that interfaces between the DB9 of the RF photodiode and the DB15 of the TTFSS field box was
opened.  On the DB15 side, there is 1M in series with pins 5 and 13.  These reduce the nominal gain of the
RFPD DC monitor output from -1 to -0.01, which would explain the low number of counts observed.

    Otherwise the number of counts for ADC channel 6 is consistent for the input applied voltage.



  Richard / Peter

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.

Nutsinee Daniel

With the discovery that the noise eater can add noise to the beat note between the PSL and SQZ lasers (LLO alog 43837), we added a 100MHz high pass filter to the spare TTFSS (S1700330).

On the PFD D1002471 we changed:

1. R1 was removed
2. F1 was stuffed with a Mini-Circuits PHP-100+

This unit was installed and the old unit removed (S1700331). We also removed the IQ demod version of the TTFSS that was still on top ISCT6.

Noticed that the fan of the laser power supply starting to sound like a coffee grinder...

Sheila, Nutsinee

Following up alog47184 we investigated on how the other two peaks (one at 177.7Hz and the other at 262Hz) behave with different CLF power and UGF. The peaks only responded to decreasing/increasing loop gain but not to increasing power. We didn't do other tests (eg. noise eater on/off) since the IFO lost lock. We also tried decreasing LO loop gain but that didn't do anything. The mystery continues. 

Note that the high CLF gain with 0.02mW going in to the coupler is what we are normally operating. 

Same CLF gain label of the third plot means same UGF as the first plot.

I think we left the CLF power at 0.08mW into the coupler. For optimized IFO squeezing tonight (if needed) I recommend putting it back to 0.02 mW. 

J. Kissel, S. Dwyer,

After Sheila fixed a few hiccups in the NLN_CAL_MEAS state's return to NOMINAL_LOW_NOISE in the ISC_LOCK guardian, I was able to gather all measurements necessary for updating the actuation function of the calibration. I was tuning the amplitude in sensing function's DARM OLG sweep to get better coherence between 5 - 20 Hz (to resolve detuning), aborted the measurement and we lost lock [it was a swept sine, and yes, it had a 3 sec ramp down time. I was actively watching the ASDs of ETMX digital requests to the DAC and we were no where close to saturating].

Anyways -- analysis to come, but the data lives here:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/
        2019-03-01_H1SUSETMX_L1_iEXC2DARM_25min.xml
        2019-03-01_H1SUSETMX_L1_PCAL2DARM_8min.xml

        2019-03-01_H1SUSETMX_L2_iEXC2DARM_17min.xml
        2019-03-01_H1SUSETMX_L2_PCAL2DARM_8min.xml

        2019-03-01_H1SUSETMX_L3_iEXC2DARM_8min.xml
        2019-03-01_H1SUSETMX_L3_PCAL2DARM_8min.xml

Note that during these measurements, one *has* to turn of the Alignment Dither Loop system (namely DOFs 3 4 and 5), which controls the drift of the Y Arm (roughly equivalent to the SOFT DOF). With the loops OFF, the alignment does drift slowly, on a ~20 minute time-scale. As such, given the length of my measurements, I went back from NLN_CAL_MEAS to NOMINAL_LOW_NOISE in between clusters of measurements and waited there for the ADS error signals to steer back towards zero (which takes about 5 minutes), then switched back to NLN_CAL_MEAS and resumed measurements.

And although the data is meaningless, the amplitudes and frequency vectors in the sensing function templates
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
        2019-03-01_H1DARM_OLGTF_5to1100Hz_20min.xml
        2019-03-01_H1_PCAL2DARM_TF_5t1100Hz_8min.xml
should be used for future measurements.

If you need it, my template for watching the ESD and Coil Driver DAC requests during measurement lives here
    /ligo/home/jeffrey.kissel/Templates/DTT
        H1ETMX_ActuatorSaturations.xml

A quick entry whilst things are still fresh in my memory, more details to follow.

    Adjusted the double pass alignment through the AOM.  Re-centered L12 and the 21.5 MHz EOM to match (component
names match those on the PSL table layout).  Without the 21.5 MHz connected, measured 43.8 mW at the base of the
periscope, and 40 mW after the polarising beamsplitter cube before the RF photodiode.  Measured 4.38 mW in front
of the RF photodiode.

    Locked the FSS.  With a reference cavity transmission signal of 3 V, measured 17 mW in front of the ALS fibre
(see ALS_Fibre.JPG).  After the alignment tune up, measured the transfer function (see PC.jpg).  It was here where
things went AWOL.  Swept the reference cavity by applying a ramp to the PZT and displayed the mixer monitor signal
on an oscilloscope (see scope_0.png).  This was noticeably different from the same measurement taken before lunch,
where the discriminator signal was less than ~10 mVpp.  The RF output of the RF photodiode is shown in scope_1.png.

    Left the FSS with a common gain of 25 and a fast gain of 16 (see CG25FG16.jpg) where the UGF is ~417 kHz.
Increasing the common gain slider by an extra dB or two to sit on the peak of the phase bubble makes the PZT
prone to oscillating.


  Jason / Peter