Albert, Chandra

9:00am local

20 sec. to overfill CP3 with 1/2 turn open on bypass LLCV. Left bypass exhaust valve open. Exhaust line is still frosty, but the ice balls near exhaust valve have melted.

CP3 show 'n tell for Albert Lazzarini.

This morning I opened up the ISS photodiode box.  The beam incident into the box is attenuated by a polarising beamsplitter
and half waveplate combination.  The rejected beam is dumped into an absorbing Schott glass filter. (see ISSBeamDump.jpg)

    The power going into the photodiode box was measured to be 597 mW.  For ease of installation I inserted a neutral density
filter labelled "ND=0.3" at the input to the photodiode box. (see NeutralDensityFilter.jpg).  The output of PDA went from
-8.43 +/- 0.07 Vdc to -2.22 +/- 0.01 Vdc, which is somewhat more than one would expect from the label.  The half waveplate
was adjusted to bring the output of PDA to -5.22 +/0 -0.03 Vdc (see BeforeWaveplate.jpg and AfterWaveplate.jpg).

    rpn1.jpg shows the free-running spectra as measured by PDA and PDB after the installation of the neutral density filter.
As previously, both agree quite well.  Attached are a few other recorded spectra with the differences being the gain slider
setting.  The transfer functions for a few gain slider settings were measured (see ISSTF.jpg).

    It is not obvious to me why the in-the-loop noise would increase as the gain increases.  See for example g3.jpg and
g6.jpg.  So this might be an electronics problem?

    Also attached is the power noise as seen by the PDA55 photodiode that monitors the power going into the input modecleaner.
0.307 mV was the output of the photodiode when the ISS was locked.  However it might be that the bandwidth of this photodiode
was only 60 kHz, depending on how the gain selector switch was set.  Beyond about 1.6 kHz, the measurement is limited by the
dark noise of the photodiode.
Click here for the datasheet for this obsolete photodiode from Thorlabs

Photos of photodiodes removed from damage OMC. Photos taken by GariLynn B. at Caltech.

Photos have been posted on E1600268-v1, "Initial Inspection of OMC Bench at CIT Aug 2016"

https://dcc.ligo.org/LIGO-E1600268

Naming conventions are from E1600262-v3, "aLIGO OMC: Spare OMC production plan"

https://dcc.ligo.org/LIGO-E1600262

Diode pictures attached to this alog entry:

• Diode DCPD1 - image (diode1.jpg, 147.6 kB)
• Diode DCPD2 - image (diode2.jpg, 133.5 kB)
• Diode QPD1 - image (diode4.jpg, 706.8 kB)
• Diode QPD2 - image (diode3.jpg, 92.9 kB)

• I put BRS to Very Windy this morning after the meeting
• JimW is modifying guardian to incorporate stage2 code 
• current state is Earthquake v3, which also has the BRS not in use
• will switch back to Windy when the site is clear

It seems that since the last power glitches, the DBB is back to operational status... hmmmm. That is to say, before the power glitches it was unusable due to the mysterious tripping of the (dbb) interlock when trying to open the beam path into the box. In the past week I've been trying to get good measurements. This was a abit daunting due to the ISS 3rd loop work that was breaking the IMC lock consistently and yanking on the LASER frequency. Below is what I could muster over the course of a couple of days. ISS_RPN will come later as Peter is currently in the enclosure and working on it.

Comments:

RPN - 35W path looks suspiciously good accross the spectrum by a factor af a few...hmmm?   200W path looks tyo be below requirement from 2Hz to ~25Hz and then above to about a factor of a few through high(er) frequencies.

FRQ -  35W path is quite noisy at low freq (below 15Hz). Other than that the rest looks good save for the usual resonances. 200W path looks ok across the spectrum except for the usual resonances.

PNT - 35W path pointing looks pretty good. 200W path shows seperation  of the 1x/y and 2x/y  by a factor of a couple.

MSC - 35W path shows TEM 20 +02 an order of magnitude higer than reference. 200W path shows TEM 02+02 mode higher by a factor of a couple.

Morning Meeting:

• SEI - all good
• SUS - Betsy to LVEA for about an hour
• CDS/Electronics - waiting for changes in PSL
• PSL - Peter is putting a ND filter in front of the ISS inner loop
• Commissioners left a alog 
• VAC - Chandra - take visitor to EX around 9:30 for les than an hour
• VAC - visiting CP3 this morning
• VAC - Kyle at EX this morning for about 20
• VAC - JimW - will modify to restart automatically

FRS:  reviewed

Currently:  no locking with Peter in the PSL modifying the ISS beam path

Sheila, Kiwamu, Evan, Matt, Lisa, Jenne, Corey

Tonight the locking has been stable enough that we were able to try several low noise steps.  We ended up with a range of about 20 Mpc, and were locked for 3.5 hours.

• Earlier this afternoon Matt, Evan, Kiwamu, and reduced the ISS loop gain by 4dB, to reduce the gain peaking visible in Peter King's plots (29725)
• We've used the guardian states LOW_NOISE_ASC (for reducing arm loop bandwidths, which Jenne checked out earlier), COIL DRIVERS (after a few additional bug fixes), LOWNOISE_ESD_ETMY, and ran the A2L script for the test masses.
• Kiwamu noticed that the AS WFS DC have been close to saturation at 50 Watts.  This might have been part of the reason the OMC alignment was railing in some locks.  To help with this he reduced the modulation depth for 45 MHz by 3dB, and moved the REDUCE_MODULATION_DEPTH state to before the power up. The OMC drives are not large right now.
• Kiwamu reduce the DARM gain by a factor of 2 (in guardian at DC readout) because there was gain peaking.
• We reduced CSOFT PIT back to 0.2 for the digital gain, and CSOFT Y from 3 to 2.
• We have not used the third loop tonight.  We accidentally powered up with it off, and that has been fine.  With the 3rd loop off we don't have the low frequency ISS oscillations that caused us to DC couple the ISS last night.
• I also made a few changes in the IMC LOCK guardian. After talking with Keita, we realized that if the 1st loop saturates and turns off, the second loop would not be turned off.  The guardian is now written to handle this, but I don't think this has happened tonight so we haven't tested it. 
• We measured the SRCL and MICH loops (screenshots and data attached). SRCL still has 6dB of gain peaking, the MICH loop would have been unstable with the boost that gets engages in the state NOISE_TUNNINGS, so we increased the gain by 3dB to a digital gain of 2. 
• When need to move SRM ASC loops off the dither before we reduce the gain of SRCL.  We were sucsesfull for PIT, using 4*ASA36I-ASB36I, and a gain of 3 (FM1 off).  We picked this matrix about 3 hours into a lock, after the thermal state had stabilized.  The next lock we tried it shortly after powering up, and it seemed fine.  We haven't added this to the guardian but probably could.  We tried a similar procedure for YAW, but about 2 hours into the second lock we opened the loop because SRM was slowly becoming misalinged. 
• We tried MICH and SRCL FF, MICH worked fine with the old settings, and improved the noise around 100Hz, we are now limited by SRCL at 50 Hz and below.  We tried SRCL FF, but it made things unstable so we need to check on it tomorow.
• Evan updated the calibration. It was off by 20%. 
• For our last lock, the violin mode damping was somehow off the whoel 3 hours.  Rung up violin modes ended up breaking the lock.  If tomorow's operator has a chance to lock at 2Watts and damp violins using the instructions on the wiki, that would be great.

Kiwamu, Lisa

We monitored the intensity noise coupling to DARM over more than 2 hours during one of the long lock tonight by injecting noise in the ISS outerloop excitation point.

Labels correspond to local times (September 16).

The coupling changes significantly over time. Kiwamu tried to reduce the CO2 ITMX power to see if we could maintain a low coupling, but that didn't really work.

After a couple of hours we could clearly see the coupling getting significantly worse (red trace). 

Tonight there was a flurry of activity with H1.  There were issues with locking at the beginning of the shift, but it got better....we had a range reminiscent of H1 during S6:  19Mpc!  :)  Slowly but surely, we're gettin' there.

Locking Notes:

At the beginning of the shift, had issues locking ALS.  This was traced down to the wrong polarizations.  

• Adjusted polarazitaion for Y-arm PLL.  Also had VCO guardian error message, so it was RESET.
• Also had same issue with X-arm, so did both of above.
• Before getting to DC_READOUT, Guardian had an issue with ENGAGE_SRC_ASC.  Jamie & Jenne troubleshooted the issue and finally got guardian going again.
• While at DC Readout:  Chris & crew(s) ran some measurements.
• Had a nice 2.5hr long high power lock.  Terra chased some PIs.  Kiwamu & Sheila eventually took us to nearly 20Mpc, and then we lost lock.
• While reacquiring, the ETMx was off a bit, but eventually got it back.
• DRMI looked off in yaw & dead.  PRMI looked ugly, too.  So, we misaligned PRM & adjusted the BS (in yaw).  This got us partly there.  Then Sheila had me restore the PRM & then tweak it such that we had decent PRMI flashes.  Eventually locked up and had no issues getting up to 50W.  (Oh, we did need to employ the BS excitation trick that Sheila alogged about on Tues night.
• Kiwamu, Sheila, & Matt will now tinker with a 50W H1....whoops, it just broke lock...time to sneak out!  :)

FOM Note on Nuc5:

Cheryl mentioned this was booted during the day, and then it died & no DMT Viewer/DTT came up on their own.  I rebooted nuc5 and conversely to last night, the DMT seismic trends looked fine & current.

Since the lock was so stable, I could not avoid measuring the DARM open loop for calibration purpose tonight. I have tuned the excitation amplitudes of the 4-1200 Hz DARM OLTF template because some frequency points had too high excitation causing saturation on ETMY DACs. Also for completeness, I have taken a Pcal sweep as well. I will analyze the data later.

The dtt files can be found at:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/2016-09-15_H1_DARM_OLGTF_4to1200Hz.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/2016-09-15_H1_PCAL2DARMTF_4to1200Hz.xml

Matt, Terra

Status of PI after TCS work and ring heater change transient (for at least the first three hours of 50 W lock):

1. Successfully damping all modes (with some caveats; see #4,5.)
2. Actively damping ITMX 15520, ITMY 14980 and 15515, ETMX 15541 and 15008, ETMY 15542, 15009, 18041 and 18059 Hz. Of these, the 18kHz and 15kHz only ring up during the transient. 
3. All modes are now getting damped using the PLL. One motivation for this is avoiding saturations. I'm fairly certain that the mysterious sign flips and illogical behavior when increasing gain in the past have been due to something saturating along the loop, usually resulting in ringing up the mode. 
4. 15009 Hz (MODE 26) is still a bit confusing: it rings up twice during the transient period and appears to require a sign flip to damp each time. I'm not yet convinced this isn't just a byproduct of the transient though (we flip a gain sign and see a slow downturn on the same timescale as the transient passing, attributing the turn around to the wrong reason?). 
5. After ~2 hours, 15541/2 Hz (MODE 17/25) ring up. While we have the actuation strength to damp these, these modes are ~.5 Hz apart, so the PLL is having trouble staying on the right one and I had to do lots of actively jumping back and forth between controls. We are going to try sending both drive signals to both optics, etc. 

3 hours into the lock and all PI's are stable. Leaving PI control with Matt for the night. 

Kiwamu I, Jeff K, Darkhan T,

Overview

Today we looked at the calibration line coherence values calculated in the front end. We discovered that in the front-end model with the currently used averaging parameters the coherence value is updated once every 10 seconds (first 1.5 minutes in Fig. 1).

We propose modifying the averaging code to improve coherence calculation and avoid potential aliasing (see details).

Details

A front-end model that calculates coherence uses N data points taken every S_cycles computational cycles to calculate cross-spectral density of the signals. S_cycles is controlled by an EPICS record $(IFO):CAL-CS_TDEP_COH_STRIDE (or simply STRIDE): S_cycles = FE_RATE * STRIDE. There are drawbacks associated with this approach:

• New coherence value will appear every STRIDE seconds;
• Skipping data points will produce aliasing.

We can deal with the first problem listed above by reducing STRIDE. On Fig. 1 we show coherence values for N = 10 and STRIDE set to 10, 5, 1, 1/16 and again 1. Notice that this test was done when the IFO was not locked, thus we do not expect a coherence of ~1. When STRIDE is set to 1/16, we can see that the number of averages must be increased in order to include actual fluctuations in the signals (in the last 2.5 minutes N = 120).

Fig. 1

Several minutes later IFO locked (at t = -5 in Fig. 2) and the coherence became ~0.8. After we set the line amplitude to its nominal value we got coherence of ~1.

Fig. 2

Next, to avoid aliasing we should use all data points (equivalent to setting STRIDE = 1/FE_RATE in the current code) and increase N accordingly. Thus to integrate over 10 seconds and avoid aliasing the current code will require O(FE_RATE * 10) = O(160k) operations per cycle and a buffer for 160k values, which is unnecessary expensive.

A following minor modification of the averaging code can solve the issue described above. Instead of adding every S_cycles'th data point into the averaging buffer, we could insert an average of S_cycles values. E.g. buffer_and_average() can be modified as follows:

...

    static int mini_sum = 0;

...

    //Increment cycle count
    mini_sum += data;
    cycle_counter++;
    if (cycle_counter >= cycles_between_data) {
        buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
        current_pointer++;
        cycle_counter = 0;
        mini_sum = 0;
    }

...

With this modification and N = 160, STRIDE = 1/16 (S_cycles = 1024), the coherence will be calculated with 10 second integration and will require O(160) operations per cycle, and the coherence value will be updated every 1/16 of a second.

WP 6087

The GDS software has been updated to branch 2.17.4 to address Bugzilla 897, 936, and 952.  Release notes (T1600007) document has been updated.  This affects Ubuntu 12 and Ubuntu 14 workstations.