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

Forgot to post this yesterday. This is the Ops Summary for Wednesday July 1st.

8:26 Leo - ETM ESD charge measurement

8:56 Jodi/Jeff to warehouse and Mid Y

9:22 Elli to IOT2R

9:30 Jodi and Jeff B. back

9:35 Gerardo to EX, EY pick up equipment

9:36 Elli to EY

9:41 Jordan to EX testing PEM acc. meter.

10:01 Elli back

10:10 Karen to LVEA

10:17 Jeff K. to LVEA (ISC rack by PSL room)

10:40 Jeff K. back

10:41 Jeff B. to 3IFO area

10:58 Ed to ETMX increase oplev laser power

11:03 Jeff B. back

11:12 Gerardo back

11:14 Fil to End stations - run cables for second pressure gauge

11:22 Gerardo back

11:50 Jason, Ed test turning off HPO box

12:00 Jason, Ed back

12:16 Fil back

13:01 Jordan back

13:07 Kyle climbing on HAM6

13:34 Kyle - vacuum work around HAM6

13:50 Gerardo climbing HAM6

13:56 Gerardo done

14:15 Daniel, Nutsinee to EX

           - turned on green laser, adjusted Crystal Frequency to get the beat note in range, PLL locked.

           - EX Lazer Hazard

15:30 Daniel, Nutsinee back

15:40 Kyle, Gerardo back from EY

15:45 Nutsinee to EY turned on Green laser. EY now Laser Hazard.

16:13 Leo finished with ESD measurement

More charge measurements.
Two plots in usual style, and other couple of plots show the same measurements separately for each QUAD.

(Kyle, Gerardo)

Y-End station:
Connected and ran leak detector at turbo's exhaust in place of scroll pump, sprayed new, untested, conflats with 20 seconds of audible helium flow.
No leaks detected.
Turbo pump restored to original configuration.
Pump down continues.

Conflats tested: new Inficon gauge for ESD interlock, NEG pump 10" gate valve conflat only, Old TMDS valve + blank on middle port north door, New TMDS valve + elbow + blank on south door, and new blank for the removal of the old type gauge for ESD interlock.

Local controller shows correct voltage and current -> The signal wiring for this unit has never been correct since an additional terminal strip box was added to facilitate moving the original ion pump controller rack as required by the placement of the HEPI pump stations -> I'll consult with the EE folks

I've seen and noted this before.  It has been present since early Feb when the sensors were quieted and the noise dropped enough.

If you look at trends, there is a brief upward spike on all the pressure sensor channels at the EndY HEPI Pump System that occurs everyday at 0329utc +- seconds!.  Additionally, there is a weekly (Sunday) double glitch.  The first glitch of the Sunday double occurs at the same time as the daily and looks similar and a second (slightly different) hits 20minutes later followed by a downward glitch 10 minutes later.  Yes, every day and every Sunday.

The pressure does cause the pressure servo to react--see the CONTROL_VOUT.  The glitch is actually a 40 second climb of the pressure which the servo attempts to counter with a reduction of the drive output.  If the servo was driving the pressure, the sign would be reversed.

The glitches don't show in the position controllers or the inertial out of loop hepi sensors.  The Actuator performance must not be that sensitive to the absolute or differential pressure.  So, this really is not an IFO issue but we should figure out what is causing this.  This is not seen in the other Pump Station's pressures but they may be currently too noisy.

Attached are 2 hour second trends of the daily and weekly glitches.  Posting this here for the record and will open an integration issue.

Anyone else see anything at this time?

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.

Don't forget laser goggles!

I reported suspisions about the ETF (Stanford) Seismometer that is now wired up as the STS2-A or HAM2 ground sensor.  That was ten days ago and here is another look from earlier this morning.  Pretty much same conclusion:  The ITMY and HAM5 units show very good coherence even though they are separated by 30meters.  The HAM2 & ITMY sensors are just a couple meters apart and they are no showing the coherence they should: and the HAM2 & HAM5 sensors coherence is similarly poor..

While the problem may be cable or setup (level or igloo rubbing) I suspect the unit itself.

BTL: Any word on these instruments from your experiences?