Another event at 14:02 PST , proc status file for IOP model posted below.

If this is a timing error (and at this point we are not certain of this), our first change was to replace the fiber optics cable between the IO Chassis timing slave and the timing fanout chassis. A new cable was installed before the system was restarted.

Note, the existing fiber was found to be not cable tied to the bundle of fibers at the timing fan-out card, rather was floating by itself.

Sequence was:

• kill all models in correct sequence
• take h1oaf0 out of the dolphin fabric
• power down h1loaf0 computer
• power down IO Chassis
• replace timing fiber
• power up IO Chassis *
• power up h1oaf0 computer
• wait for irig-b to come back to positive values (approx 3 mins)

* we did not do the TCS-AI power sequence this time and unfortunately this may have tripped the TCS chillers.

controls@h1oaf0 ~ 130$ cat /proc/h1iopoaf0/status
startGpsTime=1162838354
uptime=12257
cpuTimeEverMax=8
cpuTimeEverMaxWhen=1162838680
adcHoldTime=16
adcHoldTimeEverMax=91
adcHoldTimeEverMaxWhen=1162850544
adcHoldTimeMax=17
adcHoldTimeMin=13
adcHoldTimeAvg=14
usrTime=2
usrHoldTime=3
cycle=49476
gps=1162850611
buildDate=Nov 10 2016 08:33:32
cpuTimeMax(cur,past sec)=3,5
cpuTimeMaxCycle(cur,past sec)=21,21
cycleHist: 3=65183@17 4=350@65535 5=3@1
DAC #0 18-bit buf_size=40
DAC #1 16-bit fifo_status=0 (OK)
ADC #0 read time MAX=91 Current=14
ADC #1 read time MAX=0 Current=0
ADC #2 read time MAX=0 Current=0
ADC #3 read time MAX=0 Current=0
ADC #4 read time MAX=0 Current=0
ADC #5 read time MAX=0 Current=0

press DIAG_RESET

controls@h1oaf0 ~ 0$ cat /proc/h1iopoaf0/status
startGpsTime=1162838354
uptime=12333
cpuTimeEverMax=8
cpuTimeEverMaxWhen=1162838680
adcHoldTime=14
adcHoldTimeEverMax=91
adcHoldTimeEverMaxWhen=1162850544
adcHoldTimeMax=17
adcHoldTimeMin=13
adcHoldTimeAvg=14
usrTime=2
usrHoldTime=4
cycle=43808
gps=1162850687
buildDate=Nov 10 2016 08:33:32
cpuTimeMax(cur,past sec)=3,6
cpuTimeMaxCycle(cur,past sec)=21,1
cycleHist: 3=65201@17 4=333@65535 5=1@0 6=1@1
DAC #0 18-bit buf_size=40
DAC #1 16-bit fifo_status=0 (OK)
ADC #0 read time MAX=17 Current=15
ADC #1 read time MAX=0 Current=0
ADC #2 read time MAX=0 Current=0
ADC #3 read time MAX=0 Current=0
ADC #4 read time MAX=0 Current=0
ADC #5 read time MAX=0 Current=0

 

Here's the report of a BruCo scan for last night's lock

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

Some interesting results:

• in the 10-20 Hz region there is coherence with
  • WFS signals (ASC-REFL_A_RF9_I_PIT, fig. 1),
  • ASC signals (ASC-CHARD_P_OUT, fig. 3, ASC-MICH_Y, fig. 5, ASC-CHARD_Y_OUT, fig. 6, some CSOFT too, fig. 7)
  • but more interesting with HPI signals (for example HPI-HAM1_SCSUM_IPS_IN_Z, but others too, fig. 2)
  • and with RM signals (SUS-RM2_M1_OSEMINF_UR_OUT fig. 4)
• at 70 Hz PEM-EX_MAG_EBAY_SUSRACK_Z
• not much between 40 and 120 Hz
• usual jitter peaks above 100 Hz (fig. 8 for an example, lot of coherence with IMC WFS too), coherence well visible in the IMC MCL signals ad ISS signals too

A question for commissioners, should I exclude channels like SUS-ETMY_L2_FASTIMON_* ??

at 10:30 PST the h1iopoaf0 model detected an ADC/DAC error and stopped driving the DAC outputs. Before restarting the models I pressed the DIAG_RESET button to verify the ADC error in the STATE_WORD cleared (it did) and the DAC error was latched on (it was). We also did a quick data dump of h1iopoaf0's proc status file and dmesg.

Here is the /proc/h1iopoaf0/status file before the restart

root@h1oaf0 /proc/h1iopoaf0 0# cat /proc/h1iopoaf0/status
startGpsTime=1162832563
uptime=5511
cpuTimeEverMax=8
cpuTimeEverMaxWhen=1162832990
adcHoldTime=15
adcHoldTimeEverMax=90
adcHoldTimeEverMaxWhen=1162837830
adcHoldTimeMax=17
adcHoldTimeMin=13
adcHoldTimeAvg=14
usrTime=2
usrHoldTime=3
cycle=25821
gps=1162838074
buildDate=Nov 10 2016 08:33:32
cpuTimeMax(cur,past sec)=3,5
cpuTimeMaxCycle(cur,past sec)=21,0
cycleHist: 3=65068@17 4=466@65535 5=2@1
DAC #0 18-bit buf_size=40
DAC #1 16-bit fifo_status=0 (OK)
ADC #0 read time MAX=17 Current=14
ADC #1 read time MAX=0 Current=0
ADC #2 read time MAX=0 Current=0
ADC #3 read time MAX=0 Current=0
ADC #4 read time MAX=0 Current=0
ADC #5 read time MAX=0 Current=0
 

The adcHoldTimeEverMax looks very high (we see it on other systems in the 60-70 range but not this high). The adcHoldTimeEverMaxWhen=1162837830 equates to Nov 10 2016 10:30:13 PST which is the time of the event.

On other systems running with 16bit DACs the FIFO_STATUS is always 2. After h1iopoaf0 was restarted, its status is now 2. Looking at the manual, it suggests

I've setup monitors to report on ADC and FIFO status if this happens again.

This is a continuity of 31381.

For a bookkeeping purpose, I have extended the spot position thing to PRM and MC mirrors. Here is a summary. They all seem fine as expected.

The measurement was done with the interferometer fully locked at 25 W in nominal low noise. The measurement precision should be something like 10% or so.

WP 6287

Removed the ADC card that was added on Tuesday (WP 6287) because of instability of the h1oaf IOP model.  Several instances of ADC/DAC/DK bad status have been noted, the most recent at 06:53 PST this morning.

We will put the ADC card in the DTS for long term testing.

While I had the I/O chassis open, I checked for loose connections or anything else that might cause problems.  I noted that about half the interface cards at the rear of the I/O chassis were loose and able to wiggle back and forth.  I pushed them all down and tightened the screws on the brackets which were loose.  I then looked at the ADC and DAC cards. All the metal brackets were tight, but the last ADC card was not secured to it's metal bracket.  One screw was near falling out, the other was loose (picture attached), so the card was free to wiggle around in it's card connector.  This was tightened and reinstalled.  Not all of the cables plugged in to the back of the I/O chassis are able to be secured to their connectors.  I pushed on all of them to make sure they were seated.  I checked both the fans after power-up, they are both operational.

The h1iopoaf0 model was changed back to it's previous version to reflect the lesser number of ADC cards, and the DAQ was restarted.

The IFO has been in NLN for a while now, but I couldn't take the IFO to OBSERVE because the LASER_PWR guardian had the nominal state set wrong and it took a while to figure out how to change it.

For other operators while we are still in a semi-commissioning phase, I fixed this by editing the LASER_PWR guardian. In the LASER_PWR there is a line that says:

nominal = 'POWER_{}W'.format(REQUEST_POWERS[X])

where X is some negative number. REQUEST_POWER is a vector defined above this line:

REQUEST_POWERS = [DEFAULT_POWER,10,25,35,50]

X is the index of the element that corresponds to the power, counting from the right (i.e for 50 W, X = -1, for 35 W X= -2...).

I had to change:

nominal = 'POWER_{}W'.format(REQUEST_POWERS[-2])   for 35 W to

nominal = 'POWER_{}W'.format(REQUEST_POWERS[-3])   for 25 W.

Save, then hit load on LASER_PWR.

Daniel, Sheila

We have not been using REFL WFS to control PR3 in the last week or so because with somewhat high microseism this was making the IFO unstable.  Things got slightly better when we lowered the IMC WFS gain to avoid oscillating there. 

Tonight we started to look at the REFL centering loops, and re did them.  FIrst we started with diagonalizing them, the new matrix is in the screen shot.  Then we reshaped the loops a bit.  Before these changes the pitch loops were pretty close to unstable at 2.5 Hz with the ELF20s engaged, so we moved up the cut offs and moved the zeros down.  We have had trouble occasionally with CHARD loops ringing at 2.5 Hz, I hope this will be fixed now.

Since the microseism is down to around 0,4um/second, we tried the refl WFS again but lost the lock.  

The 260Hz peak was gone earlier tonight with an offset of 120 in DOF1P

The results of the recent A2L measurements for PR2 and PR3 are analyzed. Here is a summary.

Synopsys

The horizontal spot position on PR2 may sound too large, but I don't think this is bad.

Back in 2014 we adjusted the PR2 spot to be at 14 mm toward the West (14788) in order to improve the clipping situation on PR2 based on the study that Keita did (14640). Since the beam radius on PR2 is about 6 mm (see for example 30130), the spot position seems to have shifted by roughly the radius of the beam size further to the West comparing to the 2014 measurement. Note that the size of the PR2 optic is 150 mm in diameter (D1101377). According to these numbers, I don't think the measured spot position is too crazy.

Some details

Over the past week or so, the operators ran the a2l scripts for PR2 and PR3 (for example 31239). The scripts were the ones Jenne newly wrote specifically for checking the beam spot on these mirrors (31157). The attached shows trend of the a2l gains for the past two weeks. The values are then roughly averaged and used to estimate the typical spot positions as listed above. For the definition of alpha, see Koji's log entry in the 40m elog. For the conversion from alpha to the spot positions, see 14788.

There are some jittery peaks that may be doughnut jitter. How much are we going to gain if we squash them?

As a sensor for jittery things I chose IMC WFSA DC YAW. (Not because we believe that it's an angulay jitter, but because the coherence with DARM is high and therefore whatever polluts DARM is likely coming from the same place as the angular jitter measured by IMC WFSA DC YAW.)

Using DTT, I took 100 averages of CAL_DELTAL_EXTERNAL and IMC WFSA DC YAW from the night before (Nov/08 10:00:00 UTC) when there was this fabulously steady BNS inspiral range. As you can see from the first plot, IMC WFS is coherent with CAL_DELTAL_EXTERNAL.

I used the part where coherence is greater than 0.2 and did a dirty subtraction of the WFS signal from CAL_DELTA_EXTERNAL using a transfer function and the spectra measured. 60Hz and harmonics are excluded from the subtraction. The top panel shows both the raw and the post-subtraction spectrum.

The displacement was then divided by 4000 and was plugged into BNS inspiral range code (BNS_range.m) in calibration svn. Note that the range produced this way disagrees with the sensemon by about 10-% (my number overestimates), but it should still be useful for noise subtraction comparison.

In the second attachment, bottom shows the sqrt of the integrand (i.e. to obtain Mpc, you square the plot, add everything together, then sqrt).

The effect of the subtraction is small but not totally negligible, it seems like we'll gain something like 1.5 Mpc (or 1.3Mpc if you believe that the overestimation of the inspiral range is just a scale difference).

4pm local [Gerardo, Chandra]

Took 3 min. to overfill CP3 by increasing LLCV to 50% open (from 20%). 

The attached plots show a length noise injection into the PMC using TFIN. The first plot is calibrated in Volts for the HV_MON, whereas the second plot is calibrated in displacement. The coupling coefficient at 1 kHz is about 3.5 x 10^-8 between the PZT and DARM length.

The reference traces 0 and 1 are without injection, whereas reference traces 2, 3 and 4 are from before the changes on the PSL table on Tuesday.

A measurement done at the very beginning of the run had about half the coupling—indicating that the coupling depends on thermal lensing.

Sheila reported that Nutsinee switched the SEI_CONFs to BLEND_45mHz_SC_useism last night but looking this morning I see that it did not switch the Blend on ETMY.  I manually switched the (X & Y dof) Blends only; the Sensor Correction did switch to not use the BRS.  Otherwise all switching worked with Sensor Correction for all Test Masses and no BRS in use at the Ends.

J. Kissel, D. Tuyenbayev

Following preliminary results from Darkhan on the individual actuation strength of the UIM and PUM stages for H1SUSETMY (see, thus far LHO aLOG 31275), and the current delightfully long lock stretch with them in place, I'm bringing this study to a close. I've turned off the temporary L1 and L2 calibration lines at 33.7 and 34.7 Hz, respectively. We do not intend on turning on these lines again for the duration of the run.

These lines were turned OFF at Nov 07 2016 21:21:49 UTC.