Due to a crazy big offset of -0.5 in Y_TR_B_PIT (for SOFT modes sensing), Y IR QPDB is almost always railing a bit in 24W operation, and Y IR QPDA is not too far.

Next time IFO drops out of lock, somebody needs to lower the whitening gain by 3dB and set a new dark offset for each quadrant.

The landscapers will be out this weekend-Saturday and possibly Sunday for weed control in front of the OSB, Staging Building, and the LSB.

Patrick handed off an H1 which has been at Nominal Low Noise since about 5:30utc (10:30pmPST) with a range hovering around 70Mpc.  There was a noticeable step down in range (~60Mpc) at 12:04UTC for about 30-60min (Patrick notes several ETMy saturations around 12:10UTC & Ed notes there were earthquakes aroudn 12:15UTC).

Injection around 11:15UTC?

Looks like we have been in Observation Mode since 6:00UTC, but GWIstat says we've only been in this state since about 11:15UTC (this isn't Peter's Burst from last night....maybe a Transient Injection?  Or some other injection?  Is there a schedule for these things??).

Today's Outlook:  PEM Injections for good chunk of day

Will stay in Observation a little, but Robert says he said would like to start PEM Injections within an hour or so (~16:45UTC?), and will be PEM Injecting for a good chunk of the day so he does not have to do much on Saturday.  Have just talked with Lisa at LLO and they will be interested when we go out of Observation, so they could also go out and do some much-need commissioning.

Seismically, we look fairly quiet with microseism noticeably trending down by 0.1um/s over the last 24hrs.  Winds are also quiet.

ER8 Day 18, no restarts reported.

Per request by Robert Schofield, I am lowering the air flows in the LVEA to allow him to preform his injections.

These will be going down from ~15000 CFM to ~11000 CFM. Since the weather is cooling down, I will leave these flows at this rate until something or someone convinces me otherwise.

12:45 UTC Christina here
12:51 UTC Karen here

More SUS ETMY saturation alarms. Most if not all were coincident with glitches in the spectrum. List of all from verbal alarms script:
SUS E_T_M_Y saturating (Fri Sep 4 8:13:12 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 8:28:3 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 8:28:5 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 10:40:16 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 10:51:18 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 11:15:5 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:10:24 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:10:26 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:10:28 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:10:30 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:47:13 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:47:26 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:47:29 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 12:48:39 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 13:24:44 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 13:24:46 UTC)
SUS E_T_M_Y saturating (Fri Sep 4 14:44:33 UTC)

Nice quiet shift otherwise. H1 remains in observing mode around 70 Mpc.
Handing off to Corey. 

A scheduled burst hardware injection was done early this morning, at GPS 1125390500 = Sep 04 2015 01:28:03 PDT, that was extremely loud.  It was detected by Coherent WaveBurst (see https://gracedb.ligo.org//events/view/G181472) and also produced several MBTA triggers that were inserted into GraceDB, with (inferred) coalescence end times up to 37 seconds later.  I have removed all future burst injections from the tinj schedule file so that no more will be done until we sort this out and make sure that future injections will have reasonable amplitudes.

Received H1 locked and in observing mode from Cheryl.
Cleaned up control room. If you are missing something check the cardboard box on the floor behind the computers to the left as you come in.
Checked IP9 as requested by Gerardo. High Voltage is around 7 kV for both A and B.
Moved cameras looking in PSL enclosure to see that they were not frozen. Lights are off in PSL enclosure.
Moved cameras in LVEA to point to doors. Lights are on in LVEA.
Lights appear to be off at all mid and end stations, but I don't entirely trust those cameras. I don't seem to be able to move end X. mid Y is constantly flickering green horizontal lines.
Darkhan and Sudarshan were the only people left in the control room after Cheryl left.

08:07 UTC Darkhan and Sudarshan leaving. I'm all alone.
08:13 UTC I shut down all of the workstation computers in the control room except the ops station.
08:38 - 08:44 UTC I stepped out to use the restroom.

SUS ETMY voice saturation alarms at: 08:13:12, 08:28:03, 08:28:05, 10:40:16, 10:51:18 UTC. Have caused glitches.

H1 remains locked slightly below 70 Mpc.

- Quiet night in terms of locking.

- Most of the night dedicated to PEM injections.

- One lock loss due to injections (PEM).

- Relocking went pretty well, with the biggest thing being that I had to reset the EX ALS VCO (on the VCO screen).

- Transient injections are again enabled.

- Only ~9 hours of lock time during the 3 days

- Low glitch rate during lock time

- 60 Hz magnetic glitches showed up again at EY

- 2 interesting glitch types seen in evening of Sept 2:

    - 90Hz lines in ASD-AS_A_RF45_Q_YAW_OUT_DQ (found by Hveto)

    - some loud triggers in CBC BBH that looked like lots of vertical lines at around 100Hz.

- Full DQ page: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20150831

Eric, Cheryl

Following advice from D Shoemaker et al., we have disabled the LIMIT on the HWINJ filter bank. The change was made at approximately GPS = 1125361473. The LLO LIMIT was turned off earlier today:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=20249

J. Kissel

More UIM driver spelunking uncovers a false alarm, but a definite bug in the QUAD front-end code.

I found that the H1 SUS ETMY COILOUTF Bank (the bank that compensates for the analog coil driver electronics frequency response) for UIM / L1 stage has its last set of filters which compensated for the last stage of z:p = 10.5:1 [Hz] low pass were errantly OFF. Thinking that this might be the source of the frequency dependent descrepancy I've been whinning about for the past week in the measured UIM actuation strength (identified in LHO aLOGs 21015 and 21049), I made sure to conlog back to the state of the BIO request and filter banks during those measurements. Yup -- these compensation filters were OFF then too.

BUT -- IT DOESN'T MATTER.
(1) If there were a low-pass ON without an appropriate compensation filter, then we would see a *reduction* from 1/f^6 drive strength in the measurement starting at 1 [Hz]. We see an *increase* measured drive strength from 1/f^6 starting at ~50 [Hz]. 
(2) *If* there was a low-pass ON we would see a reduction in actuation strength. However, in State 1, there are NO low-pass filters ON (see T1100507 -- note that this document has NOT been updated to reflect the chage in zero frequency of the output impedance network). Further, because of the simLP3 / antiLP3 perfect compensation, which is what *would* be on if there were no bug, then there is no difference betweeen having both ON and both OFF. That means as long as the antiAcq filter was ON, and it was, then the driver response is compensated for correctly.

We're in full lock so I can't further confirm this bug, but we should.

Why hasn't the SDF caught this? Because the user requested H1:SUS-ETMY_BIO_*_STATEREQ is supposed to control these filter banks, so we've chosen to not monitor them in the SDF system. Perhaps we should change that decision. 

Or perhaps we should just fix the bug.

I have checked all front end code (model source, filter modules, safe.snap and guardian) which had local mods into svn. h1susitmy had a partial filter load; after verifying the filter changes had all been individually loaded, I performed a full load when the IFO was in commissioning.

To study the variation over time of the jitter peaks in the sensitivity, I computed the band-limited RMS of CAL-DELTAL_EXTERNAL between 300 and 400 Hz, for all the reasonably long lock stretches of the last three weeks. The attached plot shows the result: blue dots are the values over one second periods, while the orange traces are smoothed version over 10 minutes.

I was hoping to see some variation or trend during each lock, but apparently the amplitude of the peaks are quite constant, and it doesn't change much over each single lock. There are few exceptions: a couple of locks show very low values, but looking at them in more detail it looks like the entire sentivity was scled down, so I'm not sure if they are meaningful. Moreover, there are a couple of cases where the amplitude of the peaks suddendly decrease or increase, for example around GPS 1124092417 (Aug 20 2015 07:50 UTC) and 1124863017 (Aug 29 2015 05:55 UTC).

9/3 DAY Shift:  15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC

Locked @Nominal_Low_Noise for ~12hrs with a range ~65Mpc.  Kept H1 in Observation Mode as much as possible (there were a few errant drops & then we stayed down for PEM Injections starting at around noon (PST).  I went through the Operator Checklist & completed most of it.  I am supposed to check the Visitor Checklist, and it looks fine.  I hesitated to check the HEPI watchdog saturation counter, for fear it might add diffs to the SDF (might try it tomorrow).

Remember: 

1. AFter lockloss, "INIT" ISC_LOCK (and possibly select DOWN).
2. Re-enable Transient Injections (to make CALCS SDF green), after PEM Injections
3. Make sure SDF is made GREEN after "Commissioning" work (I see HAM6 ISI has some diffs...& I see this is probably related to PEM injections).
4. IP-9 at MY still has HV values around 7kV.

End of shift Control Room Activities:

• PEM Injections
• Calibration work (this is post-work from last week and not touching H1).
•  

Log of Activities:

• 16:45UTC 250mL added to PSL chiller (Bartlett)
• 17:19 Robert talked with LLO to coordinate dropping out of Observation Mode (plan an hour from now)
• ~18:48 Beckhoff Timing Comparator button accidentally turned OFF/ON by Kissel (BUT, we stayed in OBSERVATION mode since we currently do NOT monitor Beckhoff channels.)  The button is at:  SITEMAP --> SYS --> Timing --> Corner A --> "11" Active Port button pushed.
• 18:30-19:30 FMCS computer went INVALID.  19:41 signals appeared to start coming back.
• 19:00 Talked with Peter regarding request for starting Transient Injection.  Since PEM Injections are starting, we decided to DISABLE the "ting".  Will ENABLE when PEM Injections are complete.
• 19:08 Dropped Out of Observation Mode due to SDF diff from DISABLING Transient Injection (!). [Peter Shawhan, Corey]
  • Stayed out of Observation Mode since PEM Injections starting (Observatory Mode taken to Commissioning.) [Robert & Anamaria]
• 19:41 Corner Station Temp is low VerbalAlarm (but this is due to FMCS going down earlier). [Bubba]
• 20:42 Load Coefficients was run for SUSITMX since there were filters added by Nutsinee/Dan for violin mode work. [Dave B]

(Peter Shawhan, Eric Thrane, Corey Gray)

Using waveforms created by Chris Pankow, we have set up a schedule of burst hardware injections to occur once every 10000 seconds (~2.7 hours).  The schedule runs from now through the end of ER8, but we intend to turn them off once we've obtained 10 coherent (successful at both sites) burst injections.  This series is primarily intended to check the infrastructure, the low-latency analysis, and the EM follow-up alert generation machinery; we're not yet attempting to verify the calibration.  The injections are all scheduled for GPS times 1000*n+500, i.e. the first one should happen at GPS 1125350500, the next one at 1125360500, etc.  However, an injection will be automatically skipped if ANY of the following conditions is true:
   * The detector is not locked (L1:GRD-ISC_LOCK_OK==0)
   * We are not in Observing mode (L1:ODC-MASTER_CHANNEL_LATCH bit 0 is off)
   * There has been a GRB or SNEWS alert within the past hour (L1:CAL-INJ_EXTTRIG_ALERT_TIME is a GPS time less than an hour before the current time)
   * Injections are currently disabled by the operator (the Disable button on the TINJ / Transient Injection Control medm screen has been clicked, which sets L1:CAL-INJ_TINJ_ENABLE = 0)
   * Injections have been temporarily paused by the operator using the Pause button on the TINJ / Transient Injection Control medm screen (which sets L1:CAL-INJ_TINJ_PAUSE to a future GPS time when the pausing should end)
So, it's anybody's guess how long it will take to obtain 10 coherent burst injections.

To get this started at LHO, we needed to start the 'run_tinj' process on h1hwinj1, which hasn't been running since August 25.  I talked with Corey, who asked that we not do any hardware (strain) injections right now because the PEM injection folks were about to start doing tests.  However, we worked out that the injections can be disabled for now using the Disable button on the TINJ Control medm screen.  LHO had an old version of the screen, but Dave updated it to the latest version which has the Disable button (along with Enable and Pause).  Corey clicked Disable, and I double-checked that it's disabled by doing 'ezcaread H1:CAL-INJ_TINJ_ENABLE'.  I then did "nohup run_tinj &" at about 12:44 PDT.  So tinj is running now, but injections will be skipped until an operator clicks the Enable button on the TINJ Control medm screen.  Please do that when the PEM injection folks have finished their work - thanks!

There was one side effect that I didn't expect: when Corey clicked the Disable button, it took the detector out of observation mode.  Corey said that looks like it was done by sdf, i.e. this status (injections disabled) is being considered nonstandard.  I'm not sure if that is due to checking the value of L1:CAL-INJ_TINJ_ENABLE, or to some read-back bitmask value.  We should follow up with Jamie to find out, and take the injection enable/disable out of the configuration check if possible.  However, this isn't a problem right now because the PEM injection folks wanted to be out of observation mode anyway.

Dan, Daniel, Evan

Summary

The addition of a 9.1 MHz bandpass on the OCXO output has removed the broadband excess noise between DCPD sum and null. The dashed lines in the figure show the sum and the null as they were three days ago (2015-08-31 7:00:00 Z), while the solid lines show the sum and the null after the filter was inserted.

Details and review

Since at least June (probably longer), we've had a broadband excess noise between the sum and null DCPD streams. Stefan et al. identified this as 45.5 MHz oscillator noise a few weeks ago (20182).

In parallel, we switched the 9 MHz generation from an IFR to the OCXO (19648), and we installed Daniel's RFAM driver / active suppression circuit (20392), but the excess noise remained (20403). For a while we suspected that this was 45.5 MHz phase noise (and hence not supressed by the RFAM stabilization), but the shape and magnitude of the oscillator phase noise coupling (20783) were not enough to explain the observed noise in the DCPDs, under the assumption that the OCXO phase noise is flat at high frequencies (20582). For that matter, the shape and magnitude of the oscillator amplitude noise coupling were also not enough to explain the observed noise in the DCPDs, assuming a linear coupling from the RFAM (as sensed by the EOM driver's OOL detector) (20559).

Daniel et al. looked at the 45.5 MHz spectrum directly out of the harmonic generator in CER, and found that most of the noise is actually offset from the 45.5 MHz carrier by 1 MHz or so (20930), which is above the bandwidth of the RFAM suppression circuit. This suggested that the noise we were seeing in the DCPDs could be downconvered from several megahertz into the audio band.

Yesterday there was a flurry of work by Keita, Fil, Rich, et al. to find the source of this excess noise on the 45.5 MHz (21094 et seq.). Eventually we found circumstantial evidence that this excess noise was caused by baseband noise out of the 9.1 MHz OCXO.

Tonight we installed a 9.1 MHz bandpass filter on the OCXO output. This has removed the huge 1 MHz sidebands on the 45.5 MHz signal, and it also seems to have greatly lowered the coherence between DCPD A and DCPD B above a few hundred hertz.

Loose ends

The chain from OCXO to filter to distribution amplifier currently involves some BNC, since we could not find the right combination of threaded connectors to connect the filter to the amplifier. This should be rectified.

Also, it appears that our sum is lower than our null in a few places (400 Hz in particular), which deserves some investigation.

The attached pdf contains current Stage-1 and Stage-2 NB model performance of ITMY chamber for X,Y,Z and RZ dof. 

Fig 1- ST1 ITMY X
Low frequency near microseism model performance is limited by the ground blend filter (HEPI L4C+IPS)
1-5Hz frequency band is limited by GND-STS passing through the sensor correction path
5Hz and above (upto 10Hz say) is limited by Stage-2 back reaction
Below microseism model does not match with actual performance.       (May be because of some tilt coupling??  But it looks like actual measurement is limited by the sensor noises (T240/CPS) via isolation filter. - Not sure about it)

Fig 2- ST2 ITMY X
Instead of T240 BLND OUT,  I have used T240 BLND IN as the input (stage-1 displacement) to the ST-2 model.
Though the model and measured GS13 are in agreement above blend frequency (250mHz), the shape between 1-3Hz are not same. The model output looks more like the input signal T240 BLND IN.  May be a better input noise model will work better. 
Since the stage-2 model performance above ~1Hz is highly dependent on stage-1 displacement, we can san say that the Stage-2 back reaction on stage-1 can have effect on the final performance of the model. 
Fig 3 - ST1 ITMY Y

Most of the features and model performance are same as X dof.

Fig 4 - ST2 ITMY Y

Though this one is same as ST2 ITMY X only thing I have noticed here is the actual IFO ST1 performance is better than ST2  between ~ 300-500 mHz. 

Fig 5- ST1 ITMY Z

ST-1 model performance matches the actual measurement at almost all the frequency range of interest.  
The conclusions derived for ground model and Stage-2 back reaction hold here too.   

Fig 6- ST2 ITMY Z

Unlike X and Y dof, the model performance between 60 to 250 mHz is quite good (I am still trying to figure out why this sort of discrepancy exists between these dofs ???)
At the same time the mismatch between model and actual performance above 5Hz is noticeable. Model is over estimating the actual performance here (though the model has already included stage-2 back reaction in Stage-1)
Fig 7- ST1 ITMY RZ

Apart from the limitations of the model due to ground noise at low frequencies, the performance of this stage is mostly limited by CPS sensor noise via BLEND+ISO  path.

Fig 8- ST1 ITMY RZ
   
Please DO NOT go through this figure. Still need to sort out the problems.

   
Same sort of features can be seen in almost all the BSC chambers except BS where the stage-2 controllers are not in use. 

This entry is meant to survey the sensing noises of the OMC DCPDs before the EOM driver swap. However, other than the 45 MHz RFAM coupling, we have no reason to expect the couplings to change dramatically after the swap.

The DCPD sum and null data (and ISS intensity noise data) were collected from an undisturbed lock stretch on 2015-07-31.

Noise terms as follows:

• Shot noise
  • For 20.0 mA dc on the DCPD sum, we expect a shot noise of 8.0×10⁻⁸ mA/Hz^1/2.
• Dark noise
  • Dan and I measured this a few months ago. In full lock we use one stage of whitening, which amounts to a dark noise of 1.5×10⁻⁸ mA/Hz^1/2 or so above 100 Hz. We have at times experimented with two stages of whitening, but it requires some vigilance regarding the violin modes.
• Intensity noise
  • Coupling was measured à la Kiwamu by leaving the outer loop off and driving the inner-loop excitation point. For the noise estimation, I used the outer loop out-of-loop sensor. Since Sudarshan et al. previously found that this is artificially high, this estimation is an upper limit (though probably no more than a factor of 3, given Sudarshan's plot).
• Frequency noise [CARM sensing noise only]
  • Previously (i.e., when we locked CARM using the in-air REFL sensor), I estimated the coupling by looking at the TF in-vac REFL to DARM, and for the frequency noise estimation I used the noise of in-vac REFL as an upper limit for the frequency noise. Since we now lock with in-vac REFL, which has more light on it than in-air REFL does, I do not expect that the noise of in-air REFL is a particularly useful upper limit for the frequency noise.
  • Therefore, I have tried to instead estimate the sensing noise in CARM (from in-vac REFL, the summing-node board, the common-mode board, and PDH shot noise) in V/Hz^1/2 and propagate it (using the Izumi/Sigg expression) into a frequency noise in Hz/Hz^1/2. For the CARM optical TF I use 12.7 W/Hz at dc, with a pole at 0.48 Hz.
  • Then I have injected noise into CARM and looked at the TF from the residual of the excitation into DARM. This is the coupling TF needed to propagate the estimated sensing noise to DARM, assuming the CARM gain is high (this isn't quite true at high frequencies; the ugf is 17 kHz or so, and the gain does not exceed 20 dB until 3 kHz).
  • Since this includes sensing noise only (and not, for example, FSS noise), I have labeled it as a lower limit. In fact, the coherence between REFL 9Q and the DCPD sum is about 0.04 around 7 kHz, perhaps suggesting a frequency noise contribution of 2×10⁻⁸ mA/Hz^1/2 or so. More investigation required.
• Oscillator phase noise [not included here]
  • Stefan and I measured the coupling of the 9 MHz RF source into DARM, and using the expected performance of the OCXO estimated the noise in DARM should be 2.8×10⁻¹⁰ mA/Hz^1/2 at 1 kHz. This is quite low (and not shown on the plot).
  • This number should be replaced with Alexa's and Daniel's measurements of the phase noise. An even more satisfying number could be made by trying to measure the 9 MHz and 45 MHz phase noises in situ, closer to the EOM (e.g., at the output of the distribution system on the ISC rack).
• Oscillator amplitude noise [45 MHz only]
  • In this case we know that the 45 MHz RFAM is the dominant contributor (other than shot noise) to the DARM noise above a few hundred hertz. Here I use Stefan's estimate of the RFAM-induced photocurrent (1.8×10⁻⁸ mA/Hz^1/2), which (as he notes) is not enough to explain the excess between sum and null.
  • However, based on tonight's measurements using the new EOM driver readback, it seems that 45 MHz RFAM is enough to explain the excess. Perhaps Stefan's measurement is an underestimate, since it was done at the output of the distribution system and did not include the final rf amplifier before the EOM.
  • As for 9 MHz RFAM, Stefan and I made an estimate of the coupling from the 9 MHz source into DARM. Based on the specified performance of the OCXO, the expected noise in DARM is quite small. However, it would be better to look somewhere further downstream, as Stefan did (although I think he said the measurement was not that clean). This noise is not estimated in the plot.

The downward slope in the null at high frequencies is almost certainly some imperfect inversion of the AA filter, the uncompensated premap poles, or the downsampling filter.