The MICH feedforward path into DARM has been retuned, since Gabriele recently found a nontrivial amount of coupling from 50 to 200 Hz.

First, the MICH → DARM and MICHFF → DARM paths were measured according to the prescription given here. Then the ratio of these TFs was vectfitted and loaded into FM4 of LSC-MICHFF. This is meant to stand in place of FM5, which is the old frequency-dependent compensation filter. The necessary feedforward gain has been absorbed into FM4, so the filter module gain should now be 1. These changes have been written into the LSC_FF state in the Guardian.

Details

The attachment shows the performance of the new retuning compared to the old retuning. At the start of this exercise, I had already changed the FM gain of the "old" retuning from 0.038 (in the Guardian) to 0.045, as this removed a lot of the coherence near 100 Hz.

Also, I had previously widened the violin stopband in BS M2 L, but had not propagated this change to the analogous filter in LSC-MICHFF. This is now fixed. Also note that if any change is made to the invBS compensation filter in BS M3 L, this change must be propagated to LSC-MICHFF as well.

I did not have time to implement SRCL feedforward. I suspect it would be a quick job, and could be done parasitically with other tweaking activities.

I injected pitch (270 Hz) and yaw (280 Hz) lines with the PSL piezo mirror and then tried to minimize them in DARM by adjusting values of the offsets of DOF2P and DOF1Y of the IMC WFS.  It was a bit tricky because of ten-minute alignment time scales. But we reduced the injected pitch peak height by a factor of 2, and the yaw by 5 (we cared most about yaw because the PSL jitter peaks are mainly in yaw).  The inspiral range increased by a few Mpc and the jitter peaks seemed down by a factor of a few, but I will wait until tomorrow to put in spectra in order to be sure that the improvement is stable. DOF2P was changed from 135.9 to 350 and DOF1Y from 47.5 to 200. I think we could do better with another 2 hours.

Robert, Kiwamu, Evan

19:48 - Intent Bit set back to Undisturbed. Lock is still going strong.

16:00 - Took the chair with both H1 and L1 locked.

17:31 - L1 lost lock, so I turned the Intent Bit off for Evanand Robert to return LSC Feedfowardand tune WFS offsets.

This work should last about 2 hours.

Hannah Fair, Stefan Ballmer

Just a few days ago the interferometer tended to loose lock at full input power (23W) in ~10 to 40min. (Hence the run is at 17.3W.)

We went back to the following lock losses:

1) Jun 02 2015 01:49:44 UTC    = GPS 1117245000
2) Jun 02 2015 03:53:19 UTC    = GPS 1117252415
3) Jun 02 2015 08:13:04 UTC    = GPS 1117268000
4) Jun 02 2015 11:33:54 UTC    = GPS 1117280050

All of them showed as immediate cause of lockloss a run-away of the MICH_Y ASC loop on a time scale of about 0.2sec. (0Plots 1-4).
However, lock losses 3) and 4) also showed a significant control signal drift in PRC2, SRC1, SRC2 (both Yaw and Pit) over about one minute time scale before the lock-loss.

We therefore suggest lowering the MICH_Y ASC gain slightly next time we try 23W, and then investigate the ASC signals, most likely for the SRC.

Scott L. Ed P. Chris S.

We found some cracks in the concrete enclosure while hanging lights this afternoon, 730 meters south of X-End. The cracks run the entire length of a single panel on both the east and west side of the tube, up approximately 2.1 and 2.3 meters respectively from the slab. Picture 018 also shows the crack extending >2" horizontally at the end of the panel.

I have not ever put anything on resource space but I do have 20 more pictures that I will attempt to download there.

Only 15 meters of tube cleaned today after moving lights and looking at the cracks. 

Had trouble in the morning maintaining lock in the transition to REFL_TRANS. I was going to do an initial alignment per Sheila's suggestion, but then it locked. I have not done an alignment today. Ended the shift in science mode.

The computer video6 which was used to display the Range display and the ISC guardian overview has been replaced.

The new computer is an Intel NUC, which is a 4 core i5 CPU, 16G RAM computer running Ubuntu 14.04, with a KDE display manager.  The computer has a wireless keyboard which the operator manages.  The hostname for the computer is nuc0.  This computer cannot be managed with remote desktop at this time, only with the remote keyboard.

Instructions for maintaining the displays on the computer are in the CDS wiki, under Operations/FiguresOfMerit.

[Daniel, Paul]

We have updated our LHO FINESSE file (https://dcc.ligo.org/LIGO-T1300904) to compute an estimate of the DCCP as requested by Jeff.

The DCCP value we calculated was 369 Hz. This is for a well mode matched and aligned setup.

The optics details were taken from the galaxy page for the various mirrors installed at LHO. We also tried to get some more accurate losses in the arms taken from the following documents:

The caveat here is that the DCCP value has been seen to wander depending on alignment, as was reproduced in some of Gabriele's simulations, https://dcc.ligo.org/LIGO-G1500641. Here Gabriele found a slightly higher well aligned DCCP value of ~380Hz. We know that the DDCP value depends on many variables (alignment, mode mismatch in SRC, arm losses etc.), some of which are not yet well constrained with measurements. 

Attached is a plot of the DARM TF from the Finesse model, which is well described by a single pole at 369 Hz.

14:26 Starting beam tube washing at HNW-4-064 in ~ 10 minutes
15:11 Jim replacing video6 mac mini with NUC

15:49 Went to science mode
15:59 Beam tube washing is done for the day

Betsy, Pattrick, Dave

The local copy of H1SUSMC2.txt filter file was out of sync with the SVN repository. When we tried to commit it we got a "copy out of date" error. To get around this, we copied our version into a backup file, svn reverted the file, svn updated the file, copied back in our new version of the file and then were able to commit it to the repository. During this file shell game, the h1susmc2 front end computer saw the file change and flagged the CFC bit (reporting modified file). This is a latched bit, so even though we returned the file back to the original the flag persists. During the H1 down time, we loaded all coefficients on h1susmc2 to clear the flag. No change to filters were applied.

This appears to be from Evan opening awggui and selecting a channel. It showed up even though he never hit start. It went away when he closed awggui.

late post from Tuesday evening when PNNL disrupted offsite network access for maintenance. The GRB alert system running on h1fescript0 reported that it was unable to contact the GraceDB resource, and then seamlessly reconnected when network access was restored. This outage lasted just over a minute, so the CAL_INJ_CONTROL MEDM screen would have been RED for a few seconds.

[ext-alert 1117332997] CRITICAL: Error querying gracedb: [Errno 113] No route to host
[ext-alert 1117333060] CRITICAL: Error querying gracedb: [Errno 110] Connection timed out
[ext-alert 1117333063] CRITICAL: Error querying gracedb: [Errno 113] No route to host
[ext-alert 1117333064] CRITICAL: Error querying gracedb: [Errno 113] No route to host
 

Since there have been a few uncommitted commissioning changes to filter files and guardian code, Dave and Sheila confirmed it was time to commit them all to the svn since the IFO is running ~well for E7.  Dave and I are working to clear house in all subsystems.  I have committed:

All SUS.txt filter files

All 2 ASC filter files - H1ASC.txt, H1ASCIMC.txt

All 2 ASC filter files -H1ALSEX.txt, H1ALSEY.txt

All LSC.py guardian scripts

Note, all SUS guardians are up-to-date in the SVN.

When we ent to commit H1SUSMC2 it failed with an error stating file is "out of date".  So, we copied the file to a backup and did a work around:

betsy.bland@operator1:/opt/rtcds/userapps/release/sus/h1/filterfiles$ cp H1SUSMC2.txt H1SUSMC2.txtbak
betsy.bland@operator1:/opt/rtcds/userapps/release/sus/h1/filterfiles$ svn up  H1SUSMC2.txt
Conflict discovered in 'H1SUSMC2.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: ^Csvn: Caught signal
betsy.bland@operator1:/opt/rtcds/userapps/release/sus/h1/filterfiles$ svn revert H1SUSMC2.txt
Reverted 'H1SUSMC2.txt'
betsy.bland@operator1:/opt/rtcds/userapps/release/sus/h1/filterfiles$ svn up H1SUSMC2.txt
U    H1SUSMC2.txt
Updated to revision 10745.
betsy.bland@operator1:/opt/rtcds/userapps/release/sus/h1/filterfiles$ cp  H1SUSMC2.txtbak  H1SUSMC2.txt

This however caused the FE DAQ status to show the error that the filter file had changed.  Indeed to file changed name, and then back, but we confirm that the contents of the file are the same, so we will have to hit the LOAD COEFF button on MC2 to clear the FE alarm.
 

Just before setting the intent bit for the current lock stretch, Patrick, Kiwamu and I looked at SDF.  A few red alarms needed attention.  We set SDFs:

• H1:LSC-TR_X_NORM set to be not MON, since GRD manges this channel.
• ACCEPTED SR3 M2 OPLEV damping loop arrangement revised by Sheila yesterday - see snapshot of what values were accepted.
• OMC DITHER button was ON, turned button OFF since actually no EXC was happening.  Likely left over from work last night.
• SRM and PRM had gains changed to zero in the LOCK L loop that is unused.  We set these to -0.02 as that was what SDF was expecting.  Again, loops are off so no functional change.

11:32 Richard turned off lights in the LVEA, reports that the crane lights are still on. Lights are stuck on at end Y.
11:49 Karen getting paper towels out of mechanical room.

12:24 Kiwamu and Betsy have gone through the SDF differences. Went to Science mode and notified LLO control room.

11:28 Dave reloaded filter module coefficients for h1sus frontend. (WP 5245)

Chris Pankow, Jeff Kissel, Adam M, Eric Thrane

We restarted tinj at LHO (GPS=1117411494 ) to resume transient injections. We scheduled a burst injection for GPS=1117411713. The burst waveform is in svn. It is, I understand, a white noise burst. It is, for the time being, are standard burst injection waveform until others are added. The injection completed successfully.

Following this test, we updated the schedule to inject the same waveform every two hours over the next two days. The next injection is scheduled for GPS=1116241935. However, this schedule may change soon as Chris adds new waveforms to the svn repository.

We are not carrying out transient injection tests at LLO because the filter bank needs to be updated and we cannot be sure that the filters are even close to correct. Adam thinks they will be updated by ~tomorrow.