I was able to make a couple of PEM injections during ER7, not enough to get a full picture, but because it is of interest, we superimposed magnetic noise prediction points for the ITMX injection onto the plot for coupling at ETMY (figure). The predicted level for ITMX is flatter in frequency (some cable coupling?) but the coupling level near 10 Hz, where the prediction is closest to the DARM noise floor, is lower than for ETMY.

Robert S., Katie Banowetz

Elli, Greg, Nutsinee

The ITMY HWS return SLED beam is slightly clipped at the moment so we are testing to see whether or not the HWS sees the similar result to alog14698 before we move on to do CO2Y alignment work. Elli turned on the ITMY HWS camera yesterday morning to let it warm up. We ran the HWS script this afternoon before and after turning on the ITMY ring heater for >30 mins (the ring heater was turned on at 21:42:18 UTC). We didn't see any significant changes in spherical power, prism X, or prism Y. We also tried to run the script on ITMX HWS to see if we could get any result but the return beam was so dim that the script crashed after taking 50 sample of centriods ("Not enough unique sample points specified"). We turned everything off and called it a day. Hopefully we can work on ITMY HWS optics alignment tomorrow.

Filiberto, Patrick

I didn't realized it had been removed, and except for communication errors with the missing chassis, the PLCs ran on without apparent incident.

Filiberto made the same modifications as to the one at end X and reinstalled it. I updated the system manager accordingly, checked it into svn and activated it.

This time I didn't restart the PLCs, but I still had to restart the EPICS IOC. I burtrestored to 6:10 this morning.

Day's Activities

• Noticed SR3's Guardian was in ERROR, Guidance was to Load, so I Load-ed it.
• 8:20:  Christina cleaning at HAM6
• 8:35:  EY Beckhoff going down for ethercat vacuum guage work (Patrick/Richard)
• 8:50:  Starting ETMx charge measurements (Leonid)
• 8:55:  Pulling EX EtherCAT chassis (Filiberto/Ivan)
• 10-11:  TMDS piping work (Bubba)
• 11:00:  Ops Training
• 11:20:  HAM6 Closeout work (Matt/Dan)
• 12:26:  Stefan out to end station for timing work
• 12:45:  Nutsinee taking parts to LVEA
• 1:00:  Mike out to talk to HAM6 crew
• 1:10:  LVEA transitioned to Laser HAZARD
• 1:53:  TCS work for ITMy (Greg, Nutsinee)
• 2:15:  HAM6 Closeout work continuing again (Matt, Dan, Hugh, Greg)
• 3:55:  EY Beckhoff going down (Patrick)
• 4:01:  Checking racks for as-built (Dave)

After my work on the HAMS on Wednesday, I thought I would try working on BSC feedforward some more. So far I've just gotten RX FF working on ITMY (I was then promptly distracted by other stuff). First attached plot shows the improvement I've gotten between 10 and 30 hz, red and blue are the FF on and off Y ground, magenta and cyan are the T240 RX with FF on and off. Second plot shows that I managed to not spoily the Y direction anywhere (same color scheme, red/cyan FF on, blue/magenta FF off). Last plot shows my design, blue is the X/Y FF we are currently using, red is the ideal filter, green is the filter I've installed. Black was supposed to be an estimate of the performance, but I haven't quite figured that out yet, I'll post when I've fixed it. It is supposed to be something like 1 - (filter installed) / (ideal filter), but all I get is ~1, which means no subtraction.

Leonid.Prokhorov, Jeffrey.Kissel

We measured ETMY and ETMX charge using optical levers. At both TM the charges are much lower than it was before discharging. Plots of the day and long-term are attached.

Note, that for ETMY we see the other sign of pitch and yaw response than it was in measurements of June, 12. We have not find the reason. We did the couple of measurements with Low-voltage driver instead the Hi-voltage. Sign of respose for Hi and Low voltage drivers agrees even if correlation of measured points for low voltage is very low. Dependencies of pitch and yaw on bias voltage are in attachment. 
Just in case: for all ETMX measurements signs are the same as June, 12. For ETMY the previous measurements of charge was in Jan and it gives us the 3rd combination of signs. 

We studied one year data taken from May 01, 2014 to April 30, 2015. The results agree with the earlier findings from 4-months data (here), i.e., EY tilts twice as much as EX along the beam line. Figure shows 1 year of the 0.03 to 0.08 Hz beamline seismic band at EX and EY plotted against wind speed measured at EX. The full study is documented here.

Dipongkar Talukder & Robert Schofield

During ER7, the alignment of the IMC was adjusted to minimize the jitter peaks in DARM around 312 and 347 Hz (Link). We examine the stability of the tuning here. The top two traces in the figure are BLRMS bands centered on the peaks, and the tuning is the sharp drop at the left of the plot. The dashed horizontal lines on the plots show the pre-tuning and post-tuning level.  

The tuning seems to have been fairly stable, the peak height at the end of the run was about what it was right after tuning. The peak height increased during the period when the power was increased to 24 W, which is indicated on the plot by a yellow background. This was expected because the alignment was not retuned for this power. But when the power was returned to about 17W (cyan background) the tuning returned to its good state. 

The main drawback that we found was that the peak height started high after each lock and drifted down to the tuned level over tens of minutes.

Dipongkar Talukder & Robert Schofield

Filiberto, Patrick

Filiberto moved the cable for the gauge and I made the update to the system manger, committed it into svn, and activated it.

Filiberto then removed chassis 3 for his work on it. I disabled that chassis and the one following it in the target system manager, activated and ran that configuration. I have not restarted the PLCs because I am not sure they will run without the missing chassis. The gauge appears to still be operating however, as it does not need a PLC program.

So the end X Beckhoff PLCs are not running while Filiberto works on the chassis.

Richard, Patrick

Did essentially the same work as yesterday (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19310), except the gauge was connected at the end of the photodiode chassis.

Kate, Matt and a wee bit of help from Calum Omc black glass shroud is installed. More to follow ... To do list 1) balance mass 2) beam dump 3) beam diverter 4) laser beam check 5) cables. Please note should look at cable from omc bench. Dan and Matt are going to look at this in am.

L. Prokhorov, J. Kissel

All the quadrants of ETMX ESD work Ok. 

The charge level at all quadrants of ETMX is much lower after the venting and discharging procedure. 
See plots of today's results and Long-term* plot below. 

* Points for LL quadrant (red) are correct only before May and the last point. At May and June,12 we had LL ESD broken.

Sheila, Kiwamu, Jim, Dave:

It appears that following the last successful build of h1ascimc on April 21 of this year, the file was modified to use a fastPZT version of the common ASCIMC_MASTER part. This part was not found, and the model would not compile. For now I have modified h1ascimc.mdl to use the standard ASCIMC_MASTER/ASCIMC part. The common part's input ports aligned correctly, but I had to manually connect the output ports up in the order found. Someone should verify that the DAC channels are correct, they are (counting from 0 through 15)

ch08 = PZT_P_OUT

ch09 = PZT_YAW_OUT

ch10 = SPAREOUT2

ch11 = MCREFL-SHUTTER_OPEN

The output IPC parts are labeled so I'm confident  they are connected correctly.

I have not installed this model, it needs checking before we do this.

Scott L. Ed P.

6/22/15
Cleaned 59 meters ending at HNW-4-086. Serviced diesel generator.

6/23/15
Cleaned 39.8 meters ending at HNW-4-088. Removed lights and cords and begin relocation to next section north. Test results posted on this A-Log.

6/24/15
Made run to town for fuel in all support vehicles and diesel tank. Filled water tank and cleaned vacuum machines. Restring cords, hang lights, vacuum support tubes, spray diluted water/bleach solution on floor.
This is an exceptionally dirty section.

From Ed's summary yesterday, assumed to be the same, since no emails about changing to Laser Hazard:

We are currently LASER SAFE in the corner and the ends. PSL is shuttered, CO2 LASERs are OFF. End station Viewports and tables are closed and locked. Not sure about the on/off statues of the ALS.

• Dust - all monitors, except optics lab and bakeout, are green, i.e. low counts.
• CDS overview - some red
• CDS DAQ - all GPS readbacks updating

Timeline - Last night:

• 6:38PM - HAM6 people out of LVEA

Timeline - This morning:

• 7:40AM - MattH into LVEA
• 7:48AM - Karen and Christine in LVEA
• 7:58AM - MattH out of LVEA
• 8:10AM - MattH into LVEA
• 8:15AM - Corey to Squeezer Bay - and back
• 8:35AM - Hugh to EX
• 8:47AM - Patrick/Daniel, WP5298
• 8:55AM - FilibertoC/PeterK/RichardM - WP5299 & WP 5300
• 9:06AM - Jason/Ed - EX Oplev
• 9:11AM - JoeD - Mids and End Stations to check fire extinguishers / lights

Data extracted for the three week period of ER7 (since the timing system would nominally be running steadily the entire time). The histograms show:

- Tight grouping of the minute trends in the data; min and max values for each minute end up in discrete bands. 
- The Time Code Generators show nearly identical histograms for their mean minute trends.
- The mean minute trends of the GPS clock are much more tightly grouped with a width of roughly 20ns; with minimum and maximum offsets included, the width roughly doubles.

Issues:

- There was a single second during which the MSR Time Code Generator was off from the timing system by approximately 0.4 seconds. The issue self-rectified before the start of the next second. Second-trend data was not available through dataview (or at least I couldn't get any out of it). This did not happen in the EY and EX time code generators. It did not happen again in the MSR time code generator. The anomaly happened at GPS time 1117315540.

I've attached histograms as well as screenshots of data taken from Grace.

I set up an accelerometer on the beam tube and measured the accelerations as I simulated the tapping that I observed during cleaning, and my tapping experiment mentioned here: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19038. Examination of the time series indicated that accelerations during typical taps reached about 1 m/s^2.  I suspect that some taps reached 1g. The figure shows spectra for metal vs. fist taps. The above link notes that I was unable to produce glitches while hitting the beam tube with my fist. The fist and metal taps both had about the same maximum acceleration of 1 m/s^2 (ambient acceleration levels are about 4 orders of magnitude lower), so the source of the difference in liberating the particles is probably not acceleration. Instead, it may be the change in curvature of the beam tube, which would be expected to be greater at higher frequencies. The responses from metal taps in figure 1 peak at about 1000 Hz while the fist taps peak at about 100 Hz. These results are consistent with a hypothesis that the metal oxide particles are liberated by fracture associated with changes in curvature rather than simple vertical acceleration.

When I was producing glitches in DARM for the link above, I noticed that we did not get glitches every metal tap but every several metal taps. I tried to quantify this by making many individual taps at several locations along the beam tube. Unfortunately, we lost lock with the first loud glitch and I did not get a chance to repeat this before the vent. Nevertheless, it would be good for DetChar to look for smaller glitches at the time of the taps given below. Allow a 1 second window centered around the times given below for my tap timing uncertainty. I tapped once every ten seconds, starting at ten seconds after the top of the minute so that there were six taps per minute.

UTC times, all on June 14

Location Y-1-8

20:37 - 20:38 every ten seconds

20:47 - 20:50 every ten seconds

Next to EY

20:55 - every ten seconds until loss of lock at 20:56:10