Kyle, Gerardo 

0935 hrs. local -> Valved-in RGA to X-end with N2 cal-gas on 

0955 hrs. local -> Valved-out N2 cal-gas 

1005 hrs. local -> Valved-out NEG from X-end 

1015 hrs. local -> began NEG regeneration (heating)

~1145 hrs. local -> NEG regeneration (heating) ends -> Begin NEG cool down 

1240 hrs local -> Valved-in NEG to X-end 

Data attached (see also LIGO-T1500408)

Leaving RGA valved-in to X-end, N2 cal-gas valved-out and filament off

Pcal Team,

During maintenace and calibration yesterday we found that the PCAL AA Chassis (S1400574) at EndX has problems with channel 5-7. Chanenl 5 is dead and 6 and 7 are railed at ~15000 cts. These channels are connected to DB9-to-BNC chassis (D1400423) at the other end. We isolated this unit from AA chassis to troubleshoot the location of the problem and confirmed that it is the AA chassis. 

There has been some speculation that the huge glitches in DARM on weekends and in the middle of the night might be beam tube particulate falling through the beam. The absence of correlated events in auxiliary channels (Link) and the lack of saturations, have not helped dissipate this speculation.

I think that we can test the, in my mind unlikely, hypothesis that these huge glitches are particulate glitches by comparing rate variations to what we would expect. If the glitches are produced by a constant ambient rate of particles falling through the beam, then we would not expect large gaps like the one at the beginning of the Aug. 1 run that Gabriele analyzed for the above linked log (see attached inspiral range plot). This is a fairly weak test when applied to this one day: I calculate that the distribution of glitches on Aug. 1 is only 20% likely to be consistent with a constant rate. But perhaps DetChar could strengthen this argument by looking at future variations in rates to test the hypothesis that the rate is constant. I checked that there was no cleaning or wind above 10 MPH for the Aug. 1 period.

If bangs during cleaning on July 30^th had freed up some particulate that then fell over the next few days, and this dominated the glitch rate, than the expected rate would not be constant but exponentially declining starting at the last cleaning. Since the gap was at the beginning of the Aug. 1 run, this would be even more unlikely than 20%. Bubba keeps a record of cleaning so we could also test for exponential declines in rates.

But for starters, maybe DetChar could check for consistency with a constant rate for those glitches that are not associated with saturations, have auxiliary channel signatures similar to known particulate glitches (e.g. Link, and more to come), and happen on days without cleaning (weekends for sure), and with wind under 10 MPH. Since particulate glitches are likely to be an ongoing concern for some, and since glitch rate statistics can be a good discriminant for particulate glitches, I think that it would be worth setting up this infrastructure for rate statistics of unidentified glitches, if it doesn't already exist.

I can't find the posts now, but several months ago, an intermittent issue with ETMX was spotted that was narrowed down to the CPS's, possibly specfically the corner 2 cpses (?). This problem then somehow "fixed" itself and was quiet for months. As of the night of the 4th, it seems to be back, intermittently (first attached image, spectr should be pretty smooth around 1 hz, it's decidedly toothy). Looking at the Detchar pages, it shows up about 8 UTC and disappears sometime later. I took spectra from last night (second image) and everything was normal again.

Still don't know what this is. Anybody turn anything on Monday afternoon at EX that shouldn't be?

Kyle and Gerardo regenerated the NEG pump at X End yesterday. The attached shows 30 days of the BSC chamber pressure. We gained a factor of two from the regen.

Kyle's alog;  https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20221

alog for the Y End regen is here;   https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19998

RGA data to follow.

• There WILL be a safety meeting today at 3:00PDT in the LSB Auditorium
• Next Tuesday maintenace will be REPAIR ONLY/NO NEW CODE s the CODE FREEZE is in effect as of 8/10/2015!
• SEI - a "Clear Saturations" button has been added to all ISI watchdog screens to be used instead of "clear all". Safe.snap files had been taken in the "Fully_Isolated" state prior to maintenance which caused some trouble in recovery.
• SUS - Nothing
• Controls - Nothing
• CDS - Monitor work in the control room will extend into next week. It is progressing slower than expected and Ken is out until Friday

I adjusted the AOM diffracted power from 9% to ~7%.

[Sheila, Jenne]

We have had a violin mode at ~ 508.29 Hz rung up for the last several days.

Part of the problem was that the ETMY Mode7 filter was railing at its limiter.  This filter bank has the new "flat phase" filter that is being tried, for damping many modes at once.  Evan ramped the gain to zero for this filter bank.  After ~30 minutes we didn't see any noticeable change in the height of the peak.

The only other filter bank that was enabled was the Mode5 bank, with a 506-513 band pass.  We turned off the "-60deg" FM2.  After an hour and a half or so, we see the height of the violin mode has been reduced by almost a factor of 10.  We'll check back on it tomorrow.

Also, there is a new violin mode blrms screen, accessible from the quad overview screen.

J. Kissel, K. Izumi, P. Thomas, B. Weaver, for the whole team.

It was another rough Tuesday. Thanks all for your help and patience.

The biggest issues (time delays in recovery) were (all times PDT):
09:00 - 10:27 (~1.5 hrs) Debugging the Guardian code core before the blanket upgrade LHO aLOG 20210
12:26 - 13:10 (~0.5 hrs) Finding that HEPI foton files all needed a "foton -c" cleansing from bad auto-quacking over the years LHO aLOG 20212
12:50 - 13:25 (~0.5 hrs) Finding that ETMX ESD driver had been railed negative since the night before LHO aLOG 20203
14:15 - 15:40 (~1.5 hrs) End-station Beckhoff finally crashing killing ETMX ESD driver *again* during recovery and it going unnoticed LHO aLOG 20219
16:10 - 16:40 (~0.5 hrs) LSC_CONFIG guardian becomes undead, is killed, which requires a DAQ restart, which fails miserably LHO aLOG 20228
18:05 - 19:15 (~1.5 hrs) PSL rotation stage roulette, which eventually requires restarting the corner station Beckhoff slow-controls chassis LHO aLOG 20235
19:34 - 21:40 (~2.0 hrs) OMC_LOCK guardian has logic in it that needs two channels specific data rate, and those channel's data rate was changed today during the OMC / LSC science frame channel cleanup LHO aLOG 20237

I attach a picture of the full-whiteboard, recovery diary. 

For maybe the first time ever, the H1 IFO top node reported ALL_NODE_OK, and indicated OK==True for the entire H1 IFO:

This is a reflection of  the fact that every node in the system is reporting OK==True, which in turn means that all nodes are operating correctly and their systems are their nominal states.  In other words,

H1 guardian is ready for O1

Of course it dropped out almost immediately as the ISS was turned off for commissioning, but still...

PEM channel renaming

WP5414. Robert, Dave:

h1pemcs was modified to rename the accelerometer channels PR1, SR1, MC to PRM, SRM, IMC. Change was applied to DAQ when it was restarted this morning.

h1isiham3 phantom ini change

Hugh, Dave

After the 07:55 restart of h1isiham3 and a DAQ restart the front end was reporting an ini file mismatch. We are not sure this was a true mismatch since the ini file had not been modified since Monday. We restarted h1isiham3 which cleared the alert.

h1susey computer

WP5413. Carlos, Dave, Jim:

the original h1susey computer was re-installed to remove the IOP glitching. The ETMY model is running longer than when this machine was last in service  (was 51uS, now 55uS). We checked the new SUSETMYPI model runs well with this hardware.

Reboot digital video servers

Dave

The digital video servers h1digivideo[0,1,2] were power cycled as part of the PM reboot project. These machines have been running for 280, 280 and 251 days respectively. We saw no problems with reboots.

Digital video snapshop problem. FRS3410.

Jenne, Dave, Jim, Elli, Kiwamu:

Jenne found that certain digital cameras are producing tiff files which cannot be viewed by most graphics tools. The reboot of the video servers did not fix this. We tried power cycling the ITMX spool camera which also did not help. We tracked this down to the "Frame Type = Mono12" change in the camera configuration. Kiwamu and Elli have methods to read the 32 bit tiff files. This problem is now resovled, FRS3410 will be closed.

EPICS Gateway

Dave

Due to the extended downtime of h1ecatx1, CA clients on the H1FE network did not reconnect to this IOC (EDCU, conlog, Guardian). I restarted the h1slow-h1fe EPICS gateway which prompted the clients to reconnect to h1ecatx1.

DAQ Restarts

Jim, Dave

There were several DAQ restarts. The last restart was quite messy, details in earlier alog.

The FPGA duotone channels were added to the frame broadcaster for DMT timing diagnostics.

Jemie, Kiwamu,

Even though we didn't think that the change we made on the OMC model (alog 20197) would impact on locking, it actually did.

The OMC guardian kept stopping because the code tries to access an oversize index for a data array. After some investigaton, it turned out to be due to the data rate for H1:OMC-PZT1_MON_DC_OUT_DQ whose sampling rate had been changed from 16 kHz to 512 Hz in this morning. Since the OMC guardian tries to access the data with an assumption that the data sampling rate is 16 kHz, some lines in the code lead it to the bad situation. This error happened in FIND_CARRIER in which the code sweeps the OMC length and attemps to find peaks for the 45 MHz sidebands.

Jamie and I did a quick hack -- we decimated another channel, H1:OMC-DCPD_SUM_OUT_DQ, from 16 kHz to also 512 Hz using scipy.signal.deciamate() so that relavant lines are consistent for 512 Hz. We tested it once and it worked.

Patrick, Jeff, Evan

We spent a few minutes cooking the IX compensation plate while trying to make the TCS rotation stage behave.

• To start with, the controller reported the measured angle as 0°. (During the previous TCS tests on Sunday, it was more like 55°.)
• When I asked for a different angle, the controller complained "Status: position warning", and the measured angle didn't change.
• So we asked it to search for home, which seemed to work. The homing position seems to be around the max power out of the TCS (5 W).
• Then I asked for 50°, but for some reason the measured angle dropped to −7° and then stopped.
• Then I asked for some other angles, but the stage kept rotating to random places.
• Then I searched for home again, and then asked for −50°. This time it seemed to work.
• Then I tuned the requested angle until the power output was 0.12 W.

JimW, HughR

We took all the SEIs down with guardian.  Ran foton -c foton hepifile and then loaded the modified file.  Re-isolated all platforms.

J. Oberling, P. King

Today we measured the OLTF of the ISS inner loop and the PMC.  This was done in response to LLO's recent measurement of the same documented here.  Peter has all the TF data and will post it as a comment to this report.  For the ISS inner loop, the gain was changed from 6dB to 16dB in the last couple of days, so we measured the TF at 6dB and at 16dB of gain to see how the increased gain changed things.  For the PMC we ended up increasing the gain to 22dB (up from 18dB).  This brought the UGF to ~7.5 kHz, closer to what we expect from E1200385.

I also had a chance to turn off the ISS without disturbing anything else and calibrate the 2 PDs discussed in alog 20043, and therefore complete the work in WP 5391.  The new gain values for the these PDs are as follows:

• PD_AMP: 0.00349223
• PMC_TRANS: 0.0103

Rana pointed out to me that the PR3 and SR3 suspensions may still have some shift due to wire heating during locks (which we won't see until a lockloss, since we control the angles of mirrors during lock).

Attached are the oplev signals for PR3 and SR3 at the end of a few different lock stretches, labeled by the time of the end of the lock. The lock ending 3 Aug was 14+ hours.  The lock ending 31 July was 10+ hours.  The lock ending 23 July was 5+ hours.  The lock ending 20 July was 6+ hours.

The PR3 shift is more significant than the SR3 shift, but that shouldn't be too surprising, since there is more power in the PRC than the SRC so there is going to be more scattered light around PR3. Also, PR3 has some ASC feedback to keep the pointing.  SR3 does not have ASC feedback, but it does have a DC-coupled optical lever.  SR3 shifts usually a few tenths of a microradian, but PR3 is often one or more microradians.  Interestingly, the PR3 shift is larger for medium length locks (1 or 1.5 urad) than for very long locks (0.3 urad).  I'm not at all sure why this is.

This is not the end of the world for us right now, since we won't be increasing the laser power for O1, however we expect that this drift will increase as we increase the laser power, so we may need to consider adding even more baffling to the recycling cavity folding mirrors during some future vent.