Terra, Travis, Kiwamu,

Here are some unexpected issues that we addressed tonight.

• AS36 -> SRM
  • As mentioned earlier (30295), we had stability issue with the AS36 -> SRM loop in the DRMI state with the arms held off resonance.
  • One immediate human error we found was an integrator not engaged in DC3 pitch loop.
  • However, engaging the integrator in DC3P did not improve the behavir of the loop running away.
  • In the end, we changed the input matrix. AS36BI: +2 --> +1.
  • This solved the issue. Not sure why we had to change the input matrix.
• AS WFS DC and fast shutter
  • At one point, we ran into a situation where ISC_LOCK did not proceed because the shutter guardian reported a failure in a shutter test.
  • This was found to be a failure report from the dark test in which the light level on AS WFSs A and B were checked with the shutter closed.
  • In the end, we found that the AS WFS DC signals now had a slower low pass filter (a 2nd order butterworth at 1 Hz in FM1), which was too slow to give a low enough light level. This used to be a 2nd order butterworth at 5 Hz yesterday.
  • We re-installed the 5 Hz BLP in FM2 and edited the FAST_SHUTTER and ISC_LOCK guardians so that it uses FM2 when in test.
  • It worked once.
• AS90 jumped multiple times
  • We witnessed a funny behavior of AS90 a few times tonight.
  • It suddenly changes its level by a few % or so when DRMI was in lock with the arms helf off resonance.
  • Times to look at are around 2:13:19 UTC and 3:30:00 UTC.
  • DRMI did not lose lock.

TITLE: 10/07 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: None
SHIFT SUMMARY:  Started shift with an initial alignment.  After IA, spent the entire shift working with Jenne and Kiwamu diagnosing issues with ASC loops and fast shutter.  Only made it past DRMI a few times.
LOG:

5:30 Filled TCSY chiller

6:00 Shift end due to early start for 3IFO meeting
 

Kiwamu, Matt E, Terra

We broke our overnight lock this morning from Mode2 (ITMX 15520.7 Hz) ringing up; usually this is easily damped back down with a slight phase change but there was no operator in the chair at the time. This mode has been especially prone to ring up with very minor (a few degrees) phase drifts as the frequency drifts over ~3 hours lock across a static bandpass. 

I measured this mode's open loop transfer function last night (with the same settings it later rang up with). Width of loop is 24 mHz; cursors at UGFs shown on transfer function plots. Measured Q of mode is ~20 M, giving a half-width of 0.776 so the gain on resonance of our loop is about 31. Phase differential across this fairly wide frequency range is ~160 deg, so we're close to instability. 

To this end, I've halved the gain of the damping drive. I also shifted the bandpass filter: previously the resonant frequency range was sitting slightly off center picking up ~30 deg and now it shifts around within ~2 deg phase window (for a five hour lock at least). We had trouble locking tonight and are now working at low power, so I'll have to remeasure another time. 

Joe B, Darkhan T,

From the past day's lock stretches it seems that now the DARM time-dependent parameters (kappas) calculated in the CAL-CS model are mostly within expected ranges. The optical gain seems 10% lower compared to what the DARM model suggests.

Related alogs (kappas from September): 30219, 29992.

Cal. line coherence averaging:

Coherence calculations in the CAL-CS front-end model outputs overestimated coherences for the calibration lines between Sept. 20 and now. The issue will be fixed by replacing the averaging C code, BUFFER_AND_AVERAGE.c with a previous version (modification to the script proposed in LHO alog 29744 will be reverted).

The first figure shows the results of 2.5 cycles of crystal chiller total flow variation (24.2 l/m vs. 22.2 l/m) in DARM and in the 1QX signal of the DBB quad diodes. The diode signal shows a detectable increase with flow from about 60 to about 6000 Hz, with the biggest increase in the 1000 Hz region. DARM increased from about 200 to 2000 Hz, with the biggest increase around 450 Hz.

The second plot shows other DBB diode signals.  The peaks do not change as much as the rest of the jitter spectrum (see 1000 Hz). The lower percentage changes at some of the peaks are more consistent with the changes in table accelerometer signals. The water signal is apparently a less dominant driver of the peaks than of the smooth regions, and the source of the peaks may therefore be easier to access and damp should need be. 

Robert, Jason

Jonathan, Jim, Dan, Dave

Jim W reported data errors from 06:14PDT this morning in the full frame. We found that the commissioning frame file for this time is correct on the LDAS QFS file system, but corrupt when NFS exported by the h1ldasgw2 NFS server machine to the nds machines. This is a relatively new solaris server installed this summer to take read-only exports away from h1ldasgw0 when h1fw0 was unstable.

I've opened an FRS for this #6370

Investigation is continuing, including a full characterization of the problem.

Dave, Nutsinee

There are still some issues (several white channels on the medm screen, unclear where the files are being written) but so far the new code runs on Ubuntu 14 at both end stations without complains.

This is a low level sanity check and a part of the recent delay study (e.g. 29259). I have measured a transfer function between DARM2_OUT and SUS-ETMY_L3_ISCINF_IN1 using dtt while the interferometer was locked last night. The measurement agrees with 1 cycle user model delay (=61 usec). See the attached.

WP6220 Inclusion of DBB channels to DAQ to monitor jitter of HPO

Daniel, Dave:

a new h1psldbb model was installed and the DAQ was restarted this afternoon (14:50 PDT). Daniel decided that this version initially write its fast channels to the commissioning frame only while the ECR for science frame inclusion was being processed. Daniel's ECR (E1600301, FRS6386) has been approved and these channels will go into the science frame on the next DAQ restart.

Krishna had noted in a log in the secret SEI logbook that the endstation BSC tilt subtracted sensor correction wasn't performing as well as the corner station sensor correction. This seems to have been due to a high pass added to the tilt subtracted seismometer path. This filter is supposed to help suppress signal from the BRS 8mhz resonance, but it seems to have been distorting the phase of the STS signal too much at 100mhz. The first attached plot is of an older (I think) high pass in red and the "problematic" high pass in blue. I've switched ETMX to the "old" high pass, second plot are the ground STS to St1 T240 tf for each endstation. Red trace is EX, blue is EY. It's subtle, but EX is doing better in the 100-200mhz band, if you squint. I'm going to leave the endstations in this configuration overnight, while people in the seismic group can come up with reasons why this is a bad idea.

Jenne, Evan

We looked again at RFAM on the 9 MHz REFL readout.

The attachment shows REFL9I (and REFL LF) for four different PD powers. Additionally, at the fourth power we locked the ISS outer loop (dc coupled with boosts) just to check that the RFAM does not change. The REFL centering loops were on the whole time.

At no power were we able to see anything that looked shot-noise limited, so we were not able to independently check the transimpedance and demod gain for REFL9I. However, the limit placed by the high-frequency noise already seems to indicate that we are missing some gain in the signal chain. Thus far I have been using 2900 V/W for the PD transimpedance plus demod TF, but this would produce spectra that are below the expected shot noise level.

I double-checked the schematics for the REFL LF path and found that the current digital calbration from counts back into watts seems OK. The PD powers given in the attachment are based on this LF calibration.

Finally, note that the dark noise at several kilohertz is larger than the noise when the PD has power on it. No clue about why.

FAMIS#6491

No water was added to the crystal chiller, the water level was at the Max line. The diode chiller did not have a low water level alarm, so I also did not add any water.

Following up on entry 30273, I computed the coherence and transfer function between ISS_PDA_REL_OUT (which should be calibrated in RIN units) and CAL-DELTAL_EXTERNAL (including the proper calibration). Coherence is good enough to estimate a transfer function over all the frequencies above 10 Hz. I'm not injecting any additional noise, just using the signals as they are, so the fact that we have coherence doesn't necessarily mean that we really have a coupling of intensity noise to DARM.

However, the transfer function has a very interesting shape (see figure). It's behaving like 1/f^3 up to ~80 Hz, and above that frequency it increases like f. The region below 80 Hz might very well be consistent with radiation pressure coupling of intensaity noise. We'll have to run some numbers to be sure that this makes sense. I have no clear explanation of the increase above 80 Hz.

Addition:

A quick and dirty estimate of the expected coupling of RIN at the ISS PDs to DARM due to radiation pressure

x = 2 deltaP / c / (m * (2*pi*fr)^2) / (fr / fr_pole_doublecav) = 2 P_arm / c / (m * (2*pi*fr)^2) / (fr / fr_pole_doublecav)  * RIN

At 30 Hz the coupling should be about 2e-11 (maybe off by a factor of 2 or so due to the two arms, etc..). This is many orders of magnitude LARGER than what measured in the TF discussed above. So it is unlikely that PDA/PDB see real intensity noise that goes into the IFO.

I ran a BruCo scan for the last night lock, using ten minutes of data when the range was at ~65 MPc. Results are available here:

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

Summary

There is a lot of coherence a bit everywhere:

• at low frequency (<100 Hz) the auxiliary longitudinal d.o.f.s win: MICH, SRCL, PRCL, see figures 1,2 and 3
• below 50 Hz the most significant angular control signal is ASC-AS_B_RF45_Q_YAW (fig. 4)

The "jitter noise" above 100 Hz shows a lot of coherence with many signals, of different origins. Most of the IMC WFS signals are coherent, for example: IMC-WFS_A/B_DC_PIT/YAW_OUT (fig. 5 and 6).

The most interesting coherence is however with the intensity stabilization: PSL-ISS_PDA_REL_OUT and PSL-ISS_PDB_REL_OUT shows quite large coherence, as well as the ISS control signal: PSL-ISS_AOM_DRIVER_MON_OUT. It seems that PDA and PDB (first loop ISS) are completely dominated by what the ISS second loop is doing (as shown by the control signal). The coherence with DARM in the 100-1000 Hz region is very close to one. See fig. 7 and 8.

Note that in the same 100-1000 Hz region, the coherence with PSL lab accelerometers is also significant, but mostly on the peaks (fig. 9)

En passant, a narrow feature at 56.75 Hz and 113.50 Hz are coherent with EX magnetometers (PEM-EX_MAG_EBAY_SEIRACK_X/Y PEM-EX_MAG_VEA_FLOOR_Y/Z)

Multicoherence

I selected the channels with the largest coherence from the BruCo report, and run a multicoherence code.

chnames = {'H1:LSC-MICH_OUT_DQ', 'H1:LSC-SRCL_OUT_DQ', 'H1:LSC-PRCL_OUT_DQ', ...
            'H1:ASC-AS_B_RF45_Q_YAW_OUT_DQ', 'H1:ASC-OMC_B_YAW_OUT_DQ', 'H1:ASC-OMC_B_PIT_OUT_DQ', ...
            'H1:LSC-REFL_A_RF45_I_ERR_DQ', 'H1:LSC-REFL_A_RF9_Q_ERR_DQ', 'H1:IMC-WFS_A_DC_PIT_OUT_DQ', ...
            'H1:IMC-WFS_B_DC_PIT_OUT_DQ', 'H1:IMC-WFS_A_I_YAW_OUT_DQ', 'H1:IMC-WFS_A_Q_YAW_OUT_DQ', ...
            'H1:PSL-ISS_AOM_DRIVER_MON_OUT_DQ', 'H1:PSL-ISS_PDA_REL_OUT_DQ', 'H1:PSL-ISS_PDB_REL_OUT_DQ', ...
            'H1:PSL-ISS_SECONDLOOP_RIN_INNER_OUT_DQ', 'H1:PSL-ISS_SECONDLOOP_RIN_OUTER_OUT_DQ', ...
            'H1:PSL-PMC_HV_MON_OUT_DQ', 'H1:IMC-IM4_TRANS_SUM_OUT_DQ', ...
            'H1:PEM-CS_ACC_PSL_TABLE1_X_DQ', 'H1:PEM-CS_ACC_PSL_TABLE1_Y_DQ', 'H1:PEM-CS_ACC_PSL_TABLE1_Z_DQ', ...
            'H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ'};

The code take into account the cross-coherences between channels and produce the total coherence and an estimate of the noise projection, base on that coherence. The last figure (10) shows this coherence and the projection into the DCPD signal. A lot of noise can be explained by the coherences.

So, apparently Peter went into the PSL this morning and adjusted the HWP to give us more power incident on the rotation stage.  However, this was not communicated to commissioners / people in the control room, so the ISC_LOCK guardian was still requesting 60W.  With the hardware change, this was actually giving us ~60W into the vacuum.  Something in the ASC didn't like this, and we lost 2 locks after ~1 hour each, with something drifting away. 

EDIT:  I guess some commissioners did know that we were getting 60W and decided to try running with it, we just didn't think it would have such a deleterious effect on the ASC.

The only oplev which is furthest off (approaching -10urad) is the HAM2 oplev (pit & yaw).  This closes out FAMIS#4696.

• The sleds were swapped back and re-swapped to do the same test as alog29956 (I forgot to swap the launchers then). The result was we had no reflection back from ITMY and ITMX had both 790 and 840 nm reflections. So we didn't learn much from this test. The sleds are now swapped back (790nm on X, 840nm on Y)
• The code has been restarted. No new reference has been taken yet. Waiting for a cool IFO.
• The 840nm sled S/N 07.14.264 is dead. I replaced it with 07.14.265.
• The current sled power calibration is again slightly off from alog25806. I don't see a more recent alog of it being re-calibrated so I'm putting the values back to where it was. I tried to measure the power but I had a hard time zeroing my meter so I don't trust my measurement so much (I measured HWSX sled to be outputting 3mW, HWSY sled 5mW). I accepted the changes in the SDF.

Summary:
Repeating the Pcal timing signals measurements made at LHO (aLOG 28942) and LLO (aLOG 27207) with more test point channels in the 65k IOP model, we now have a more complete picture of the Pcal timing signals and where there are time delays.

Bottom line: 61 usec delay from user model (16 kHz) to IOP model (65 kHz); no delay from IOP model to user model; 7.5 usec zero-order-hold delay in the DAC; and 61 usec delay in the DAC or the ADC or a combination of the two. Unfortunately, we cannot determine from these measurements on which of the ADC or DAC has the delay.

Details:
I turned off the nominal high frequency Pcal x-arm excitation and the CW injections for the duration of this measurement. I injected a 960 Hz sine wave, 5000 counts amplitude in H1:CAL-PCALX_SWEPT_SINE_EXC. Then I made transfer function measurements from H1:IOP-ISC_EX_ADC_DT_OUT to H1:CAL-PCALX_DAC_FILT_DTONE_IN1, H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1, and H1:CAL-PCALX_SWEPT_SINE_OUT to H1:CAL-PCALX_TX_PD_VOLTS_IN1, as well as points in between (see attached diagram, and plots)

The measurements match the expectation, except there is one confusing point: the transfer function H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1 does not see the 7.5 usec zero-order-hold DAC delay. Why?

There is a 61 usec delay from just after the digital AI and just before the digital AA (after accounting for the known phase loss by the DAC zero-order-hold, and the analog AI and AA filters). From these measurements, we cannot determine if the delay is in the ADC or DAC or a combination of both. For now, we have timing documentation such as LIGO-G-1501195 to suggest that there are 3 IOP clock cycles delay in the DAC and 1 IOP clock cycle delay at the ADC.

It is important to note that there is no delay in the channels measured in the user model acquired by the ADC. In addition, the measurements show that there is a 61 usec delay when going from the user model to the IOP model.

All this being said, I'm still a little confused from various other timing measurements. See, for example, LLO aLOG 22227 and LHO aLOG 22117. I'll need a little time to digest this and try to reconcile the different results.