[JimW, JeffK, Jenne]

Several times today we've had to hand-request the OMC guardian to go to ReadyForHandoff, after it fails to find the carrier during the PZT scan.  I'm a little unsure why it sometimes works, and sometimes doesn't, since the scans look quite similar.

In the two attached screenshots, once the OMC scan worked, and once it didn't.  The one that includes "succeed" in the filename starts at a slightly lower DCPD value (below 2mA), whereas the "failed" time the DCPD value starts at around 5mA, so maybe that's the difference in it recognizing that the first peak on the left is one of the 45MHz sidebands?  I'll have to look at the OMC scan code, but if that's not it, then I'm certainly confused.

I have plotted about 18 minutes of data starting at GPS time 1164290368 (2016/11/27, 13:59:11 UTC). The attached pdf file has a time series plot of the kappas and the coherences on the first page, and histograms with averages and standard deviations on the second page. The output of CALCS, SLM, and GDS are included. For kappa_tst and kappa_pu, CALCS and GDS are ~1% different, while SLM values are ~4% larger. Agreement is fairly good for kappa_c and f_c, with the exception that the CALCS value of kappa_c is ~1-2% larger.

Robert, Kiwamu,

This is a summary of the recovery of the IMC alignment after the PSL PZT mirror mount swap today (for which I think Robert will make a separate report).

Synopsis-

IMC seems to have shifted its waist location horizontally by 0.25 mm based on the change seen by the suspension witness sensors. This apparently was large enough to reduce the amount of light at IMC-TRANS by a factor of two presumably due to a worse in-vac clipping in HAM2. Nevertheless, as of now, we seem to be able to lock the interferometer on DC readout without new issues.

Recovery process-

We temporarily placed an iris after the top periscope mirror and before the beam tubing. After the swap, we checked two existing irises that had been on the table and the new one at the top of the periscope to coarsely recover the alignment. Then checking the spot on the PSL wall coming out from the light pipe between the PSL and HAM1, we did a fine alignment. This was good enough to put us back to a position where we see the main light on IMC REFL camera. A final alignment was then done by engaging IMC ASC which automatically servoed the alignment to an optimum. The temporary iris was removed before we left the PSL.

After the successful lock of IMC and successful engagement of IMC ASC, we noticed that the IMC TRANS is smaller by a factor of two. This seems to be due to a slight change in the horizontal direction in the uncontrolled degree of freedom. Here is a table listing several changes in some relevant sensors.

As shown above, the only appreciable change is that in DOF2 of IMC YAW (highlighted by red texts). Using Kawazoe's formula (P1000135), one can find that this amounts to a lateral shift of the spot position by 0.25 mm toward HAM3 or away from PSL. [EDIT] Keita pointed out that the direction of the move that I initially reported was wrong. So the correct statement is that the beam shifted by 0.25 mm toward the PSL or away from HAM3.
 

Things we didn't optimize-

• MC3 spot position (or IM4 spot position) in yaw
  • We are not sure how this is going to change DARM noise.
• IMC WFS centering
  • They are not centered any more as a consequence of today's activity. One can re-center them by picomotors if necessary.

~1555 - 1605 hrs. local -> Kyle in and out of LVEA 

More data - I'm letting the gauge volume pressure accumulate overnight - I noticed that the pirani gauge mounted between the two in-series turbo pumps has changed again and is now showing 1.8 x 10-3 torr.  This a few hours after the most recent decrease in heating power.  Being positioned between these two turbos, i.e. at the inlet of the downstream turbo, this gauge should be "off-scale low" and unchanging regardless of what temperature the, now baked parts, are.  If this pressure change is real (which it isn't) it would have to be due to a newly developed leak (which it isn't).   

The real reason to isolate the pumps from the gauge volume at this stage is two-fold; firstly, the off gassing/gas removal bang for the buck is over now that we would be pumping on it at, or near, room temperature and secondly, by doing so, we now have (2) closed valves between the site vacuum and any failure modes of the temporary pumping setup that could result in a venting of the pump line.

Frontend Watch is GREEN

Attached are the long trends of the ETM charge measurements with this morning's data appended.  Note in the first 2 plots that the ETMy charge looks slighly ramped up as it heads away from zero in all 4 quadrants - if indeed ramping, it could be due to the nice IFO duty cycle we have which drives through the ETMY L3.  For this reason, Jenne wrote into the ISC_LOCK.py Guardian to set the ETMY L3 bias gain in DOWN to be the opposite of what it is in-lock in an attempt to de-charge it when not in low noise use.  She also made sure the there was an appropriate re-setup step for this bias gain where needed in the guardian script.

This is a similar change that Sheila made in alog 31172 to "de-charge" ETMX via flipping the gain sign during unused times - in that case during low noise locking.

Change to the guardian script has been committed to SVN.

TITLE: 11/28 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Jim
SHIFT SUMMARY:  After the lockloss, we have been in DOWN for PSL PZT work, with other tasks happening opportunistically.
LOG:

16:12 Joe D beamtube patching Yarm

17:37 Lockloss, possibly due to coincident PSL Noise Eater OOR

17:58 Kyle to LVEA PT180

18:06 Jason to EX for OpLev work

18:10 Robert and Kiwamu to PSL PZT work

18:15 Joe D done

18:20 Kyle out

18:22 Jeff B forklifing chiller

18:25 Hugh to EX BRS work

18:30 Jason done at EX

18:33 Jason and Betsy to TCSy table to check flow sensor

18:54 Jason to EY OpLev, SEI_CONF to SC_OFF_NOBRSXY

19:08 Jeff B done

19:21 Jason done

20:02 Hugh done, SEI_CONF set to WINDY_NO_BRSX (Hugh said not to use BRSX yet)

22:08 Switched SEI_CONF back to WINDY since Hugh reports that BRSX is back up

22:34 Dave restarting models

23:55 Kyle to LVEA to close valve
 

A mini circuits amplifier was placed on the following RF signals going into the PEM QUAD I&Q Demodulator Chassis:

Cable PEM_CS_Radio_Ebay_45MHZ (AMP1)

Cable  PEM_SPQ_PWR_HAM2-3_2 (AMP2)

Cable  PEM CS_Radio_Ebay_9MHz (AMP3)

Cable  PEM SPQ_PWR_HAM2-3_1 (AMP4)

The cables were re-routed from the demodulator chassis to the network rack (next to the PEM/OAF Rack). Four mini circuits amplifiers ZHL-1A+ were monted on a rack tray. A 5 dB attenuator was installed at the output of each amplifier.

Amplifiers are being powered by a DC power supply.

Special Monday Maintenance:

WP 6350 ALS and LSC model change

Keita, Dave:

Removed 3*2048Hz channels from each of h1alsex, h1alsey and 1*16384Hz lsc channel from DAQ Frame.

WP 6354 SUSPROCPI model change

Terra, Dave:

removed 28*2048Hz channels from DAQ frame.

WP 6353 ECR E1600351 Add GDS channels to DAQ broadcaster

Jess, Dave:

Added 41 channels to the DAQ frame broadcaster.

Additional data size is 2*16kHz and 39*256Hz. channels.

DAQ restart

Dave:

Did one DAQ restart to install the above changes.

Attached files show the DAQ channels removed from frame due to model changes, and the added channels to the broadcaster.

The online h(t) pipeline has been restarted at Hanford at approximately GPS second 116440990. This does not include any filter change, but does include the following changes:

• Upgrade to gstlal-calibration-1.0.9
• Applying kappa_tst, kappa_PU, and kappa_c to online h(t)

The full command line is below.

gstlal_compute_strain

        --data-source=lvshm

        --shared-memory-partition=$LIGOSMPART

        --filters-file=/home1/calibration/svncommon/CalSVN/ER10/GDSFilters/H1GDS_1163857500.npz

        --ifo=H1

        --frame-duration=4

        --frames-per-file=1

        --write-to-shm-partition=$HOFTSMPART

        --compression-scheme=6

        --compression-level=3

        --control-sample-rate=4096

        --expected-fcc=341.0

        --partial-calibration

        --coherence-uncertainty-threshold=0.004

        --kappas-default-to-median

        --apply-kappatst

        --apply-kappapu

        --apply-kappac

Significant exhaust temperature response (<-30C) 47 seconds after changing the manual mode %open value of the LLCV (liquid level control valve) from its as-found valve of 17 to 50 -> restored this value back to 17 following this exercise.

Numerous entries of the last few days mention the BRS X being down.

First notice is LHO aLog 31792 when PEM went to EndX.  A couple hours later Jim mentioned that it was very rung up and he disabled the damping.  On Thursday Jim worked on the BRSX but was unsuccessful at getting it to damp reliably.  On Saturday and Sunday, TJ logged that the BRS was ringing down--it was but just passively.

This morning after reenabling the Damping, it was going nowhere.  The Damping neither helped nor rung it up further so I'm unsure what it was doing.

After IFO dropped lock, remote logged into the BRS computer and looking at the encoder file showed it contained gibberish.  At the End Station, opened up the box and saw the Damper Masses sitting at the 0 position.  I thought I had cleared out the gibberish in the Encoder file but upon restart, the damper just started 360s, this might be what was going on for the past few days.

With Krishna on the phone and some guidance that needs updating, I managed to clear the encoder file and reset the damper encoder angle.  Once this was successfully done, the damper quickly did its job and got things under control.

For the operator--see T1600103 for some troubleshooting.  After today's lesson, this needs some updating, and it contains nothing about the Encoder file problem.  This is on my to-do list.

On Thursday we (Sheila, Daniel & I) increased the Thresholds on the TIDAL RED TRIGGER when the very low value kept the ISC driving the HEPI too long.  It would appear there was only one long lock stretch with these settings before Sheila reported that the tidal was not coming on, in some locks.  Beam diverters?...  When Nutsinee reverted the values of the RED TRIGGER Thresholds, things seemed to start working properly again.  I don't pretend to understand this and it is pretty clear that reverting the values solved the problem.  See attached four days trend, when lowering the THRESH_ON value started the TIDAL running (I did not zoom in but it looks correlated.) But also seen is the REDTRIG_INMON has dropped to 153000 from the previous 165000.  If this level (Power?) change was enough to disable the 8000 count THRESH_ON setting, clearly something else must be in play.  I need to understand the triggering better to really understand this.  We don't want the ISI to trip as it can be several minutes for the T240s to settle and be ready for complete ISI isolation but obviously we need the TIDAL relief to engage.

Travis, Sheila

Tonight we saw more pathological behavoir in the PSL electronics.

Robert wanted to do a test of powering down the DBB, so he switched the power supply that sits on top of the DBB chassis off and unplaggued the DIN connector from the back.  After this, engaging the ISS second loop caused the diffracted power to drop from almost 5% to less than 0.5%, which caused locklosses as we tried to increase power. 

We tried to let the offset adjustment servo (30932) run for a while, but this didn't help. 

We plugged back in the DBB so we could get back to locking, but doing so tripped the PSL external shutter.