Let's add some statistical information on the loud glitches we've been investigating lately (see 20176, 20276, 20304).

All those glitches have a very distinctive shape: a sharp peak rising in about 1ms and decaying in about 1ms, followed by what we believe is the DARM loop response: a second slower peak of opposite sign.

I looked into all the glitches I previously identified, and run a MATLAB script to fit them with the above shape. What I'm fitting is a 100 Hz high passed DARM_IN1_DQ signal, with additional notches at 60, 502, 992, 1000, 1462 and 2450 Hz. The parameters are the rising and decay times of the first peak, its amplitude, the rising and decay times of the second peak and its amplitude. The waveform is the sum of two triangles. See for example the first two plots for a large and a small glitch.

After fitting all the 151 glitches, I actually convinced myself that 13 of them were probably of another kind, since the shape was clearly different. In two occasions (GPS 1117616943 and 1117631610) there were double glitches (see 3rd and 4th plots).

Armed with the results of the fit, I can now look at the distribution of the amplitudes with sign and of the duration. The 5th plot shows an histogram of the amplitudes. Result: there are both positive and negative amplitude glitches, but large amplitude glitches are only negative (in DARM_IN1_DQ).

The 6th plot shows the distribution of the rising and decay times of the first peak. The distribution is quite well peaked around 1 ms for the rising time and 1.5 ms for the decay time. For the second peak, rising times are peaked around 2.3 ms and decay times around 5 ms.

The last attached plot shows a distribution of the absolute value of the glitch amplitudes, in log scale. The low amplitude cut-off is likely due to my inability to detect the smallest glitches (and the threshold of 5 Mpc drop in the range). The amplitudes span a couple of orders of magnitude, with a quite smooth distribution. I see no reason why we shouldn't believe that there are many more low amplitude glitches with the same shape (and maybe origin) that we simply can't detect in this way.

The attached text file contains all the results of the analysis:

Column 1: GPS time
Column 2: amplitude of the first peak
Column 3: rising time of the first peak [ms]
Column 4: decay time of the second peak [ms]
Column 5: amplitude of the second peak
Column 6: rising time of the second peak [ms]
Column 7: decay time of the second peak [ms]

Elli, Nutsinee

We currently don't have the return SLED beam to the ITMX HWS. Not sure since when this is happened but looks like the beam splitter is likely to blame.

Sudarshan, Evan, Stefan, Shivaraj

We completed  a set of Pcal sweep measurement against the DARM for both endstation and the measurement files and the templates are stored at the following svn location.

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Measurements/PCAL/

Analysis will follow.

This morning after a lock-loss, the ETMX ESD railed, so Fil and I drove to the end station to reset it. To do this, Fil first powered off the chassis by the chamber (3rd chassis from the bottom on the right rack, power is red button on the left), then unplugged the right most cable on the chassis. He then powered the chassis back on and plugged the ESD cable back in. This seemed to fix the ESD, until it tripped just a little while ago.

Reinstalled PCAL AA Chassis at EX. Unit had three channels that needed repair (S1400574).

This morning, after the IFO was locked, DARM was super noisy in kHz region. ISS error point was also super noisy and the coherence between the two was big.

Turns out that the ISS got noisy at the tail end of the lock stretch from last night, at around 2015-08-07 12:00:00 UTC. That's 5AM in the morning.

We went to the floor and sure enough a function generator was connected to ISS injection point via SR560. We switched them off, disconnected the cable from the ISS front panel, but left the equipment on the floor so the injection can be restarted later.

J. Kissel, as a once-removed observer to the people doing the real work: J. Driggers, S. Dwyer, S. Ballmer, S. Karki, E. Hall, M. Evans, H. Yu, etc.

For record, this mode that Stefan is just beginning to have victory over (see LHO aLOG 20307) has been giving us problems since this past Saturday. My strong suspicion is that this mode was rung up during the ISC_LOCK :: DOWN sanfu (LHO aLOG 20134), in which the ISC system was blasting non-sense into the suspensions for many hours after it failed to recognize that the IFO was down (and it was a Saturday, so it was only by chance that Jamie happened to come on site). Further, I think that it was exacerbated / rung up further because turning OFF one of the failed techniques to damp the mode had not been included in the ISC_LOCK DOWN state, and not discovered for a few days (see LHO aLOG 20272). 

Also, the newly doctored Dan Hoak has been on site for a few days, the current worlds expert on violin mode damping in the H1 aLIGO IFO. As soon as he heard we were violin mode damping, he said "Oh, is it the 508.289 mode? Yeah, I tried to damp that, and never could. Good luck!" So this particular ETMY mode has never been controllable.

We have *just* re-acquired since 4 hours ago, and the violin mode has been damped to the best reference levels. 
Fabulous work ladies and gents.

Note to self: let's not ring up this mode ever again!

The resolution / timescale of my statement about the causes is informed by scanning this past week's summary pages, and informed by control room / commissioning meeting conversations over the past week that don't make it into the log:
Saturday 08/01: [[Initial Ring Up]]

Sunday 08/02: [[Failed Violin Mode Damping Rails]]

Monday 08/03:

Tuesday 08/04:

Wednesday 08/05: [[Failed Violin Mode Damping Railing turned OFF]]

Thursday: 08/06

The h1broadcast0 daqd process was restarted to add channels to the frame sent to the DMT GDS system.  The following channels were added:

H1:CAL-CS_TDEP_ESD_LINE1_REF_A_IMAG
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_REAL
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_IMAG
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_IMAG
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_REAL
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_REAL
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_IMAG
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_REAL
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_REAL
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_REAL
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_REAL
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_REAL
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_REAL
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_IMAG
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_REAL
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_IMAG
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_REAL
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_IMAG
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_IMAG
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_REAL
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_REAL
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_IMAG
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_REAL
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_IMAG
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_REAL
H1:CAL-DELTAL_RESIDUAL_DQ
H1:CAL-DELTAL_CTRL_DQ

Work Permit meeting is part of today's meeting due to not having it on Wednesday

• SEI - nothing
• SUS-nothing
• CDS- re-install P-Cal AA chassis at EX; Re-Install cosmic ray chassis in corner
• VAC- will be making a couple of trips to Y2-8 to drop off equipment
• FAC- Building diffusers for AC vents
• COMM- business as usual

Evan Stefan, Sudarshan
Previous alogs 20298, 17610, 19720

- With the configuration from alog 20298 
  - MODE5: FM1, FM2, FM4, G=-100
  - MODE8: FM1, FM4, FM5, G==500
  we noticed that the 508.2896Hz rang down but then settled at a fixed and still large value of about 9e-15mRMS (2e-14m RMS/rtHz with BW=0.187Hz)
- This had two causes:
  - The MODE5 filters (broadband feed-back for all ETMY modes) were interfering. Thus we designed a notch for the 508.2896Hz mode in MODE5.
    This made the phase slightly worse for the 508.22Hz mode - but it still damps.
  - While MODE8 it driving pitch, it has has some coupling to length, leading to some gain peaking at the violin mode frequency.
    This effect limits the gain we can have.

Next we fine-tweaked the damping phase with the following trick:
 - Right after turning on the MODE8 damping we see the immediate effect of the pitch to length coupling change the violin mode height.
 - by fine-tweaking the phase, we can find the phases for which this immediate effect results in...
   - ... the biggest step-down (violin mode and direct drive are exactly out of phase), and ...
   - ... the biggest step-up (violin mode and direct drive are exactly in phase)
 - We then added roughly 90deg to the step-down version of the filter, such that there is no immediate step when tuning on the damping.
   This implies that the direct drive is lagging about 90deg behind the violin mode, which is what we want for damping.
 - The setting in this configuration was (see snapshot)
  - MODE5: FM1, FM2, FM4, FM5, G=-100
  - MODE8: FM1, FM3, FM4, FM5, G==800
 - In this configuration we saw a slope in the 508.2896Hz mode of about 1 decade reduction per 3.5h. (slow, but consistent!)
 - We tried increasing the gain, but ran into a growing beat with about 2min duration. I am guessing that this is related to the P2L coupling induced gain peaking.
 - After about 3h of this, we were again able to turn on the OMC DCPD whitening.
 - MODE8 is now turned on in the guardian.
   
  

Sheila, Gabriele, Nutsinee

Today I asked the operators to log when they do intial alingment and say what prompted them to do it, so I will start doing the same.

Tonight we had a trip of the ITMX ISI, stage 1 on the L4Cs, which was probably triggered by a PEM injection (which was unfortunately coincident with the arrival of a small earthquake).  After this, it seemed as though the alignment of the ITM might have changed. We had two locklosses durring CARM offset reduction, and DRMI alingment was bad.  After and earthquake, an ISI trip, and several locklosses, we decided to do inital alingment. 

After this we had one sucessfull lock, which I broke attempting to disengage CHARD so that we could phase refl WFS.  Then one and a half more earthquakes made us decide to call it a night without learning anything more about the violin mode. 

Note: We did add logic to the ISC_LOCK DOWN state that switches off ALL the violin mode damping, and added logic to the DRMI gaurdian (in engage DRMI ASC) that will prevent it from doing anything other than check for locklosses if SRM is misaligned. 

Also, earlier in the afternoon we had a lockloss that appeared to be because of coil driver switching. The lockloss seems to be coincident with BS M2 LL coil driver state changing.