J. Kissel

Took a set of Top to Top transfer functions for H1 SUS SRM this evening. Results look like the suspension remains free after Betsy & co re-engaged the OSEMs from having backed them off during the monolithic optic install. 

Data lives here (and has been exported to files of similar name):
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_L_0p01to50Hz.xml
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_P_0p01to50Hz.xml
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_R_0p01to50Hz.xml
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_T_0p01to50Hz.xml
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_V_0p01to50Hz.xml
        2017-10-13_2122_H1SUSSRM_M1_WhiteNoise_Y_0p01to50Hz.xml

Will post detailed graphical results with the usual comparison against previous measurements and the model on Monday. Attached is a sneak peak of the Pitch to Pitch TF, the DOF usually most sensitive to shenanigans.

The parts in question are D1101911 & D1101910.

HAM2: I've installed a QPD cable strain relief on IM4 trans. See first attachment.

HAM3: Done with MC2 trans and POPB, but not POPA.

For POPA, 1/4-20 screw wouldn't go in easily (I only tried for a minute or two) and I didn't bother to keep trying because I remember that this was a problem in the past for some of the QPDs (alog 19168 for TMSX).

One set of parts is left on the wire shelf on the work table in HAM2 cleanroom (top right of the wire shelf). If the 1/4-20 wouldn't cooperate, I would recommend to do the same solution as the above alog entry.

F. Clara, J. Kissel, R. McCarthy, G. Moreno

After 
    - sorting out confusion with drive electronics (thanks Fil and Richard!)
    - a few iterations of tuning transfer function amplitudes, 
    - realizing that the eddy current damping magnets may be interfering with / over damping the SUS, 
    - a tweak of a rubbing OSEM, and finally 
    - diagonalizing the longitudinal transfer function (i.e. actuating in Yaw to compensate for the SD OSEM's offset from the center of mass)
Gerardo and I have completed the first set of in-air, driven transfer functions with the recently installed OSEMs on the OFIS. 

Attached are the results, and the resonant frequencies are as follows:
    DOF          Freq (Hz)
     L         0.625 +/- 0.01
     T         0.625 +/- 0.01
     Y         1.039 +/- 0.01

This confirms that AOSEMs, driven with standard 16 bit, 20Vpp DAC, through a (LIGO) standard AI chassis, HAM-A coil driver and ISC/US-style satellite amplifier, pushing 3mm DIA x 6 mm LEN magnets is sufficient to drive the suspension. Further, the OSEM sensor has plenty enough signal to read out the position of the platform, so damping loops will be quite straight forward.

Excellent work design and assembly team!

Details
The data collection templates for the best, diagonalized transfer functions live in
    /ligo/svncommon/SusSVN/sus/trunk/OFIS/H1/OFI/SAGM1/Data/
        2017-10-13_2116_H1SUSOFI_M1_WhiteNoise_L_0p01to50Hz.xml
        2017-10-13_2116_H1SUSOFI_M1_WhiteNoise_T_0p01to50Hz.xml
        2017-10-13_2116_H1SUSOFI_M1_WhiteNoise_Y_0p01to50Hz.xml

Because the new SQZ electronics infrastructure is not yet in place, the drive chain is a temporary setup involving the digital drive chain of OM1 (hence the nonsensical denominator in the labels of the transfer functions), and several in-air cables, including a pin-flip ribbon cable (hence the poor coherence above 5 Hz).

Norna is suspicious of the OFIS's dynamical model put together by Mark Barton back in 2014, so hopefully this data can be used to solidify some degrees of freedom of the model.

I've created a new script that populates the new OFI's infrastructure with a diagonal sensor / actuator basis, which now lives in 
    /ligo/svncommon/SusSVN/sus/trunk/OFIS/Common/MatlabTools/
        make_susofis_projections.m
where the conventions are defined as in E1700352, T1200015, and G1701887. Note I'm also sticking with the SUS convention to have the OSEM2EUL and EUL2OSEM matrices be the *transpose* of each other, and not the inverse. Taking into account that the LF and RT OSEMs (for driving T and Y) are equidistant from the suspended center of mass by l_LR_to_COM = 0.111 [m], but the SD OSEM is offset from the center of mass by l_SD_to_COM = 0.056 [mm], means the drive matrix is 
  | L |    [     +r            +r             -1 ] | LF |
  | T |  = [     -0.5          -0.5            0 ] | RT |
  | V |    [    +0.5/l_LR      -0.5/l_LR       0 ] | SD |

where r = l_LR_to_COM / l_SD_to_COM, and I've abbreviated l_LR_to_COM as l_LR. Actually sticking in the numbers, and reporting as they must be in the CDS system, that's

OSEM2EUL = +1.9821   +1.9821   -1.0000         EUL2OSEM = +1.9821   -0.5000   +9.0090
           -0.5000   -0.5000    0.0000                    +1.9821   -0.5000   -9.0090
           +9.0090   -9.0090    0.0000                    -1.0000    0.0000    0.0000

TITLE: 10/13 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:

15:09 Garilynn into the LVEA

15:17 Betsy into biergarten

15:35 TJ out o HAM5 and then HAM2

15:39 Peter and Jeff heading ino PSL for water leak mitigation

17:04 Marc to MY

17:05 TJ out for a quick break

17:09 Gerardo into HAM5

17:36 Travis, Betsy, and Greg out of LVEA

18:12 TJ and Cheryl out to HAM2

18:15 Marc Back from MY

19:20 Gerardo ad Peter out to HAM5

19:21 Greg to biergarten to prepare chambers fo Monday work

19:27 TJ out for lunch

20:34 Gerardo and Peter back and Peter into the optics lab

20:49 Greg out and gone for the day

21:22 Arnab out to Y Cryopump area with Kyle

21:32 Richard out to CER

21:43 Peter and Gerardo out

Dust Monitor 102 has stopped responding in the last couple of hours and needs to be power cycled/re-started.

Today the CDS overview screen looks like it has a bad case of measles (see attached). This is due to the h1ioplsc0 model ADC/TIM glitching now it has a faster computer. Like the end station SUS, some times the glitch propagates into the IPC channels and in turn glitches the receiver models. Because LSC touches more models than end station SUS, these glitches are more prominent.

Last night I added the LSC models to my script which issues diag reset to fast computer models and receivers of end-station SUS every minute. I'll extend it to cover receivers of LSC.

Jeff B, Dave:

I have re-written the check_dust_monitors_are_working script to make the output more readable.

The script defaults to checking the past 12 hours. Additionally it can take a second argument to check for N hours ending M hours ago, where N and M are the two arguments given. For each dust monitor, it internally checks both 0.5um and 0.3um dust counts. If both have shown no variation over the time period provided (i.e. both have zero standard deviation) then a warning message is printed, otherwise an ok message is printed.

Here is a "all is good" example for the past 12 hours:

check_dust_monitors_are_working      
 
Checking dust monitors for possible problems over a period of 12 hours ending 0 hours ago...
 
    H1:PEM-CS_DUST_LVEA2       OK
    H1:PEM-CS_DUST_LVEA3       OK
    H1:PEM-CS_DUST_LVEA4       OK
    H1:PEM-CS_DUST_LVEA5       OK
    H1:PEM-CS_DUST_LVEA6       OK
    H1:PEM-CS_DUST_LVEA10     OK
    H1:PEM-CS_DUST_LVEA30     OK
    H1:PEM-CS_DUST_PSL101     OK
    H1:PEM-CS_DUST_PSL102     OK
    H1:PEM-EX_DUST_VEA1        OK
    H1:PEM-EY_DUST_VEA1        OK
 
done
 

Here is an example with HAM6's monitor in error, prior to this morning's restart of the LEAV6‌ dust monitor:

check_dust_monitors_are_working 12 12
 
Checking dust monitors for possible problems over a period of 12 hours ending 12 hours ago...
 
    H1:PEM-CS_DUST_LVEA2       OK
    H1:PEM-CS_DUST_LVEA3       OK
    H1:PEM-CS_DUST_LVEA4       OK
    H1:PEM-CS_DUST_LVEA5       OK
    H1:PEM-CS_DUST_LVEA6       WARNING: dust counts did not change, please investigate
    H1:PEM-CS_DUST_LVEA10     OK
    H1:PEM-CS_DUST_LVEA30     OK
    H1:PEM-CS_DUST_PSL101     OK
    H1:PEM-CS_DUST_PSL102     OK
    H1:PEM-EX_DUST_VEA1        OK
    H1:PEM-EY_DUST_VEA1        OK
 
done
 

Travis, Ed, Greg

We went down the x-arm to check if the cryopump baffle ring was grounded like the issue that Livingston had, alog 33667, where the ring was touching the copper pieces. One side was not centered very well, but was still clear of the copper block, the other side was pretty well centered. A quick bump test showed the baffle ring floating freely. 

Power cycled at 17:44. It's working properly again at this time.

Both doors on HAM 4 were removed this morning. HEPIs are covered also.

Everythin seems to be in working order this morning.

TITLE: 10/13 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY:

Kyle R., Rakesh K.  

Today we decoupled the 10" gate valve that isolates the YBM Main Turbo Pump (YBM MTP) from the Y-beam manifold.  Next, we removed the 10" valve from the YBM pump port.  

For tonight, we are leaving the YBM 10" pump port covered in UHV AL Foil.  Tomorrow we will install the valve and should make some progress towards re-coupling the the turbo to the valve.  

With help from Mark and Tyler, Betsy and I reinstalled the ITMx lower structure into BSC3 this morning.  In the afternoon, we worked on resuspending it to begin assessing alignment.  Tomorrow, we will check the alignment at the OpLev viewport and begin adjustments.

TITLE: 10/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:

15:15 Vent meeting

15:57 Travis and Betsy ou to the biergarten

16:00 Jason and TJ out to LVEA

17:44 Jason out to HAM5

18:05 Travis and Betsy out

18:29 Jason and Garilynn out

18:40 TJ out for lunch

18:54 Bubba and crew taking the HAM4 South door off (started earlier, not sure when)

19:00 Dave B having Dolphin issues and the CDS overview is quite red with TCS Chiller imminent on Verbal Alarms and the PSL PMC not unlocked

19:05 Dave B out to EY  to investigate Dolphin issue.

19:23 Dave back

20:00 Untripping IMs

20:02 Untripping MCs

20:03 Untripping PRs

20:05 Untripping BS

20:06 Untripping SRs20:12 Reset PSL EPICS alarm and readjusted ISS Diffracted Power

20:25 Marc to MY

20:39 Cheryl out to HAM2

20:44 Jason out to BSC1

20:57 Marc back

22:10 Betsy and Travis back out to biergarten

Krishna, Jim

This is a slight variation on an earlier duty cycle analysis by Jim. I'm trying to establish how the new ISI-Stage1 control scheme implemented in O2 at LHO benefited the interferometer. As a reminder, in O1, we only used feedback from the Stage 1 seismometer and switched between the 45/90 mHz blends to combat microseism/wind respectively. In O2 we used 'tilt-subtracted' feedforward at low-frequencies and 250 mHz blends as the nominal configuration on all platforms including the HAMs. The data lives in:  SeiSVN/seismic/Common/Data/LHO_O1_O2_duty_cycle_data

The first attachment shows plots for duty cycle versus wind for O1/O2. It uses the minute trends of ISC Lock State and the ETMY windspeed (max) signal. The first page simply shows the distribution of wind - fraction of time windspeeds were in a given bin (bins were ~2 mph) during O1 and O2. The second page shows the fraction of the time the interferometer was locked at a given windspeed. Not only is there a clear improvement in O2, but the curve looks flat up to a windspeed of ~30 mph unlike in O1. The overall duty cycle in O2 seems to have suffered a bit, possibly due to other reasons. Pages 3 and 4 show similar plots, but only comparing the 45 mHz blends used in O1, which are still the default configuration at LLO. Again, it is interesting to note the downward trend on page 4 for the 45 mHz blend, which suggests that even 10-20 mph winds would begin to impact the interferometer.

The second attachment has very similar plots for duty cycle versus microseism velocity, using the band-limited-rms ITMY_Z (max) signal in the microseism band. The O2 configuration looks better once again and there is a similar trend of nearly flat duty cycle up to ~1300 nm/s velocities in O2. The distribution of the velocities looks odd/different, partly because of the inclusion of Hanford summers in O2, which are very quiet in the microseism.

S. Dwyer, J. Kissel

This completes the investigation of the broken beam dump found in HAM6 (see LHO aLOG 38918) -- the beam dump has been identified as the OMC REFL Beam Diverter Dump. 
This beam dump captures light *down stream* (toward the OMC) of the fast shutter.
The dump was broken in a relatively clean vertical fracture which lines up with the dump's set screw, and when reconstructed appears to show a small pock-mark from an apparent small laser blast.

While there's no way to prove why it broke, we have two main suspicions:
   - The black glass is secured to the dump's mount with metal set screws. It has been suggested that all such black glass should be secured with PEEK set screws. If not, these metal screws create un-due stress on the glass, especially if over-tightened.
   - During observation, it has become standard to leave the OMC REFL path's Beam Diverter CLOSED, i.e. blocking the path from hitting the OMC REFL QPDs and/or exiting HAM6 onto ISCT6. Thus, during some high-power lock loss in which both
      - the fast shutter protection failed, leaving the OM2 > OM3 > OMC > OMC REFL path exposed, and
      - the OMC was unlocked sending lots of OMC REFL light down the REFL path (instead of through the OMC, if it were locked).


Picture highlights and labeled drawings are attached as .jpgs, and a more complete collection of pictures are compressed as a .pdf.
Regarding the metal set screws on this dump: a survey of other similar beam dumps in the chamber indicate that *all* such dumps in HAM6 are secured with metal set screws (see 2017-10-11_HAM6_BumpDump_SetScrews.pdf).

Open question:
   - Was the beam diverter closed when the shutter failed and killed the OMC DCPDs in Aug 2016 (LHO aLOGs 28820 and 28842)?
   - If closed, did we inspect this path / dump when we went in to fix the DCPDs?
       This picture from the Corey's Resource Space collection show that the dump is at least intact then.