Sheila Jenne

We made some quick intensity noise injections using the second loop, and jitter using the IMC PZT.  A first look at the data suggests that several of our peaks in DAM which show coherence with the ISS sensor are due to jitter coupling, rather than intensity noise. This menas that we can't fix these peaks with more ISS gain, but we might be able to do something by changing alignment offsets.

The attached plot shows the noise in DARM (taken with MICH FF off, which causes extra noise at 100 Hz), a projection of intensity noise in DARM based on the ISS PDs, and a projection of the jitter noise in DARM based on IM4 trans yaw. I"ve used a coherence cut off of 0.5 for the transfer function measurements used here.  

Still to be done:

• pico IM4 trans so that it is centered in pitch and we can get a better pitch jitter measurement
• Cut out frequencies where IM4 is sensor noise limited (this probably won't affect the peaks of the jitter projection.)
• Repeat with MICH and SRCL FF on to see what we can learn about the noise at 100 Hz. 

I have remeasured the SRCL feedforward transfer function, and put it into the SRCLFF1 filter bank, and into the guardian.

Injections were done: SRCL1_EXC from 22:24:30-22:28:40 UTC, SRCLFF1_EXC from 22:13:20-22:17:30 (no filters engaged, input off, gain=+1).

The matlab file SRCLff.m grabs the data from the injection times, and calculates what the feedforward filter ought to be.  The matlab file Fit_SRCL_Filter.m loads that filter and uses vectfit to find the appropriate poles and zeros. 

The first image (Measured_vs_fitted_SRCLff.png) shows the agreement between the calculated transfer function that we want, and the result that vectfit gives.

The second image (New_vs_old_SRCLff_filters.png) shows the difference between the old FF filter and the new one.

I then took 3 different spectra and coherences, as shown in the third image (NewSRCLff_works.png):  Blue is without any SRCL FF, brown is the old SRCL FF with the gain of -1.3 that Lisa found yesterday, and pink is the new SRCL FF with a gain of -1.  While it's not a lot, there is improvement between 10 Hz and 30 Hz with the new filter over the old.  Either one is better than nothing though.

Note also that the old feedforward scheme was using an elliptic 4.5 Hz highpass (FM8=AC2 in SRCLFF1) while I am using a much more gentle 1 Hz highpass that was already installed (FM3=AC in SRCLFF1) so that I don't change the phase of my filter as much above 10 Hz.  Both cases have the FM6 and FM7 SBVio1 and SBVio2 filters engaged. 

Kiwamu, Sheila, Terra, Corey, Matt, Lisa

We are still dominated by intensity noise, and it is unclear what is the main noise source at 100 Hz right now, but at least we went through mostly all of the other low noise steps, and the locking sequence now works up to the "nominal low noise" state. 

Sheila had put most of the tuning in the guardian already (see  here ); here are some modifications that we had to do to the code to make it run:
 BounceM0 definitions were added to ISC_GEN_STATES
 The settings for the ASC SRC1 loop were loaded, but the PITCH loop was actually not engaged, so I added that (the YAW loop still needs some work, so at the moment it is just left uncontrolled once the SRM dither lines are turned off)
  
 The coil driver switch was only switching one of the coil; we believe that's the reason why we had troubles with violin modes getting excited during several locking attempts earlier tonight. Matt fixed the code (and used "guardian -i" to test it)
 
And this is the list of the parameters that we changed:
 DARM gain is now 700; Kiwamu had changed it from 1400 after finding that the DARM loop had gain peaking, but the new setting was not properly coded in the guardian; 
 DSOFT gains were lowered to deal with a 2 Hz instability appearing in the ASC low noise transition: DSOFT PITCH from 0.5 to 0.2 and DSOFT YAW from 3 to 1 (now in the Guardian); 
MICH and SRCL feed forward tuning (I ended up with -15.9 for MICH and -1.3 for SRCL, gains are still to be fine tuned) 
 

We locked several times tonight and powering up to 50W has been very robust. Parametric instabilities have been taken care of during the whole day (Terra will comment on that, but I believe she has been using standard PI settings without the need of manually adjusting them). However, by looking at the control room monitors from the hotel, it looks like a couple of PI are about to unlock. On a positive side, the summary pages monitoring PIs are working (see for example https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20160917/isc/pi_15_5_khz/).

 Before leaving we had left the interferometer in Observing Mode @ 50W, intent bit set to enable detchar monitoring, with intensity noise dominating above 400 Hz. As yesterday, the coupling to DARM increased during the lock. PIs will break this lock. There is more low frequency noise reduction to be done, but it is not immediately clear what is the excess at 100 Hz right now. The calibration shouldn't be too off as Evan checked it recently, at least at high frequency. The range reported by SensMon is above 30 Mpc.. 

(Sheila, Terra, Lisa, Matt, Kiwamu)

SUMMARY:  Took H1 to Nominal Low Noise a few times (albeit briefly), and had issues with violin modes.

Locking Notes:

Tried locking up H1 at the beginning of the shift, but the DRMI & PRMI flashes were fairly non-existant.  Tried a few things to tweak up the alignment on-the-fly, but simply could not get any life with the Michelson.  Spent about 45min trying to get this to work.

Ultimately went for an Initial Alignment.  Had issue with a badly misaligned ALSy.  Tweaked on ETMy AND ITMy for a while before finally getting it.

There was an earthquake midway through the shift, but did not go much over 0.2um/s, so no change made to SEI_CONFIG.

Issues later in the night:

• IMC_LOCK Guardian had issues with the ISS in that it would get in a loop of OPENing/CLOSE-ing the ISS.  The IMC guardian would eventually solve its own problem after a few minutes.  
• Violin Modes for ITMy & ETMy caused us grief whenever we took a 50W H1 past Low Noise (we would make it to Nom Low Noise for a few minutes, but then we'd see the violin modes ring up).

Here is the current status of things in guardian, for people who will be locking latter tonight:

• The violin mode damping is turned off by the coil drivers state, because we found in the past that we couldn't transition the test mass coil drivers with the damping on. As we saw last night, we need to re-engage this for long locks.  This afternoon we tried not turning the violin mode damping on until after doing the coil drivers, but this rung up a mode badly enough to loose lock.  For now I have moved violin mode damping back to 2Watts RF locked. I made the violin state into a state generator, which is used twice, once when we are locked on RF, and again after coil drivers. (The same code gets executed twice).
• In low noise ASC I've added code to turn of the SRM dithers and engage the SRC1P WFS loop, it leaves SRM yaw uncontrolled. This is only partially tested, and starts on line 3488
• NOISE_TUNNINGS can be run as is, but will not engage SRC FF (just type in gain to try it, the nominal value is 1).
• I also added some code to LOW noise ESD ETMY to prevent it from running if the control has already been switched. 

Today I attempted to confirm that the X-end RGA was still functional after having been vented, removed from its protective nipple, re-installed and evacuated yesterday.  I wasn't able to do this due to an inability to connect to it with the RGA-dedicated laptop.  There is some sort of network issue that has been hit or miss for awhile now but, recently, has degraded to the point of being unusable.  I'll try again after investigating and/or at the next window of opportunity.  

Here is the current state of the H1 DAQ.

h1fw0 and h1fw1 have been completely stable for several weeks, and following the code fix on Wednesday 9/7 the frames written by both are 100% identical. These systems have the same hardware and are running the same code, but h1fw0 occasionally asks for retransmissions and h1fw0 never does. The OS install is slightly different between the machines, and we will try cloning fw0 from fw1 next week.

h1fw2 is a front end computer, running U12 with a local disk system for frames. It was running the original daqd code, but went unstable after the Sat 9/10 power outage. We upgraded it to the rcg3.2 daqd this afternoon to see if this improves stability. It is now connected to UPS power.

Now that h1fw2 has the new set of EPICS diagnostics channels I have expanded the DAQ overview medm screen to show these.

State of H1: locking and easilly getting to DC_READOUT

Activities:

• after lunch I locked H1 and went to DC readout, and while H1 was in DC Readout I worked on damping violin modes with some succes
• unfortunately H1 broke lock due to an earthquake
• since then Commissioners have been working on the ISS which included an attempt to improve the qpds with an amplifier box that has whitening gain, but this is on hold
• AC ran a bit after the PSL encursion, sothe room cooled by about 5F and is now recovering

Lisa, Sheila, Ed

Durring ER9, the intensity/jitter noise in DARM was worse than inO1, but not as bad as now.  We looked at the PSL accelerometers, and see that the table is moving about a factor of 5 more over a broad range of frequencies from 150-550 Hz. The coherence of DARM with PSL table acclerometers and the ISS PD is also increased compared to July.  The last panel shows the coherence of the table accelerometer with the ISS PD.  Ed trended PSL pressures, and found that the flow rate durring ER9 was 0.5lpm, compared to 0.7lpm now.

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)

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

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. 

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.