Nice night lock, here is the report from BruCo:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1121900417/

An excerpt. As usual, the selection of channels might not be the most representative of the real noise couplings, but should give some good hints.

• Around 10 Hz there is coherence with ITMY_M0_NOISEMON_LF_DQ. Is this part of the control signal? Should I remove it from the channel list? (fig. 1)
• SRCL is the winner below 20-30 Hz (fig. 2). In the same region there is coherence with some SR3 signals, in particular M2_OLDAMP. Is this optical lever damping noise? (fig. 3)
• MICH is not far below SRCL, up to 40-50 Hz (fig. 4). PRCL shows some coherence too, but not very high levels.
• There is coherence with some OMC ASC signals (fig. 5)
• It's not very close to the sensitivity, but we also see some coherence with OM1/OM2 signals (fig. 6). The same pattern is visible in ASC_B_PIT and YAW. This is the dominant coherence in the 50-100 Hz region
• At 74-74.5 Hz there is coherence with PEM-EY_MIC_VEA_PLUSY and with a magnetometer at EY
  _VEA_PLUSY
  _DQ
• At 111.5 Hz and 128 Hz there is coherence with PEM-EY_MAG_EBAY_SEIRACK_Z_DQ
• Coherence with IMC angular signals (and ISS signals) has a pattern slightly different from usual: there are few peaks between 100 and 700 Hz (fig. 7). The same coherence pattern is visible with the periscope accelerometer (fig. 8) and POP_A_RF9_I_ERR. This is the dominant coherence in the 100-350 Hz region and around 600-630 Hz
• There is still broadband coherence with AS signals, for example  ASC-AS_A_DC_SUM_OUT_DQ (fig. 9). This seems to be the dominant coherence above 400 Hz.

Jeff, Evan

Here is a DARM OLTF DTT xml with drive levels that are appropriate for use when the EY ESD LVLN LPF on.

Above 500 Hz, it is hard to get coherence. In this region, we have tuned the drive envelope so that the DAC for each ESD quadrant is putting out somewhere between 10 000 ct pk and 50 000 ct pk.

The current integration time (and number of points) as saved in the file is meant for a long, slow, precise measurement, and it will take about 25 minutes to run. For commissionning purposes, it is prudent to reduce the number of points and the integration time.

Came in to find the interferometer has been locked for 5 hours and the ITMY HWS camera, frame grabber, and SLED beam has been on. Since they don't seem to bother anyone I decided to leave them on and run the ITMY HWS code. The number on ITMY HWS medm screen are constantly changing but in the terminal I kept getting "LHD File Not Written". The .mat files are not being updated constantly so I'm not sure how to tell if the code is actually working. The files are in /home/controls/temp/HWSY_July25

ETM HWS cameras were also on. I just turned them off.

Summary

Attached is the dark noise of REFL9Q, along with an estimate of the shot noise and a conversion of these noises into equivalent frequency noise in CARM.

The dark noise appears to be slightly below the shot noise level.

Details

I took the TNC that goes directly into the common-mode board and put it into an SR785. Also attached is the noise with the input of the SR785 terminated.

I also have tried to estimate how this compares to the shot noise on the diode. In full lock at 24 W, we see 3.6 mW of dc light on the PD (according to the calibrated REFL_A_LF channel). Off resonance and at 2.0 W, we have 13.6 mW of dc light. So the CARM visibility is about 98%.

The shot noise ASD (in W/rtHz) and the CARM optical plant (in W/Hz) are both given in Sigg's frequency response document. With a modulation index of 0.22 rad and an incident power of 24 W, the shot noise is 9.4×10⁻¹⁰ W/rtHz, the CARM optical gain is 11 W/Hz, and the CARM pole is 0.36 Hz. [Edit: I was missing some HAM1 attentuation when first calculating the shot noise level. Out of lock, the amount of power on REFL A should be 24 W × 0.1 × 0.5 × 0.5 × 0.5 = 300 mW. That gives a predicted shot noise level of 7.7×10⁻¹¹ W/rtHz, assuming a sideband amplitude reflectivity of 0.44. On the other hand, from the measured in-lock power we can calulate 2(hνP)^1/2 = 5.2×10⁻¹¹ W/rtHz for P = 3.6 mW. This includes the factor of sqrt(2) from the frequency folding but does not include the slight cyclostationary enhancement in the noise from the sidebands (although this latter effect is not enough to explain the discrepancy).] Additionally, I use Kiwamu's measurement of overall REFL9 response (4.7×10⁶ ct/W) in order to get the conversion from optical rf beat note power into demodulated voltage (2900 V/W). These numbers are enough to convert the demodulated dark noise of REFL9Q (and the shot noise) into an equivalent frequency noise. At 1 kHz, the shot noise is about 10 nHz/rtHz; as a phase noise this is 10 prad/rtHz (which is smaller than Stefan's estimate of 80 prad/rtHz). The dark noise, meanwhile, is about 5 nHz/rtHz.

J. Kissel, S. Ballmer

The ESD / DARM calibration lines have been OFF since the CAL-CS front-end model changes this past Thursday (LHO aLOG 19875), because the channel names that generate them have changed. I've used LHO aLOG 19792 to restart them with the newly high SNR.

As Stefan mentions in LHO aLOG 19925, I turned this back on just before the current lock stretch's undisturbed bit was engaged.

For the record, the new channels are
H1:CAL-CS_TDEP_ESD_LINE1_DEMOD_OSC_FREQ       34.7 [Hz] 
H1:CAL-CS_TDEP_ESD_LINE1_DEMOD_OSC_CLKGAIN    0.22 [ct]

H1:CAL-CS_TDEP_ESD_LINE2_DEMOD_OSC_FREQ       538.1 [Hz]
H1:CAL-CS_TDEP_ESD_LINE2_DEMOD_OSC_CLKGAIN    2.4 [ct]
I've overwritten the current EPICs database to the SDF safe.snap, and loaded in the new table to initialize all of the newly named channels. A large fraction of them are now not monitored (417 out of 1188), but I've at least gone through the ESD LINE CLKGAIN and FREQs to make sure they're monitored. I would monitor more, but I don't want to sort on substring (see LHO aLOG 19650).

Stefan, Jeff,

Starting at 22:24:00 UTC (Jul 25 2015) we left the interferometer undisturbed (H1:ODC-OPERATOR_OBSERVATION_READY was set).

For detChar purposes: 
- All cal lines are on. Our (questionable) calibration reports 60Mpc, but hopefully we ca revise that later.
- The winds are hauling with peak gust up to 38mph, but to interferometer seems remarkable indifferent about that.

Now that h1fw0 is stable, we are testing making h1fw1 stable by having it only write commissioning frames and not science frames. This is a temporary fix to support the current commissioning work where reliability is more important than redundency. The frequent restarts of h1fw1 (whose data is served by h1nds1 which is the default NDS) was causing commissioning issues due to data gaps and unavailability. Also note that we have not had any crashes of the framewriter OS or hardware, and so redundency is less of an issue outside of a science run.

After the 12:02 h1fw1 restart today it is now running the new configuration.

The current DAQ configuration is:

frame-writers 

nds-servers

* This is a mistake now that h1fw0 is not writing commissioning frames, needs a restart of h1nds0 to fix which could impact on Guardian nodes, so we are delaying this.

at approx 5pm Friday cdsfs1 (the backup server for cdsfs0 and h1boot) froze up. I was able to power cycle it remotely via IPMI. I'll check that it performs its periodic rsyncs of cdsfs0 and h1boot.

h1fw0 is now stable after the yesterday's configuration change (it is not writing commissioning frames, only science frames). The plot below shows the restarts for h1fw1 (green) and h1fw0 (red) for Friday and today. The blue square marks the time h1fw0 stopped writing commissioning frames. We will run in this configuration over the weekend to get more statistics.

Retook the SRCFF measurement. the data is in /ligo/home/controls/sballmer/20150724/FF
SrclFF20150724.xml & SRC_FFpath20150724.xml  (1st measurement)
SrclFF20150724v2.xml & SRC_FFpath20150724v2.xml (2nd measurement)

An initial fit produced a filter (FF4) that improved the performance at high frequency, but moo0.5 (the old moo, adjusted by a gain of 0.5) was still better at low frequencies. More fitting will be done during daytime. For now, guardian uses moo0.5.

Hannah, Evan, Stefan

The slightly strange sensing matrix from alog 19769 did not seem repeatable today, so we switched ASC_AS_A_RF36_I_YAW back to the settings from alog 19572:
H1:ASC-AS_A_RF36_I_MTRX_2_1    0
H1:ASC-AS_A_RF36_I_MTRX_2_2    0
H1:ASC-AS_A_RF36_I_MTRX_2_3    -2
H1:ASC-AS_A_RF36_I_MTRX_2_4    2

Instead we added some of H1:ASC-AS_B_RF36_I_YAW (with the same sign as in DRMI) to the input matrix. There wasn't much signal there, but the right kind of RF offset. The new sensing matrix is
            asc_intrix_yaw['SRC1', 'AS_B_RF36_I'] = 1.0 
            asc_intrix_yaw['SRC1', 'AS_B_RF36_Q'] = 0.0
            asc_intrix_yaw['SRC1', 'AS_A_RF36_I'] =-3.0 
            asc_intrix_yaw['SRC1', 'AS_A_RF36_Q'] = 0.0
This at least also makes some theoretical sense, so hopefully this will hold up longer.

Stefan, Evan

Summary

We temporarily switched back to the IFR as a sideband generation source, and then used it to drive the sidebands in frequency and amplitude. Then we looked at the coupling in OMC DCPD sum.

Details

We ran the spare LSC DAC channel (LSC-EXTRA_AO_2) into ISC patch cable R1 #11-4, which goes to ISC C4 #2-4. Then we sent this into the IFR's external modulation input.

First, we did the amplitude measurement. The IFR was set to dc-coupled AM with a nominal deviation of 10%. We drove 25 mV out of the DAC and watched the response in the OMC DCPD sum. The observed AM coupling is roughly flat from 300 Hz to 5 kHz, with a level of about 0.01 mA/RIN.

Next, we did the phase measurement. The IFR was set to dc-coupled FM with a nominal deviation of 1 Hz. We drove 100 mV out of the DAC and watched the response in the OMC DCPD sum. The observed FM coupling is roughly flat from from 300 Hz to 5 kHz, with a level of about 2×10⁻⁵ mA/Hz.

[An aside about the IFR actuation calibration: The IFR is designed so that in order to get 10% peak RIN, you must supply 1 V rms at the modulation port, which 1.41 V peak. Stupid stupid stupid. Anyway, I verified with an oscilloscope that the actuation coefficient was 0.068 RIN/V, which is close enough to the expected 0.071 RIN/V.

The same nuttiness applies to the frequency calibration: to get 10 Hz peak deviation, you must supply 1.41 V peak. However, Stefan and I measured this coefficient and found that it is really 3 Hz/V rather than 7.1 Hz/V. Measurement as follows:

• We beat the IFR and the OXCO against each other and looked at the mixed, low-passed output on a scope
• We adjusted the IFR frequency to match the OXCO as best we could.
• We applied 5 V dc from the DAC channel to the external input of the IFR, and measured the beat frequency (it was 14.8 Hz). This gives the acutation coefficient as 3.0 Hz/V.]

Evan, Stefan

We kept having PREP_TR_CARM issues, and again tracked it down to moving dark offsets. now the guardian measures the offsets at the beginning of PREP_TR_CARM.

Let's see weather this finally eliminates those PREP_TR_CARM issues.

Morning Meeting:

- Richard, cosmic ray work continues, not in LVEA

- no SEI

- Apollo, beam tube cleaning ongoing today

- Gerardo, vacuum, High Bay area

- SUS, no work

- PSL, yesterday's work OK, no work today

- Commissioning, intensity noise, frequency noise

- Jim, Frame Writers work continues

I have installed and made RCG2.9.6 the default build environment. I have compiled all th H1 models (102 of them) using 2.9.6, there are no errors in the build. The IPC file was created from new, it is 6 channels smaller than the old file.

This was a make only, it was not installed. I have reverted the original IPC file in case models are restarted this weekend. I'll complete the make/make-install process next Tuesday prior to H1 upgrade to 2.9.6.

The morning around 17:42UTC, PR3 moved but there was no alignment slider or other requested alignment change.

Two plots show this:

Plot 1: 3 channels

• H1:SUS-PR3_M3_WIT_PMON - red
• H1:SUS-PR3_M3_OPLEV_PIT_OUTPUT - green
• H1:SUS-PR3_M1_OPTICALIGN_P_OFFSET - blue

- blue trace, alignment slider, 17:09 to 17:57(end of plot) no change

- red and green traces, pmon and oplev pitch, 17:42 optic takes a step

Plot 2: 9 optic alignment channels, ISI pmon, POPAIR, TEST, and IMC power

• H1:SUS-PR3_M3_OPLEV_PIT_OUTPUT
• H1:SUS-PR3_M3_WIT_PMON
• H1:SUS-PR3_M3_OLDAMP_P_INMON
• H1:SUS-PR3_M3_DITHER_P_INMON - no change
• H:SUS-PR3_M3_LOCK_P_INMON - no change
• H1:SUS-PR3_M2_OLDAMP_P_INMON
• H1:SUS-PR3_M2_DITHER_P_INMON - no change
• H1:SUS-PR3_M2_LOCK_P_INMON - no change
• H1:SUS-PR3_M1_DAMP_P_INMON
• H1:SUS-PR3_M1_OPTICALIGN_P_OFFSET
• H1:SUS-PR3_M1_DITHER_P_INMON - no change
• H1:SUS-PR3_M1_LOCK_P_INMON - no change
• H1:SUS-PR3_M1_ISIWIT_PMON - steady
• H1:LSC-POPAIR_A_LF_OUTPUT
• H1:SUS-PR3_M1_TEST_P_OUTPUT
• H1:IMC-PWR_IN_OUTPUT

- nothing that explains why the optic would move

Here is an update on the ongoing CDS investigations:

DAQ framewriter instability (FRS3379)

started around 14th July. We are testing reducing the disk loading of h1fw0 by only writing science frames (i.e. not also writing the larger commissioning frames). Four hours into this with no frame writer restart.

End Station SUS IOP glitching (FRS3375)

started when the end station sus computers were upgraded to the faster model (14th July). Its impact on ISI has been reduced with the installation of new ISI BSC models this week which do not watchdog trip on individual IPC errors. We will check on the BIOS settings of the SUS computers next Tuesday with LLO (requires LLO end station SUS power down). If there are any differences, LHO will be made the same as LLO. Reverting to the slower computers is an option.

Front End IOC freeze ups (FRS3279)

Not sure when this started as logging was not available, word-of-mouth suggests it became clearly noticable early in July. Monitoring of the problem has been installed. Investigation is continuing, its main impact is on Guardian nodes.

There was a question yesterday about the blends we are running on the the BSC-ISIs. I'm attaching plots of the Quite90/250 and Windy90/250 blends. Pages 1-3 are the 90mhz X/Y blends, 3-6 are the 250 RX/RY blends. The Quite blends are what we are running currently on St1 in XYZ (90) and RX/RY (250), and there is some evidence that we can run them during windy times as well. The Windy blends are kind of untested, and don't currently run on the end station ISIs, I don't know why and I haven't had much of a chance to look into it. The end ISIs will switch to the Windy blends, but trip after a few seconds. Pages 3 and 6 at least show that the filters as installed on ETMY are properly complementary, ETMX is the same.