Stefan will be conducting OMC measurements during this meeting.

TITLE: 09/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 3mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

H1 dropped out at about 3:30amPST hovering just under 80Mpc.

AS AIR video looked obviously misaligned.  Just opted to start an Initial Alignment.
 

Kiwamu, Stefan

We drove the IM4 in PIT and YAW, and measured the beam jitter to OMC_DCPD_RIN transfer function. We calibrated the drive signal in Relateve Beam Jitter (RBJ), so we can directly compare it with measured beam jitters at other places (for calibration, see below).

We found a transfer function from IM4 RBJ to DCPD_RIN of about 2e-2 RIN/RBJ for yaw, and 3e-3 RIN/RBJ for pitch. When then tried to minimize the couipling by putting offests into the INP1 ASC loop that controls IM4.
For YAW, we found a minimum (with sign change) for -1300cts OFFSET, resulting in about the same transfer function as for the undisturbed PIT.
For PIT, the improvement was minimal, and we didn't find a minimum. But the best coupling was achieved at +1800cts PIT OFFSET.

With those offsets the recycling gain dropped a bit, but there still was a net range improvement.

Calibration:
========

DCPD_SUM: The channel is in mA. The attached txt file includes the closed loop correction, as well as the factor 1/20mA, casting the channel into RIN.

H1:SUS-IM4_M1_OPTICALIGN_P_OUT: The channel should be calibrated in urad at DC, and the PIT pendulum frequency is 1Hz. Also H1:SUS-IM4_M1_OPTICALIGN_P_GAIN is 0.212. Thus, the calibration in rad is 1e-6/0.212 = 4.72e-6 rad/ct + 2 poles at 1Hz

H1:SUS-IM4_M1_OPTICALIGN_Y_OUT: The channel should be calibrated in urad at DC, and the YAW pendulum frequency is 0.727Hz. Also H1:SUS-IM4_M1_OPTICALIGN_Y_GAIN is 0.388. Thus, the calibration in rad is 1e-6/0.388 = 2.58e-6 rad/ct + 2 poles at 0.727Hz

Calibration in Relative Beam Jitter (RBJ):

The field overlap between two Gaussian beams with k=2*pi/lambda, w the beam spot size, and Theta the angle between the beams is
  ovl =exp(-(k*w*Theta/2)^2/2 )
Thus, the mode-mismatch M=1-|ovl|^2 = (k*w*Theta/2)^2 = (Theta/Theta_w)^2
where Theta_w =lambda/(pi*w).

From T1200470 and the attached wCalc.m file, we find the beam spot on IM4 to be 2.12mm. Thus Theta_w for IM4 is 160urad.

Finally, there is a factor of two between the beam deflection angle Thata and the mirror angle Phi: Theta=2*Phi.
Thus, we have to divide the calibration for H1:SUS-IM4_M1_OPTICALIGN_P_OUT and H1:SUS-IM4_M1_OPTICALIGN_Y_OUT by 80urad to ger relative beam jitter (RBJ):

H1:SUS-IM4_M1_OPTICALIGN_P_OUT: 0.0590 RBJ/ct
H1:SUS-IM4_M1_OPTICALIGN_Y_OUT: 0.0323 RBJ/ct

Jason (on phone), Jim, Sheila, Stefan, Terra, Kiwamu,

The PSL tripped twice tonight, one at around 2:06 UTC and the other at 3:36 UTC. For the first trip, Jason remotely walked us through the recover procedure of the PSL on the phone. For the second time, we could not get Jason on the phone, but since the fault status was exactly the same, we repeated the same recover procedure by ourself. For both times, the laser came back up without issues. The attached shows the PSL staus screen before we cleared the errors for the first time. In each time, we had to add a few 100 ml of water to the chiller to clear the warning. Also, when we went to the chiller for the second time, there was water not only on the floor but also on the door and the chiller itself. It looked as if water was sprayed. Not sure if this is the same as what Sheila reported a few days ago (29964).

Title:  09/28/2016, Evening Shift 23:00 – 07:00 All times in UTC 
State of H1: NLN, Kiwamu and Stefan plan to leave in undisturbed
Commissioning: 

02:00 PSL trip, Jason was called, he helped Kiwamu and Sheila recover

04:30 second PSL trip, Kiwamu and Stefan recovered

ey_mode[9].only_on('INPUT', 'FM10', 'FM4',  'OUTPUT', 'DECIMATION')

ey_mode[9].GAIN.put(0.001)

Channel to monitor: H1:SUS-ETMY_L2_DAMP_MODE9_OUTPUT

rms channel: H1:SUS-ETMY_L2_DAMP_MODE10_RMSLP_LOG10_OUTMON

Sheila, Kiwamu, Robert, Daniel, Stefan

After a lot of discussion about possible ways for jitter noise to end up as intensity noise, still nothing really added up. Nevertheless, here are some related numbers:

Quoting the noise around 300Hz, we have

For beam jitter:

- DBB measurement of the laser amplifier: relative beam jitter (rad/divergence angle): 2-10 e-6/rtHz (alog 28729)
- IM4 relative beam jitter (PIT/SUM, YAW/SUM): 2-5e-8/rtHz (plot 1)

For Intensity noise:

- Excess noise in DCPD-sum 1.5e-7mA/rtHz --> 20mA --> 8e-9/rtHz RIN (plot 2)
- RIN coupling from entering main IFO to DCPD (measured) up to 0.05 RIN/RIN around 300Hz (alog 29644), but varying a lot.
    - thus we need the equivalent of 1e-7/rtHz RIN entering the IFO
- The REFL_A_LF_OUT_DQ, calibrated in RIN, reports a rin of 4e-9/rtHz (plot 3)
- The ISS out of loop PD reports a RIN of 7e-9/rtHz (alog 30026)

The number we were missing is an experimental measurment of the (power) transfer function beam jitter after the IMC (e.g. added through the IMs), directly to DCPD_SUM RIN.

Also, the spectum of plot 2 was taken at a time when almost none of the jitter peaks shoed up in DARM - however there is still a clear broadband hump visible. We seem to be fighting two different phenomena here. Robert also had a plot that shows that this broadband stuff is coherent with the ISS_SECONDLOOP control signal... as I promised, no conclusion.

WP6195

I have modified the reservation system to permit users to supply work-permit numbers (if applicable) as an additional argument and to display these as a new column. Full details in the wiki page

https://lhocds.ligo-wa.caltech.edu/wiki/H1CommissioningReservationSystem

example display screen shown below (with made-up tasks)

Resetting the IMs to their O1 start and O1 end alignments, I have identified the IMC as the biggest contributer to pitch beam position changes at PRM, and IM1-3 as the biggest contributers to yaw beam position changes at PRM.

Summary and detailed charts attached.

Copper seat has long been bottomed out due to over torque and gazillions of cycles etc.  The resulting air leak into the RGA volume when the chamber is vented necessitates frequent baking of the RGA volume.  This then requires that the electronics module be removed and reinstalled.  These repeated re-installations of the electronics module along with the associated "hit or miss" alignment of the feed-through pins and sockets has caused the sockets to recess into their connector etc. etc. etc. Postponing fixing one problem is soon to result in a 2nd, avoidable, problem.  

First couple of hours of today addressed the TCSy Chiller which went down over the night.  After that, went through an Initial Alignment and had a few locks.  Unfortunately, later locking attempts would break lock during ASC guardian states (this was probably related to changes Sheila notes in her alog last night); specifics below.

Day's Activities:

• 16:03-17:00:  Addressing TCSy (Corey, Gerardo, Vern)
• 16:31-17:46:  CP4 Work (Chandra)
• 16:44:  Inventory at MY throughout day.(Mark)
• 16:53 -17:05:  Mechanical Room trip (Richard, Patrick)
• ~17:15:  EQ observed (most likely 5.1 from Mexico), seismic taken up to 0.9um/s.  Did not adjust SEI_CONFIG.
• 17:27:  Initial Alignment run
• 19:55:  Hartman table work (Nutsinee)
• Commissioning work in the afternoon around the DC Readout step is currently underway.

ISC Locking Note:

• First few locks after initial alignment were fine, but h1 started to break lock at various midpoints through Guardian States---namely when ASC would drive the SRM off (noted by Kiwamu).  This is related to work from last night (see Sheila's alog)
• To ride through the roughness, you will need to tweak the SRM (in 1.0 um steps) to prevent (1) POP90 (green on front StripTool) from increasing & (2) AS over POP90 deceasing.
• Also need to wait before COIL_DRIVERS to allow bounce/roll/violins to damp out.  

OPS INFO Notes:

PRM ALIGN:  If AS_AIR is flashing, you are not locked, and this is most likely due to a misaligned PRM.  Take ALIGN_IFO to DOWN, & then tweak PRM while looking at AS_AIR.  Then go back to PRM_ALIGN for the alignment.

Reminder that two weeks ago we swapped out the 16bit DAC card in h1oaf0, but got a dac-zero'ed error on Sunday (9/25). Yesterday (9/27) we swapped the first and third ADCs and are waiting to see if we get another DAC error. On Keith's suggestion we are running a script on h1oaf0 which will report to a log file if the DAC FIFO status is anything other than OK. We suspect that a FIFO full or empty error is precipitating the zeroing of the DAC channels.

The script is called monitor_iop_dac_status.bsh, running in the background on h1oaf0's general core. It appends text to the log file:

/opt/rtcds/lho/h1/target/h1iopoaf0/logs/h1iopoaf0_16bitDAC_fifo_status.txt

It runs every minute, outputting a date stamp and any errors. The DAC FIFO status is gotten from the /proc/h1iopoaf0/status file.

model restarts logged for Tue 27/Sep/2016
2016_09_27 05:57 h1nds0
2016_09_27 09:37 h1psliss
2016_09_27 09:54 h1psliss
2016_09_27 10:02 h1fw0
2016_09_27 10:02 h1fw1
2016_09_27 10:06 h1dc0
2016_09_27 10:08 h1broadcast0
2016_09_27 10:08 h1fw0
2016_09_27 10:08 h1fw1
2016_09_27 10:08 h1nds0
2016_09_27 10:08 h1nds1
2016_09_27 10:08 h1tw1
2016_09_27 10:24 h1alsex
2016_09_27 10:24 h1calex
2016_09_27 10:24 h1iopiscex
2016_09_27 10:24 h1ioplsc0
2016_09_27 10:24 h1iscex
2016_09_27 10:24 h1lscaux
2016_09_27 10:24 h1lsc
2016_09_27 10:24 h1omc
2016_09_27 10:24 h1omcpi
2016_09_27 10:24 h1pemex
2016_09_27 11:18 h1dc0
2016_09_27 11:18 h1iopoaf0
2016_09_27 11:18 h1pemcs
2016_09_27 11:20 h1broadcast0
2016_09_27 11:20 h1calcs
2016_09_27 11:20 h1fw0
2016_09_27 11:20 h1fw1
2016_09_27 11:20 h1fw2
2016_09_27 11:20 h1iopoaf0
2016_09_27 11:20 h1nds0
2016_09_27 11:20 h1nds1
2016_09_27 11:20 h1ngn
2016_09_27 11:20 h1oaf
2016_09_27 11:20 h1odcmaster
2016_09_27 11:20 h1pemcs
2016_09_27 11:20 h1susprocpi
2016_09_27 11:20 h1tcscs
2016_09_27 11:20 h1tw0
2016_09_27 11:20 h1tw1
2016_09_27 11:25 h1broadcast0
2016_09_27 11:25 h1dc0
2016_09_27 11:25 h1fw0
2016_09_27 11:25 h1fw1
2016_09_27 11:25 h1fw2
2016_09_27 11:25 h1nds0
2016_09_27 11:25 h1nds1
2016_09_27 11:25 h1tw0
2016_09_27 11:25 h1tw1
2016_09_27 11:31 h1broadcast0
2016_09_27 11:31 h1dc0
2016_09_27 11:31 h1fw0
2016_09_27 11:31 h1fw1
2016_09_27 11:31 h1fw2
2016_09_27 11:31 h1nds0
2016_09_27 11:31 h1nds1
2016_09_27 11:31 h1tw0
2016_09_27 11:31 h1tw1
2016_09_27 11:32 h1nds1
2016_09_27 12:04 h1tcscs
2016_09_27 12:35 h1tcscs
2016_09_27 13:48 h1iopiscey
2016_09_27 13:48 h1pemey
2016_09_27 13:49 h1iopiscey
2016_09_27 13:49 h1pemey
2016_09_27 13:50 h1alsey
2016_09_27 13:50 h1caley
2016_09_27 13:50 h1iscey
2016_09_27 14:28 h1nds0
2016_09_27 22:50 h1nds0

maintenance day. h1lsc0, h1isce[x,y] powered for dc-supply install. h1oaf0 powered for adc swap. psl-iss model change. tcs restarts to test alarms. multiple daq restarts. several unexpected nds0 restarts.

model restarts logged for Mon 26/Sep/2016 No restarts reported

There was some discussion about the prospects for pushing up the CARM bandwidth to better suppress frequency noise above several kilohertz. Since we currently run with a 20 kHz UGF or so, adding more gain would require a UGF that approaches (or exceeds) the FSR.

The attachment shows the CARM OLTF taken in the viscinity of the FSR, showing the expected dip and (overcoupled) phase feature in the optical plant. The feature does not have infinite Q, so in principle any secondary UGFs could be eliminated, though it would be tricky. The HWHM is 0.6 Hz, consistent with CARM intensity TFs taken previously.

(Corey, Gerardo, Vern, Betsy on phone)

9am - 10am

As noted earlier, TCSy CO2 Laser was down and we had a chiller flow alarm.

Went out to the Mezanine to assess the TCSy Chiller.  Here's what was noted for the chiller:

• Had power (it was NOT tripped OFF).
• LCD window stated:  WARNING!  LOW LEVEL
• The fluid level indicator was completely empty (!)
• We also went out to the TCSy Table area and noticed lots of air bubbles in the clear tubing...it was also noticeably loud.
• Returned to Chiller.

First thing we did was start filling the Chiller (there was a little "DISTILLED LABORATORY WATER" [1st pic], ended up filling remainder with a jug labeled "Premium Distilled Drinking Water" [2nd pic]).  It took about 3L before we saw the float indicator move from EMPTY.  After that it was filling 0.5L at a time and watching.  We took it up to about 6L and had a level near FULL.  As we were chatting for a minute or two, we noticed water pooling at the base of the front of the TCSy Chiller (!) [3rd pic].  

Investigated by removing the resevoir cover assy (this cover allows you to see resevoir filters and also holds the cap for filling it).  We could clearly see RETURN water splashing all over the place due to the Stainles Steel mesh RETURN filter [4th pic].  Water was easily escaping this resevoir by having some water flow out of the resevoir & down the exerior panels of the Chiller and dripping on the floor.  (In contrast to TCSx Chiller [5th pic] which was a pristine and calm waterfall from the RETURN down into the resevoir.)

Removed the mesh filter & reseated it.  It wasn't trivial.  Our first attempt did not look as nice as TCSx.  Vern reseated again but this time flipped the mesh filter, and this time it looked much better [6th pic] (& more importantly, similar to TCSx).  The OUTPUT "coffee filter" looking filter (which has been noted as being partly green) looked like it had an air bubble under it.  We tried pushing it down, but it didn't help.  But overall, we looked better after reseating the mesh filter.  When reinstalling the Resevoir Cover, we saw a tab under it (most likely to keep the mesh filter in place); our guess is the mesh filter might have been dislodged by this tab when the resevoir was reinstalled yesterday); see [7th pic]  

Since we lost some water due to the leak we witnessed, we topped off the Chiller again with another 0.5L (so total of 6.5L was poured, with some splashing out).

After we were done at the Chiller, we went out to the TCSy table area.  We looked inside the enclosure to make sure there wasn't a puddle of water (there wasn't).  We then turned on the laser controller.  (The water tubes were much quieter than before...no visible air bubbles.).

As this lock progressed, the 100 to 200 Hz region was improving and the range hit 80 Mpc right after 8:30 UTC. This is despite some huge noise in the 30 to 50 Hz region that came up at the same time. Around 8:49, the detector lost lock. The first attachment is the range, and the second shows the two parts of the spectrum going in opposite directions.

It's not clear why the lock was lost, although the PI summary page shows something in the 3-8 Hz band growing exponentially (blue trace, third plot). Maybe it's this line at 4735 Hz (fourth plot)? It gets bigger and grows ugly sidebands as time goes on. I don't see it identified on the PI MEDM page though (I looked for 11649 and 28033 Hz as likely aliases).

Edit: Actually, this could be the 10th order EY violin mode; see alog 19608. Is it possible something is going wrong with the damping and it's getting out of control? Or maybe it's nothing to worry about?

This information is based on the cumulative spectrum of recent lock stretches (9/18-9/26, computed from Fscan SFTs with spec_avg_long), plus Fscan magnetometer data.

0.997698 Hz

• Worst comb at present
• Previously noted in ER9
• Higher in DARM 9/24-9/26 than 9/18, 9/23
• Appears in CS mags and is fairly steady there (based on available Fscan data since April).

1.0 Hz

• Present in CS, EX, EY magnetometers

0.5 Hz odd harmonics (AKA 1 Hz with 0.5 Hz offset)

• Looking better! Weaker than ER9 by a factor of ~5-10 (varies across spectrum). Improvement presumably due to timing system LED reprogramming.
• Hoping for more improvements as IO chassis timing slaves are put back on alternate power supplies.

1.0 Hz with 0.998889 offset (new)

• Very close to 1 Hz comb, but distinct peaks are visible

0.987987 Hz (new)

• Present in EX magnetometers
• Increases on 9/11/16 in magnetometers

Attached plots:

• 1: LSC-DARM_OUT_DQ cumulative spectrum with the noted combs highlighted
• 2-4: Representative (SUSRACK) magnetometer channels at CS, EX, EY with combs highlighted
• 5-6: Plots showing 0.5 Hz odd harmonics improvement between ER9 and present