Shift Summary - Day

TITLE: 07/25 Day Shift 15:00 – 23:00 (08:00-16:00), all times posted in UTC

STATE of H1: Locking

INCOMING OPERATOR: Patrick

SHIFT SUMMARY: Busy maintenance day, followed by a tedious locking process. A particular initial alignment was performed after the ALSY camera was reported to have potentially been bumped. This alignment lead to several locklosses from ENGAGE_SOFT_LOOPS, then later we experienced locklosses from LOCKING_ALS and then CARM_TO_TR. We did an initial alignment, found that we were still experiencing CARM_TO_TR locklosses, and then some combination of waiting/Jeff and Daniel working their commissioning magic (see Jeff’s alog) allowed us to get past that step. We are currently in LOWNOISE_COIL_DRIVERS, approaching NLN.

LOG:

15:00 (08:00) Start of shift

15:16 (08:16) Dripta to Optics Lab

15:19 (08:19) Gerardo to EY

15:25 (08:25) Richard back from LVEA

15:36 (08:36) Gerardo, Fil to EY, EX -- grab, install cable

15:50 (08:50) Dick, Marc, Matt to CER -- inject lines

16:01 (09:01) Kyle to LVEA -- setting up equipment

16:01 (09:01) Peter to LVEA -- transition to laser safe, go PSL enclosure

16:01 (09:01) Karen to EY

16:04 (09:04) Dripta out of Optics Lab

16:08 (09:08) Chandra to LVEA

16:08 (09:08) Chris to MX

16:09 (09:09) Jason to EY -- ALSY beam profile works

16:15 (09:15) TJ to EY -- assist Jason

16:18 (09:18) Timesh, Dripta, Laurence to EX -- measure BSC pier

16:24 (09:24) Adrian, Matt to LVEA -- moving speakers, uninstalling vibrometer

16:28 (09:28) Vanessa to LVEA

16:35 (09:35) Gerardo to High Bay -- lift HEPA pumps

16:50 (09:50) Peter out of PSL enclosure

17:05 (10:05) Karen leaving EY

17:15 (10:15) Jim to CER -- investigate ITMY racks

17:15 (10:15) Keita to PSL enclosure

17:18 (10:18) Adrian, Matt out of LVEA

17:35 (10:35) Jim back from CER

17:45 (10:45) Gerardo back from high bay

17:46 (10:46) Gerardo to LVEA -- grab cables

17:50 (10:50) Keita back from enclosure

17:50 (10:50) Vanessa to EX

17:53 (10:53) Fil, Richard back from EX

17:54 (10:54) Chris, Bubba to LVEA -- measure HAMs

17:56 (10:56) TJ, Jason back from EY

17:56 (10:56) Fil to EY -- take picture of chassis

18:03 (11:03) Gerardo back from LVEA

18:14 (11:14) Timesh to Optics Lab

18:22 (11:22) Bubba out of LVEA

18:30 (11:30) Vanessa leaving EX

18:30 (11:30) Gerardo to MY -- take picture of pump

18:37 (11:37) Fil back from EY

18:51 (11:51) Karen out of the LVEA

18:55 (11:55) Chandra, Kyle out of LVEA

18:58 (11:58) Gerardo back from MY

19:07 (12:07) Dick, Matt, Marc out of CER

19:41 (12:41) Rick, Ethan to Optics Lab

19:44 (12:44) TJ sweeping LVEA

20:02 (13:02) Timesh out of Optics Lab

20:06 (13:06) Peter to mezzanine

20:13 (13:13) Peter back from LVEA

20:30 (13:30) Rick and Ethan out of optics lab

21:36 (14:36) Kyle to MX

22:47 (15:47) Ethan to Optics Lab

23:00 (16:00) End of shift

Tuesday Maintenance - RF Noise Injections and Continued Noise Profiling

Dick Gustafson, Marc Pirello, and Matthew Withers

We performed a series of RF signal injections by passing RF signals to the shielding of several cables via a ferrite transformer. The following table summarizes our work.

Time (UTC)	Cable Name	Cable Frequency [MHz]	Injection Frequency [MHz]	Injection Amplitude [dBV]	Measured Frequency in DARM [Hz]	Measured Amplitude in DARM [m/Hz^(1/2)]
15:56 - 15:59	ISC-C4-41-5	9.10023	9.10028	-30	50	1.8537*10^-19
15:59:45 - 16:03:45	ISC-C4-37-1	9.10023	9.10028	-30	50	4.12905*10^-19
16:05 - 16:09	ISC-C4-41-6	45.50115	45.5014	-30	No discernable effect	No discernable effect
16:10:15 - 16:14:15	ISC-C4-37-2	45.50115	45.5014	-30	No discernable effect	No discernable effect
16:17 - 16:21	ISC-C3-41-4	35.5	35.50005	-30	No discernable effect	No discernable effect
16:22:45 - 16:26:15	ISC-C4-33-4	72	72.00005	-30	No discernable effect	No discernable effect

From roughly 16:30 to 19:00 UTC, we collected the noise profiles of the following cables:

ISC-C4-41-5

ISC-C4-37-1

ISC-C4-41-6

ISC-C4-37-2

ISC-C3-41-4

ISC-C4-33-4

Pre-modecleaner high voltage power supply programmed

The Kepco BHK-500-0.4MG power supply was programmed with its output voltage set point at 375V and output current set point at 50 mA.
Storage location 01 was used for this.

    In case the power supply trips off again to restore the settings perform the following steps:
 - turn on the power supply
 - press the RECALL button followed by ENTER
 - press the red OUTPUT ON/OFF button

CDS Maintenance Summary, Tuesday 30th July 2019

WP8295 Add 2 channels to DAQ-DMT broadcaster

John Z, Dave:

Two new slow channels were added to h1broadcast0's ini file (H1:GRD-SEI_CONF_STATE_N, H1:GRD-SEI_CONF_STATUS). Change was applied during the DAQ reboot.

WP8296 New Guardian SEI nodes

Jim W, TJ, Dave:

A new H1EPICS_GRD.ini file was created with 115 additional channels for the 5 new nodes (H1:GRD-ISI_HAM[2-6]_BLND).Change was applied during the DAQ reboot.

WP8282 DAQ Reboot

Dave:

Instead of a usual DAQ restart, today I rebooted three DAQ machines which were suseptible to the kernel-2.6.35 208.5+day crash, and which had been running for 202 days. The machines rebooted are: h1dc0, h1tw1, h1broadcast0.

The reconfigure/restart/reboot sequence was:

01. Create the new H1EPICS_GRD.ini file from the Guardian generated H1EDCU_GRD.ini file (FRS13329 was opened for this issue)

02. Generate the new H1EDC.ini file. Verify all new channels exist.

03. Check DAQ for channel duplication errors.

04. h1dc0: turn off monit, kill daqd process (which is not then restarted), reboot h1dc0.

The following steps done while h1dc0 was rebooting:

05. h1edc, restart external edcu with new configuration (num channels increased from 40,549 to 40,664)

05. h1tw1 stop monit, kill daqd process, reboot h1tw0

06. h1broadcast0 stop monit, kill daqd process, reboot h1broadcast0

All reboots took about 5 minutes because after running for 202 days an FSCK was forced.

After h1dc0 started running again, the other DAQ systems which had not been rebooted restarted their daqd normally.

After h1tw1 completed its reboot, its daqd was started normally by monit.

After h1broadcast0 completed its reboot, monit did not restart its daqd process. I had to restart this manually via the monit Web Page.

Number of channels in the DAQ-DMT increased by 2 from 1,428 to 1,430

After 20 mins I renamed the truncated second trend frame files on h1fw[0,1] to force NDS2 to rescan the channel lists.

Decommisioned lockloss virtual machine

Carlos

the virtual machine lockloss was powered down at 11:15PDT.

ALSy Bad Green Mode Matching Investigation - Round 2

J. Oberling, T. Shaffer

Following on from Round 1 last week, TJ and I went out to ISCTEY this morning with a ThorLabs BP209-VIS scanning slit beam profiler to see if we could identify where the ALSy green beam was becoming elliptical (as first identified by Georgia, Laurence, and Dripta here).  Because of how scanning slit profilers work it is entirely possible to miss ellipticity that is rotated 45° w.r.t. the profiler's sensor.  Luckily the BP209 allows the user to rotate the sensor plane to account for this (from +90° to -90°), so we took 2 profiles at each point: 1 with the sensor head at 0° and one at +45°.  To see the sign convention for the sensor rotation, I've included a picture of the front face of the BP209 (1st attachment); the entire face rotates, with the small white line (lined up with Y in the picture) being the fiducial for setting the sensor angle.  As the ALSy green path is quite crowded, there were only 2 points where we could fit the profiler: after ALS_HWP6 and after ALS_HWP5 (ALS_HWP6 preceeds ALS_HWP5 in the beam path, see the table layout here).

First things first, as reported in Round 1, I suspected the green beam was clipping on the entrance aperture of the EOM, so I tried to get a picture to show this.  Unfortunately the green beam completely washes out the EOM entrance aperture, and my phone camera is too old to have saturation controls to clean this up; see the 2nd attachment.  Looking at my phone pics, one cannot discern if there's any clipping; best I can say is there's some scatter being picked up by my phone  All was not lost, however, as TJ has a newer phone and was able to get much cleaner pictures, which he will attach as a comment to this alog.  Looking at TJ's pictures, it appears the beam is in fact clipping on the entrance aperture of the EOM.

Before we took any beam profiles, I first wanted to check the power at the 2 locations we were planning on taking profiles (don't want to damage the profiler); an Ophir PD300-3W-V1 3W head was used in conjunction with an Ophir VEGA for this measurement.  The powers measured as follows:

• After ALS_HWP6: 38.9mW
• After ALS_HWP5: 32.0 mW

Max power on the BP209 is ~100mW for a 1mm diameter beam, so we're good to go.  We then proceeded to take the profiles at the locations mentioned above; see last 4 attachments.  Unfortunately, the beam profiler with the addition of its power/signal USB cable (which sticks directly out of the back of the unit) was too long to get more than one profile at each location, so please keep that in mind when looking at the attached profiles; as I said, this section of the green path is a little crowded (the profiler barely fit between ALS_HWP5 and ALS_L5).  Please note, all lenses were left in the beam path (specifically ALS-L4) as removing then reinstalling them can cause an aligment shift.  While alignment can be recovered, it is a non-trivial exercise not to be undertaken lightly.

Profile #1: After ALS_HWP6

The beam here, in my opinion, looks OK.  Not great, but OK.  Slightly elliptical with the horizontal axis being ~11.5% larger than the vertical, but nothing grossly out of order here.  Rotating the sensor head by +45° doesn't reveal any gross off-axis ellipticity; in fact, the beam looks more round, indicating that the profiler is missing the slight ellipticity seen when in its normal orientation.

Profile #2: After ALS_HWP5

Here, things get interesting.  The beam is obviously elliptical at this point, with the horizontal axis being ~38.9% larger than the vertical.  As with the 1st profile, rotating the sensor by +45° does not reveal any gross off-axis ellipticity; also as with the 1st profile, the beam looks more round.

With the above being said, the beam diameters measured are roughly consistent with the mode matching simulation performed when the table was assembled in 2013; see Figure 13 of T1300837.  From Figure 13 it is apparent the beam was expected to be elliptical throughout the beam path.  This ellipticity is caused by the horizontal and vertical waists being in different locations.  The 35W FE in the PSL shows similar behavior, as does the spare SQZ NPRO I recently tested, so this isn't entirely unexpected.  While the clipping observed should be corrected (and is most likely contributing to the bad mode matching), based on T1300837 it is less clear to me that the ellipticity measured today is the root cause of the issue.

LVEA and End VEAs Swept

Added HAM Blend Nodes

Jim asked for some HAM blend nodes, so added them to the local config file and made a starting file for the HAM ISIs. This uses the same code as the BSC BLND nodes and will auto-generate the states based on the config file.

The 5 new nodes are running and were tested: ISI_HAM2_BLND, ISI_HAM3_BLND, ISI_HAM4_BLND, ISI_HAM5_BLND, ISI_HAM6_BLND.

I will update the GUARD_OVERVIEW_COMPACT.adl, GUARD_OVERVIEW.adl, and ISI_CONFIG.adl today.

The node count is now exactly 150 for H1

Consider Loosening Threshold for IMC WFS Centering

J. Kissel, N. Lecoeuche

In order to reduce the number of red herrings during any given recovery, we followed the rabbit of hole of guardian warnings on the IMC_LOCK guardian which often states "IMC WFS not centered." 

This message appears, typically, after PSL incursions (rare), site power outages (rare), or computer failures (rare) when the IMC suspensions's or PSL Periscope PT alignments get lost. Because these events are rare, instituional memory loss causes confusion for folks when they see that error message and wonder if action is needed. However, once these alignments are roughly recovered (via reseting sliders on suspensions), the WFS, again typically, eventually recover their centering all on their own as the RF loops converge [there are no "DC centering" loops on IMC WFS, as there are for many of the the WFS systems]. 

Where is the threshold set and can we modify it to better reflect this knowledge?

This message is generated by a function in ISC_Library (WFS_DC_centering_servos_OK), which is called by another decorator function (gen_check_WFS_DC) in ISC_Library which creates the class (or state as we use it in guardian) called check_WFS_DC, which is called inside the IMC_LOCK guardian state "LOCKED." The decorator function, gen_check_WFS_DC, is used any where there are WFS. 
Inside the function, WFS_DC_centering_servos_OK, the threshold is hard-coded to be abs(WFS DC Signal) > 0.5 (for PIT or YAW of any WFS DC Signal) -- and note that by convention, WFS DC signals are normalized by their SUM, such that typical signals range from +/- 1.0, and centered goodness is typically considered in regions when WFS DC signals are less than +/- 0.1-0.2.

Because WFS_DC_centering_servos_OK is a function used all over the place, we can't solely change the threshold for the IMC WFS, and thus "just increasing the threshold."

So, the short answer is "no." 
However, with a bit more thinking, I bet we can catch this fish.

I attach a short (just this past time it happened during a PSL incursion), medium (including today's incursion and the past few days of lock losses), and long (all of O3) trend of the IMC WFS signals for reference.

Water filter inspection

After last night's trip, I inspected the water filters under the optical table.  They seemed fine with no particulate matter
in the containers.  One of the filters - the one on the left as you look at both from the right hand side of the table - looked
a little darker than the other one, which looked pristine white to my eye.

    No under the table water leaks were found either.

Bumped the Magnetometer at the X End

While taking measurement of the BSC pier (50921), I bumped the yellow stand that the magnetometer is mounted on (see in image attached to this alog). There are inscription on the floor where the feet used to be located and these positions are at some distance to where the feet of the stand currently sit (and the dates are over a year old) . I don't think the feet were located in these positins to begin with and I didn't bump the stand that much, it moved it no more than 1cm.

I'm not sure if this will affect PEM measurements and Detchar thus I am tagging both. I am also unsure if a 're-alignment' is required.

 

FSS open loop transfer function

Measured the FSS open loop transfer function.  Common gain = 20.0 dB, fast gain = 15.0 dB according to the FSS MEDM screen
slider values.  Measured UGF was ~417 kHz with a phase margin of 56 deg.  Just about where we would want to be in some
regards.

    No detrimental effects from last week's outage.

OLTF.[txt, jpg] transfer function to 1 MHz, text data and image
OLTF2.[txt, jpg] transfer function to 5 MHz, text data and image

ITM Y camera adjusted

Before full blown maintenance started I adjusted the ITMy GigE camera.  The spot has returned.  I am afraid that the green camera may have a problem.  While getting in position for the IR camera a peice of equipement caught on the Green camera network connection.  This should be okay but I am worried it moved the camrea.

Camera mount sensitivity to movement in the area associated with IIET Ticket 11931.

*A* way to recover from a green camera move: (excerpt from LHO aLOG 45696):
   - reverting the ITMY, ETMY and TMSY alignment (via moving sliders and steering to top mass OSEM values) to the last time the green arms were locked (yesterday, Dec 4 2018 @ 10:00 UTC), 
    - with ISC_LOCK set to INITIAL_ALIGNMENT, (and thus ALIGN_IFO already in SET_SUS_FOR_ALS_FPMI), set ALS_YARM to LOCK_NO_SLOW_NO_WFS and confirm that the transmitted power in the YARM is above 1.0
    - while confirming the the camera loops are OFF (using your favorite method, today we chose to hold the outputs of the camera loop filters at 0.0), set ALS_YARM to INITIAL_ALIGNMENT. This turns on the green WFS, but forces a zero to the control output of the camera servos (even though it looks like they've been turned on by the guardian.)
    - wait for the ALS WFS error signals to converge toward oscillating around zero with small amplitude. Accept that the camera loop error signals are large, and request GREEN_WFS_OFFLOADED
    - move on with the rest of initial alignment.
As such, aligning MICH was a little more difficult, and aligning the SRC was more difficult.
With this path forward, we'll not know that we have a good alignment -- and PRMI/DRMI lock acquisition will be more challenging -- until we *get* PRMI/DRMI locked, start running *red* WFS, get through the CARM reduction, get the arm HARD and SOFT loops engaged. Once we get the full red ASC systems running -- then we'll be sure to check the green camera offset settings and confirm that this was indeed the cause of our problems.

NOTE -- AS OF JUNE 2019, WE ARE USING AN AUTOMATED INITIAL ALIGNMENT SEQUENCE. THIS MUST BE TURNED OFF FOR SUCH A RECOVERY. (These instructions were written before we had the automated system. We'll take notes for how we recovered today, and post later.)

SegGener restarted for earthquake segments

I restarted the SegGener monitor pursuant to the work order submitted by Dave Barker last Friday. This will update the SegGener configuration to generate Earthquake mode analysis segments once the necessary channels are available from the frame broadcaster.

LVEA transitioning to LASER SAFE

Peter is transitioning the LVEA to LASER SAFE

This is under work permit #8298.

Evaluating Space to Around BSC Pier for Drilling Holes for the NCAL

[Bubba Gateley, Jeff Kissel, Calum Torrie, Krishna Venkateswara, Eddie Sanchez, Rich Savage, Timesh Mistry]

This is a delay post from last week.

Rick and I went down to EX end station with a tape measure to see how much room there was to physically do the drilling. All the photos ca be found in the DCC G1901341 entry. The key photos will be attached here.

We notice that we have ~11 inches from the vacuum chamber to the HEPI pier however, there is less space than expected as there is a vacuum flange protruding from the vacuum chamber (first image - DSC_1492.JPG). Also, there is only 4.5 inches of space on the top surface of the BSC pier as a result of the vacuum flange (second image - DSC_1487.JPG).  Moreover, the top surface is not as the CAD drawing depict. Instead of a flush plate with gussets in the corners, there is a square place raised up and welded (third image - DSC_1500.JPG). In addition, there are 2 extra steel plates on the sides of the BSC pier that are untreated (not painted) that are not present in the CAD drawings this extra room is required in the NCAL mount to accommodate for this (fourth image - DSC_1482.JPG) this, increasing the thickness of the side wall that we have to drill though. The weld due to the side plates will interfere with the current proposed positions for the NCAL mount (fifth image - DSC_1498.JPG and sixth image - DSC_1478.JPG).

We have also found that the 90 degree angled drill we inteded to use will not be suitable for this job as it is a snug fit to get the drill into the space, without any drill bits in it. We will order a lower profile drill that will be capable of drilling into the mild steel pier.