To see if we have anything to gain with our low ugf loops.

1st plot is the ASD of the HAM 2 & 3 X Y & Z with our 2Hz ugf evident.  The next 6 plots use the HAM2 SENSCOR FIR IN1 as a calibrated ground motion for the TF A channel.  The B channels are the HAM 2 & 3 ISO X Y & Z.

In general, coherence is greatest where it makes sense X to X Y to Y etc.  The greatest level of coherence shows mostly around 5 hz at about 0.5. 

The standout is the HAM3 Y to Y coherence which shows stronger hitting 0.7 and is broader around 4 to 5 hz.  Maybe not that important for IMC motion but still..

The final attachment is a comparison of the LHO vs LLO isolation filter.  Interesting comparison since LLO is not doing any inertial isoation with the L4C.  They are quite different.

We were locked most of the day until ~21:00, out of lock for around an hour, and came back up relatively easily ~22:00.  Another successful PRMI-->DRMI transition trick seemed to help expedite the process. 

Although I failed to note specific times, Kyle and Gerardo were working at Y-2-8 most of the day, and Jodi visited the mid stations for property tagging work.  Neither of these seemed to effect the IFO performance noticably.

Winds have been in the 20-30mph range for the past 4 hours, with a few gusts to ~40mph.

Summary:

A huge range variation from the day before is very likely due to green light. One less thing to worry about.

Chronicle:

In the attached 12-hour trend, t=0 is Aug 20 2015 07:20:43 UTC.

At around t=3.6h, ALSX green transmission started to fluctuate a lot (third plot from the top), and at around the same time the range started dropping (top).

At around t=6.2 something happened, both ALSX and Y unlocked for a short while and then locked to a new lock point (bottom).

After relocked to the new lock point, Y was OK while X was in a bad-but-better state, and the H1 range was similarly bad-but-better.

At around t=9.6, Y arm ALS gave up and lost lock.

Finally, at around t=10.2,  Y arm ALS beam started flashing in the arm and made a huge drop in the H1 range.

We misaligned the PZT for both green beam injection (and later closed shutters) and the H1 was happy.

I will not investige further.

Control room problem:

This is not related to glitches, but NOT being able to get any DMT data in the control room except from DMT viewer and/or NDS2 means that, for example, we cannot use dataviewer for plotting binary inspiral range.

Why?

Ligodv was unusable at least on opsws7 (one of the control room workstations) due to graphics artefacts which is probably Ubuntu problem.

Ligodv on the web (https://ldvw.ligo.caltech.edu/) doesn't have much options for plotting, Travis and I completely failed to make several traces in separate subplots.

Using DMT viewer and dataviewer in separate windows is a pain.

You can go on your own (e.g. matlab like I did here, or python or whatever), but is this really how we are supposed to work in the control room?

On top of that, even though NDS2 works, it takes 2-hours-ish before the binary range data becomes available in NDS2, so if we want a quick analysis of range-noise correlation we need to use DMT viewer and something else in separate windows.

This is a pain.

Switched to true integrator:
FM1: zpk([0.01],[0],0.01,"n")
FM2: zpk([],[0.01],-1,"n")    (was old FM1)
Gain 0.1

Added all of this to Guardian and SDF.

It seems like Detchar must already be aware of this, but we are having huge glitches durring this lock long lock stretch, which show up in auxiallary degrees of freedom.  We were wondering if anyone has checked for things like DAC crossings, or saturations.  

Note, we're on a 20 hour lock stretch! 

And the previous lock was also long at around 18 hrs.

The relock time between these 2 long stretches took ~1 hour.

Nice.

(Now we just need a trendable range channel...)

I have set the Intent Bit to Commissioning for some measurements by Elli.

Sudarshan reports that a PCal line was turned off sometime last night.  He is turning it back on at 17:53.

(Keita writing)

While Betsy was checking SDF status she found that some ASC signals were routed to ASC-DC5 only in YAW while output matrix elements for DC5 are all zero.

It seems to me that somebody used DC5 matrix elements to write down the previous SRC1 sensing matrix when they had to change it, knowing that DC5 is not used at LHO, and forgot to delete the "memo". Sensing matrix doesn't look like a good place to store this kind of stuff.

Went through the SDF to see if I could make sense of the differences on there.  I did not make anything GREEN (i.e. I did not ACCEPT or REVERT anything because I'm not sure whether we want Operators to do this or Detector Engineers to do that). 

Here are some of my notes of Differences we have by subsystem:

SUSITMY

• H1:SUS-ITMY_L2_DAMP_MODE2:  Stefan violin mode damping (8/20 00:30PST).  Are we happy with this and can we accept?

SUSITMX

• H1:SUS-ITMY_L2_DAMP_MODE1 (8/19 15:24):  violin??  Revert or Accept?
• H1:SUS-ITMY_L2_DAMP_MODE7 (8/19 14:36):  violin??  Revert or Accept?
• H1:SUS-ITMY_L2_DAMP_MODE9_GAIN:  Can't find alog (8/20 16:31PST)

SUSETMX

• H1:SUS-ETMX_L2_DAMP_MODE10:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE7:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE8:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE9:  Nutsinee violin damping (8/20 16:20PST).  Are we happy with this and can we accept?

SUSETMY

• H1:SUS-ETMY_L2_DAMP_MODE10 (8/19 23:29) Stefan violin damping. 
• H1:SUS-ETMY_L2_DAMP_MODE3 (8/19 8:33) Stefan violin damping. 
• H1:SUS-ETMY_L2_DAMP_MODE9 (8/19 13:55) ???

SUSSR3

• H1:SUS-SR3_M2_OLDAMP_P_GAIN (8/19 14:38):  ??
• H1:SUS-SR3_M2_TEST_P_GAIN (8/19 14:36):  ??

LSC

• H1:LSC-MCL_TRAMP (8/20 16:31):  ??  Can we revert?

ASC

• H1: ASC-INMATRIX_P_5_3 (8/20 16:52):  ?
• H1: ASC-INMATRIX_P_5_8 (8/20 16:52):  ?
• H1: ASC-INMATRIX_Y_16_3 (8/19 0:31):  ?
• H1: ASC-INMATRIX_Y_16_7 (8/19 0:31):  ?
• H1:ASC_MICH_P_OFFSET (8/19 22:16):  ?
• H1:ASC_MICH_Y_OFFSET (8/19 21:11):  ?

OMC

• H1:OMC-DCPD_A (8/20 17:16):  ?
• H1:OMC-DCPD_B (8/20 17:15):  ?

CALCS

Lots of channels here.  Seems like many can be ACCEPTED

The ASC control of the SRC hasn't been making sense.  I did some calculations to see if the SRC might head towards an unstable condition if we run the IFO at high power (24W).   We were interested in whether thermal lensing effects in the ITMs could cause a big enough gouy phase shift to cause us troubles.

At 24W there is 120kW of power in the arms and that the surface absorption of the ITMs is 0.5ppb (galaxy).  The HR surface curvature of the ITMs changes by 1.06 udiopter/mW absorbed power (LLO alog 14634).  This means we could expect a change in ITM curvature of 120e3*0.5e-6*1.06e3=65udiopters, or a change in the radius of curvature from 2000m to roughly 1750m as we go from cold state to 24W input power.  I haven't considered substrate absorption, and G060155, slide16, indicates change in index of refraction due to bulk heating is roughly 10% of the surface absorption effect.

Putting this hot state ITM ROC into an aLaMode model of the interferometer (based on Lisa's model T1300960 with Dan's additions, alog 18915), the round trip gouy phase decreases from 32 to 22 degrees.  Calculating the stability parameter for the SRC using the round trip transfer matrix, the cavity goes unstable.  (A stable cavity occurs when -1<1/2*(A+D)<1.  This parameter changes from 0.8 to 1.3.)

These numbers are just estimates,  but the take away message is that as we increase the power, the SRC becomes less stable, and could be pushed into an unstable regime around about now.  Turning on the ITM ring heaters would make the SRC more stable.  (see comment) A ring heater on SR3 would also make the SRC more stable.

An additional note on transverse mode spacing:  The SRC mode spacing is 240kHz in the cold state and 180kHz in the hot state.  The cavity Finesse is 13.5, the free spectral range is 2.67MHz, so the full-width-half-maximum is 200kHz.  So heating of the ITMs also pushes the SRC closer to degeneracy.

This is a follow up analysis of Robert's anthropogenic noise injections on August 12th. So far I don't see any convinving evidence that these activities were actually coupled into DARM. There were couple of injections ("human in optics lab" and "jumping in the change room") that seemed to coincide with DARM noise around 20-100Hz but it was unclear whether those injections were actually causing the noise. The noise *blobs* started prior to the injection and the PEM seismic sensor only coincided with one of them. Plus I would expect to see a coupling at much lower frequency if human jumping up and down the change room actually injects noise into DARM.

Note that the first injection time (15:05) is still unconfirmed. The time in the original table was wrong.

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.