Nic, Evan, Jenne

We tried looking at the efficacy of MICH freeze with DRMI today.   

First, we looked at the MICH fringe velocity in Michelson-only: With the MICH freeze engaged, the fringe velocity seems to slow down by a factor of about 2 versus without the freeze.  

Then we aligned the DRMI and tried to get some locking statistics (length of time waiting for lock) with the freeze on vs. off, but we aren't really getting any locks at all.  We waited more than 15 minutes without a lock with the freeze off, so we went to trying with the freeze engaged.  With MICH freeze engaged, we had 2 wait times of 2 or 3 minutes, but all other times have been more than 15 minutes.  (We tried changing trigger threshold settings a few times, which is what defined the ends of these 15 minute wait stretches).

So far, it's not clear to us whether the MICH freeze is having a significant effect at all.  We think we'll try again later.

Nic, Jenne, Evan

In spite of the bad POPAIR situation, we were able to get DRMI to lock by increasing the whitening gain of POP18 (from 12 dB to 45 dB), and by lowering the trigger thresholds for MICH by a factor of 10, and SRCL by a factor of 5.

After DRMI locked, we were able to optimize the buildups of POP18 and AS90, mostly by moving PR3 positive in pitch, and then compensating by moving PR2 negative in yaw. In this way we increased the buildup of POP18 by a factor of 45. (We then undid the extra analog whitening gain.) So this seems to support the idea that our issues are caused (at least partially) by misalignment of the power recycling cavity.

We went onto the table and again tried to resteer onto POPAIR_B, but we got only 10 % more power on the PD. POP18 is now at about 6 ct (normalized), whereas we expect about 300 ct for DRMI without arms. So there is still a missing factor of 50 somewhere.

We measured the OLTFs of PRCL, MICH, and SRCL, and they seem fine. So the DRMI LSC seems healthy as far as we can tell; there's just some problem with the POP path.

I've been working on a diagram of the timing system with specific locations and uses of every timing system component. I've put it up on DCC as https://dcc.ligo.org/LIGO-D1500201. I'd appreciate feedback regarding what else would be useful (while bearing in mind that I'd like this to stay clear and simple). I'm also happy to make extra pages if someone needs a detailed view of some particular element of the system that wouldn't fit into the overview shown.

Happy 4th!

Jenne, Evan

Tonight we ran through initial alignment of the corner in order to get back to DRMI locking (without arms). This is a bit different than usual, since we cannot use the X arm as a reference for PR3 (via the COMM beat note) or for IM4 and PR2 (via the IR input pointing).

Initially we just restored the suspension slider values for PRM, PR2, PR3, SR2, SR3, SRM, and IM4 to their pre-vent values. Then we tried locking PRX, but found that we could not get decent fringing, even by moving the PRM a milliradian or so in pitch and yaw. So we instead restored the pitch and yaw values of PR3 as seen by the oplev, and then optimized the fringing using PR2 and PRM. This allowed us to lock PRX with a decent amount of light at the AS port (>1000 ct on ASAIR_LF with 10 W PSL power), and we then engaged the PRX WFS loops as usual.

We were able to lock the dark Michelson and optimize the BS angle without issue.

We were able to lock SRY using a similar philosophy as PRX: we restored the SR3 alignment to its pre-vent values as seen by the oplev. After that, we saw fringing and were able to optimize it by moving SRM. Then we were able to lock SRY and engage the SRC alignment loops without issue.

Then we tried moving on to DRMI locking. The flashes at the AS port look more or less normal, but there seems to be very little going on in POP18. We saw some flashing with peaks < 1 ct, but for normal DRMI acquisition we expect hundreds of counts. We went onto ISCT1, and found that the beams were low (by about 1 mm) on both the POPAIR diodes. We adjusted the spot on POPAIR_B so that it is more centered, but this only brough the flashing up to at most 15 ct (at 20 W PSL power).

Since it seemed that the POP path was somehow not aligned, we then relocked PRX (with WFS loops feeding back to PRM) and moved IM4 while watching the spots on the POP QPDs. We centered the spots as best we could, then ran through the other initial alignment steps again, and then tried locking DRMI. However, this did not improve the flashing in POP18. For the time being, we reverted our change to the POPAIR_B pointing on ISCT1.

JCD:  Since we were able to lock the individual pieces of the vertex, it seems like the vertex optics are all aligned to one another, however I am less confident in the overall alignment (e.g., the input pointing doesn't match what the Xarm will want, so we're not hitting all of our PDs simultaneously).  I am not quite sure how to resolve this, with the sensors that we have at our disposal right now.

Inner Loop

ISS Inner Loop has  UGF of 22 KHz with a phase margin of about 50 degress. This was measured with variable gain set at 6 dB for the best phase margin. This is the normal operation settings for Inner Loop.

Outer Loop

Outer Loop has a UGF of 1 KHz ( designed for 4 KHz) with a phase margin of  about 30 degrees. The variable gain was set at 40 dB (max available) and an additional gain stage(?) was switched on as well.

Also tried moving the the Inner loop gain to see if it shows any improvement on the outer loop but no luck.

TF Plots are attached.

I selected a loud sine-gaussian injection done during ER7 at each site and compared h(t) data from the HOFT frames against the intended strain waveform; this is documented at https://wiki.ligo.org/Main/HWInjER7#Injection_sign_check .  It looks like the injection came through with the wrong sign at LHO, but with the right sign at LLO.  This should be investigated.

(evan jenne nic)

We wanted to investigate the OMC alignment/backscatter problem. Driving the OMC SUS in Yaw has been known to cause backscatter noise due to the modulation of the optical path length when the OMC moves in Yaw.

Our procedure was to lock the vertex optics in a bright michelson configuration (a state has been added to the IFO_ALIGN guardian to make this easy). Then we wanted to drive the OMC in yaw and choose the yaw->longitudinal matrix element such that the center of rotation would be about the input beam, rather than the omc center of mass. This would be determined by minimizing the scatter as measured by either OMC trans, or the MICH error point.

I was surprised that we were not able to induce any significant backscatter fringe wrapping noise in this configuration. We drove the OMC SUS in longitude up to the point that the beam was misaligning enough to noticibly affect the OMC DC trans.

We also drove the ISI table directly by putting a 1Hz 1mm injection into the Y isolation loop error point. 

Driving the path length, we both listened and had a live spectrum running. We saw no evidence of scatter in either OMC trans or MICH_IN1.

We will need to think if there is another configuration (available to use without arms) that will be more sensitive to backscatter.

8:52 Sudarshan work on ISS

         Fil to EX (run cables)

9:16 Jordan to HAM6 checking on PEM sensors

9:44 Kyle to HAM6

10:01 Kyle grab He bottle at EY

10:15 Leo - EX ESD measurement

10:20 Kyle out of EY

11:25 Dave and Stefan to EY - Hook up GPS receiver

11:32 Fil & Andrea back from EY

11:50 Jordan to LVEA testing PEM accelerometer

12:04 Leo done with EX ESD measurement. Starting EY ESD measurement.

12:47 Jordan back

13:00 Kyle to EX

12:42 ISI HAM5 tripped

           -No correlation with PEM acc. sensors. Not sure what happened. Coincides with sharp peak on 1-3 Hz ground motion plot. Suspect electronics issue.

13:42 Fil and Stefan to EX by the rack

13:53 Jordan to EX

14:12 Leo finished EY ESD measurement

14:24 Rick and Sudarshan to LVEA - ISS work by PSL enc.

          Kyle back

14:37 Jordan to EY

15:00 Fil & Stefan back

15:10 Rick & Sudarshan back

15:19 Sudarshan & Jordan to IOT2R table

15:27 Kyle to HAM6

15:41 Kyle back. Shutdown HAM5, HAM6 annulus pump.

Other notes:

- Jordan discovered magnetometer at EY rack output straight line since June 22nd.

- Laser Hazard notifications added to Ops Overview.

HAPPY HOLIDAY!!!!

More charge measurements. Plots are attached.

Jim, Daniel

I calibrated the frequency of the CsIII Cesium Standard Atomic Clock in MSR by setting the Output Frequency on to 1 + (1010 * 10^-15). I did this at 12:26 PDT on July 2, 2015. I used the serial port on the back of the clock and the Monitor2 software installed on the IBM Thinkpad in MSR.

The previous setting was +1078 (parts per 10^15); I calculated the proper value to be 1010 (details below). I used the time difference between the atomic clock's 1PPS signals and our timing system's 1PPS signals. I took a linear regression to determine the rate of linear drift of the CsIII, since an improperly calibrated Cesium clock shows very little short-term jitter but does show long-term linear drift. Our timing system is long-term accurate since it's GPS backed.

I interpreted the meaning of the time difference according to an explanation from Daniel: a negative time difference means that the external (i.e. Cesium) 1PPS signal is ahead, while a positive time difference means it's behind. I calculated the drift rate to be approximately -6.8e-14 corresponding to -175 ns per 30-days.; the CsIII 1PPS is getting earlier and earlier relative to the timing system 1PPS, suggesting that the period is a bit short. I calculated the proper setting for the CsIII, as explained below, and talked to Microsemi's customer support to confirm that the CsIII's output frequency setting is what one would expect (the instructions were vague). He agreed with my interpretation but didn't have deep knowledge of the system. So we'll have to keep an eye out and check the drift rate in a few weeks to see if it is indeed close to zero (I expect it
will be fine).

The offset to be entered was calculated as follows. The current 1PPS period is given by tau_{measured} - 1 = m_{drift} where m_{drift} is the drift rate. If the clock's "natural" frequency is f_{natural}, then the current offset (Delta{f})_{measured} (which I found to be 1078 * 10^{-15} according to the Monitor2 interface) relates to the current measured period as (1 + (Delta{f})_{measured})f_{natural} = f_{measured} = frac{1}{tau_{measured}}. We want f_{calibrated} = 1, so we need to set (1 + (Delta{f})_{calibrated})f_{natural} = 1 = (1 + (Delta{f})_{measured})f_{natural}tau_{measured}, which simplifies to 1 + (Delta{f})_{calibrated} = (1 + (Delta{f})_{measured})tau_{measured}, giving (Delta{f})_{calibrated} = (1 + (Delta{f})_{measured})tau_{measured} - 1 = (tau_{measured} - 1) + (Delta{f})_{measured}tau_{measured}, or, in terms of the drift rate, (Delta{f})_{calibrated} = m_{drift} + (Delta{f})_{measured}(1 + m_{drift}), which we then divide by 10^{-15} in order to get the value to be entered into the Monitor2 software. See the attached code (written in Julia) for the precise method used. The output (besides the graphs, also attached) includes the above calculations:

Drift rate in Time Code Generator in MSR: -6.786047272268983e-14
Drift rate in Time Code Translator in EX: -6.788794482601771e-14
Drift rate in Time Code Translator in EY: -6.780539996010063e-14
mean_drift_rate = mean($(Expr(:comprehension, :(channel.drift_rate), :(channel = channels)))) => -6.785127250293606e-14
delta_f_measured = 1.078e-12 => 1.078e-12
delta_f_calibrated = mean_drift_rate + delta_f_measured * (1 + mean_drift_rate) => 1.0101487274969909e-12
what_to_enter_into_monitor2 = delta_f_calibrated / 1.0e-15 => 1010.1487274969908

Note that the drift rates calculated for each channel are in very close agreement. I used this to pick the new setting of 1010 for the Cesium clock. The channels I looked at were:

H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Time Code Generator in MSR)
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Time Code Translator in EX)
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Time Code Translator in EY)

The timeseries (with linear regressions) and histograms are included. The period analyzed is from the beginning of ER7 until last week. I had to remove a chunk of spurious data from the EY channel since Dave and I were using the BNC cable for a different test and polluted the EY channel during that time.

The linear regression shows a very clear and steady trend, as expected. Standard deviation of the atomic clock offset is reduced by a factor of five once linear drift is accounted for, and the histogram more closely follows a Gaussian distribution:

std(z) => 1.1845358220722136e-8    # Jitter about linear trend
std(y) => 5.853090568967089e-8      # Absolute time difference

Filiberto, Jim, Dave

Installed one new CNS Clock II in each end station in receiving, directly above the Timing IRIG-B Module in each rack. We tested each unit to make sure it successfully locks to a GPS signal.

Filiberto ran an extension cable for the GPS antenna from VEA into receiving in both end stations in order to provide signal for the new CNS II as well as a BNC cable from receiving to CER to deliver the CNS II 1PPS signal to the third time difference port of the Timing Comparator located there. The cable lengths for the 1PPS signals are the same to within an inch.

Upon completing the leak testing of the Y-end yesterday, Gerardo and I realized that we had failed to test the 4.5" blank which had replaced the 1st generation ESD gauge on BSC9 at the X-end.  So... 

~1345 - 1415 hrs. local 

Replaced X-end turbo scroll baking pump with LD and sprayed 20 seconds of audible helium flow at untested CFF -> OK -> Restored pump configuration to as found -> Shut down LD 

Scott L. Ed P.

6/30/15 
Cleaned 62 meters ending 1.5 meters north of HNW-4-097.
 
7/1/15 
Cleaned 47.4 meters ending 13 meters north of HNW-4-099.

7/2/15 
Finished crevice cleaning and testing. Results posted here.


X-ARM IS COMPLETE.

This is the (delayed due to conference travel) summary of my DQ shift for 12-15 June mentored by Andy L, the detailed report is at https://wiki.ligo.org/viewauth/DetChar/DataQuality/DQShiftLHO20150612

Friday 12th: No science data

Saturday 13th: Few minutes of science data

Several blip glitches occurred during that time, eg this one

DAC glitches were noticed in LSC-MCL_IN1, these seem to come from SUS-MC2_M3 as shown by the lineup plot :

MC2_glitching002.png
 

Sunday 14th: Several hours lock, several hours of science data

Much of the data was clean with good sensitivity - but there were significant bad periods of excess broadband and/or low frequency noise during hour 8 UTC (spectrogram link) and hour 10 UTC (link) which killed inspiral range.  The excess noise appears also in a large number of ASC and LSC channels but no clear cause.  Does anyone have an idea what could have been going on at these times?

One curious feature was a band of excess noise over 60-75 Hz appearing at almost exactly 12:00 and gradually moving up and down in frequency until hour 17 UTC when it suddenly disappeared.  See spectrogram link for an overview.  Again this is mysterious and any clues from on side would be welcome.

It is clear from the spectrograms and omicron triggers that there were a few (about 1 per hour) really loud glitches - SNR > 1000.  It has been suggested these are related to beam tube cleaning and its aftermath (e.g. particles loosened & falling through the beam).  See omega scan of the loudest

Another feature seen previously is a set of near-periodic glitches at 60Hz, approximately every 72 minutes.  These are associated with activity in the SUS-ETMY_L2 auxiliary channel, 'something happening' at the Y arm end station with ~4300s period.

Monday 15th: Tiny amount of data

Danny Sellers, LLO Laser Safety Officer, unplugged and locked out the PSL HPO diode box power supplies to prevent the accidental activation of the High Power Oscillator. 

See photo. The appropriate laser safety documentation concerning the operation of the PSL is being reviewed and updated to reflect the implementation of this new administrative/ engineering control

Note: Having the HPO diode box power supplies off does not interfere in the operation of the 35W Front End laser. 

Also note that LHO made the same change today.

Calibration Team

Sign of h(t):

The gravitational wave strain h(t) is given by  h(t) = Delta L/L where Delta L  is is computed using

                         Delta L = ± (Lx - Ly)

The sign of Delta L can be determined using Pcal actuation on the test mass. Pcal only introduces a push force  so pcal readout signal (truly pcal excitation) is minimum when the testmass is away from the corner station (closer to pcal laser). From the first plot the phase between DARM/PCAL is ~ -180 degrees (DARM lags PCAL) which suggests that DARM signal from ETMX will be maximum when pcal is minimum (ETMX further away from corner station). Similarly, from second plot, since DARM and PCAL have a phase difference of ~-360 degrees (essentially 0 degrees), the  DARM signal from ETMY is minimum when the pcal is minimum. This shows that the sign convention for the Delta L is '+'

Time Delay between Pcal and DARM:

Also the slope of the curve gives the time delay between Pcal and DARM signal chain. The time delay is about 125±20 us. This time delay can be accounted for, within the uncertainity, from the difference in signal readout chain outlined in Figure 3 attached.

Refer to LLO alog #18406 for the detailed explanation behind this  conclusion.