Sheila, Lisa 


Since we had lost good alignment references, and the sub-optimal IR alignment was what limited the build up in the  last full lock attempts , we decided to invest sometime working on the initial alignment procedure.

As already known, achieving a good alignment for both IR and green is easy for the X arm, but kind of tricky for the Y arm.

So, after Sheila aligned both green and IR to the X arm, we decided to commission the IR lock to the Y arm (feeding back the REFL IR signal to the MC length) with the idea that this step will become part of a future automatic alignment procedure to ensure the IR is well aligned to Y. As observed for the X arm, because of the  27 Hz and 41 Hz MC2 resonances , achieving a stable IR lock feeding back to the MC is indeed painful. We eventually succeeded by re-designing the loop so that we could keep the 41 Hz notch in the MC path always on. Phase and gain margins are not great, but this worked well enough that we could keep the cavity stably locked while optimizing BS, ITMY and ETMY so as to reach maximum build-up for IR (1 in LSC-TRY). 

At that point we used TMSY and the green QPDs offsets to recover some green build up, and we could relock the cavity on green; with both cavities locked at the same time we could find a way to keep maximum build-up for IR, and achieve 0.7 for green. Not fantastic, but probably not too bad; Keita's green WFSs will hopefully make the green alignment better.

Happy with the IR in the arms we went back to PRMI. The PRM alignment was totally off (about 15 urad both PIT and YAW); Sheila patiently brought it back, and we could relock the PRMI stably on 1f sidebands. 

We leave the IFO with the green arms locked for Keita tomorrow.

First, yesterday we had a WFS interface cable that would short circuit -100V bias to the ground. A new cable was put in (or maybe the old one was fixed), and today I restarted WFSY-ing.

I immediately noticed that WFS whitening binary IO readback doesn't agree with the output I intended to send, for all four BIO cables.

Upon looking at the whitening chassis, I've noticed that +15V power indicator LED was really dim for WFSA whitening (first picture), but when I removed the second BIO cable from the WFSA whitening chassis the LED got bright again (second picture). But that didn't solve the readback problem for that specific cable.

I and Daniel started disconnecting cables from the binary IO output chassis, and immediately the readback got sane again, and we confirmed that BIO chassis is working fine by connecting a BIO tester. As soon as we connected the cables (that connect the BIO chassis to the field rack whitening interfaces) back to the BIO chassis (the othe end of the cable is still disconnected) the readback got mad again, and the madness is somehow dependent on how we strained and wiggled the cables.

We opened the shell of the cables, and were disappointed to find that it seemed to be really easy for the exposed conductor of the flat cable to be pressed against the shell to cause short circuit (third picture).

By removing all 8 shells (four cables both ends), and then connecting the cable back to the BIO output chassis and the whitening chassis, we were able to eliminate the readback problems for most (but not all) of the requested states. This means that most of the short circuits were gone but there are still some that is not related to the short circuiting to the shell.

And the +15V LED of WFSA whitening isn't dim any more.

Anyway, for the moment, short-circuiting between high and low is a problem but not for high-high and low-low, so we decided to find a seemingly good state where the readback don't complain. For both of the WFSs, this is +33dB whitening gain, first two filters on, third filter off.

And then I connected H1:LSC-Y_EXTRA_AO_1_EXC output to the B input of the PDH CM board, locked Y arm on green, injected a sine wave to the CM board and started measuring the demod phase of WFSs. And I noticed that there are huge differences in signal levels for quadrants, and for some quadrants I couldn't make a decent job of minimizing the injected signal in one demod quadrature.

I got suspicious about whitening and measured the dark noise coming into the ADC (4th attachment, bottom), and sure enough, whitening gains seem to be all over the place, and it seems like two channels for WFSB have only one stage of whitening filter engaged. I then found that the readback wouldn't complain at 45dB too, so I repeated the same thing with 45dB whitening gain (top), and it got better for WFSA but not for WFSB. Maybe there's still some cable-related problem though I don't know how, or maybe this is the whitening chassis problem.

The next step would be to go to the floor and look at the whitening chassis. It would also make sense to see if the whitening gain for X arm is OK.

Reading before turning it off, 1.75X10^-05 torr.  CC remained on the entire day.

It is off now.

Took a PET swipe of HAM6 today. This is after the alignment and balance of the suspensions in HAM4 and HAM5 and before the final installation and alignment work in HAM6.

   Examined the ISI and the OMC under flashlight array for particles. There were no visible concentrations of contaminates on the horizontal or vertical surfaces. I wiped down the top of the ISI and the OMC.

   Took several particle counts while working in and around the chamber.

   Highest particle count in cleanroom before cover off: 16 0.3µm, 0 0.5µm, and 0 1.0µm

   Highest particle count in chamber before cover off: 0 for all sizes

   Highest particle count in chamber just after cover off: 203 0.3µm all other counts in the mid teens

   Highest particle counts in chamber just after wipe down with cover on: 790 0.3µm, 420 0.5µm, 200 1.0µm

   Highest particle counts in chamber after 5 minutes with cover on: 80 0.3µm, 30 0.5µm, 20 1.0µm

After some response from the the Cogs, I finalized the balance, cleaned up some of the SRS cables and other spode.  The covers are on and pulled away from the ISI.

HEPI remains locked.

Purge is turned way down.

TFs are underway.

From the logged in controls account on opsws8, because I haven't been able to figure out how to get everything working nicely on my own ops account. No touching, as usual.

This is a temporary setup needed to operate the RGA at BSC8.  These are rack mount crate type units but I have them stacked on the LVEA floor (south side of BSC8).  If these interfere with commissioning tonight, feel free to turn them off.  Otherwise, please them on.  

8:15 – 8:40 Installation Meeting Minutes
8:45-10:13 ESD drive work at EndY – Richard/Filiberto
9:09 – 10:19 Heading to EndY/MidY for cleaning – Karen
9:12- 12:00 ISI work (table balancing) on HAM5 – Hugh
9:27- 11:27 TCS Hartman table work continues – David
9:55- 11:42 Contamination & control activities at HAM6 – Jeff B.
10:25- 12:00 Heading into the LVEA (West bay) Inventyory – Jody
11:12- Going to End Y to work on WFS – Keita
11:53  LVEA transitioned to LASER HAZARD – Justin
12:58- 14:55 Back to LVEA for TCS work – David
13:00- 15:22 Heading to work in LVEA (West bay) – Betsy/Travis
13:45- 15:36 Heading back to HAM5 – Hugh
12:47- Heading to Endy/EndX to intall ESD grounding – Aaron

 LVEA is Laser HAZARD!

The corner whitening filters were not switching, with an error message invalid data chn and readback different for Refl 9 and refl air 9, and for POP we had an error message invalid data for channels 1, 2, 3 and 4. 

Daneil fixed this by going to the system manager for the corner, finding the X gateway under device 1, corner MSR L0, Corner MSR L8_9 Vertex, going to the Online tab, and clicking on several of the buttons under state machine (Init, pre-op, safe op, op) in an order that seemed random to me. 

I am just writing down the solution to this problem so that we can look it up next time it happens.

Jeff B reported that the OSEM speed-dial screens were not working on the QUAD test stand. A bit of poking showed that the sitemap1 alias invoked

/opt/rtcds/tst/x1/userapps/release/cds/x1/medm/X1SITEMAP.adl

The Display File field for the QUAD button on that screen invoked

/opt/rtcds/tst/x1/userapps/release/sus/x1/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl

but the Arguments field included

SUSDIR=/opt/rtcds/tst/x1/cds_user_apps/trunk/sus/common/medm/quad

which references a newer set of files where all the speed-dials have been renamed from SUS_CUST_QUAD_M0_OSEM_ALIGN.adl and the like to SUS_CUST_QUAD_M0_CENTERING.adl etc.

I changed the SUSDIR and it now works. I also had to manually load the safe.snap file to get all the matrix elements and gains filled in.

Removed 106kg from Stage1 including 20kg from Table top.  Wall payload went from 125 to 40kg in addition to removing 2 10kg masses from table top.  Lone table top mass at +X, -Y area gone, viton damping of Table Top masses still to go.

When we balanced the table before any SUS went in, we had 810lbs on the table top (iLIGO & aLIGO stuff.)  This was removed, table top balance mass added per D1001139, SUS adds SRs, OFI, & Baffles.  Not sure what the projected payload was going to be on the table but this indicates it is 302kg.  Sound good?

Anyone care about how the mass distribution has changed?  How about the poor distribution of the Table Top 1075s for damping?

Several questions have come up over which wipes to use, when to use them, and where to use them. This table should clarify and answer these questions:

1. In chamber cleaning
Pre-soaked Vectra Alpha 10
Vectra Alpha 10

2. Glove cleaning
Pre-soaked Vectra Alpha 10
Vectra Alpha 10

3. Gross cleaning - up to and including clean-room walls / outside of chamber
Valutek pre-soaked wipes

4. Daily wipe-down of work surfaces, drying clean parts
Contec PNHS99

5. Back up if out of Vectra Alpha 10 (or have heavy inventory)
Contec PNHS99
    

Kyle noticed that the web MEDM snapshots had stopped when script0 has issues yesterday at 6pm PDT. I have restarted them after the reboot of script0.

Installation Meeting Minutes 

8:15-8:40

Fred, Richard, Aaron, Gerardo, Jeff B, Vern, Bubba, Travis, Hugh, Mitchell, Mike, Arnaud, Thomas, Daniel, David, Corey, etc.


•	Went over Work Permits
•	Work on HAM5 ISI (table balancing) – Hugh
•	BK hammering test on SR3/SRM  suspensions (HAM5) – Arnaud
•	TCS work continues - David
•	Sled getting ready to be moved to HAM6 – Dan/Corey
•	Quad  upper structure work in LVEA (West Bay) – Travis/Betsy
•	ESD driver work at End Y – Richard/Filiberto
•	Staging building activities ongoing – Mitchell/Scott

LVEA is Laser SAFE

Moday and Tuesday, no restarts reported. Maintenance was deferred until the vent.

script0 was not running correctly, we ended up rebooting it via the front panel reset button.

[Sheila Lisa Jeff Arnaud]

Sheila and Lisa were having alignment issues in the X arm this afternoon, in the sense that some fine alignment was always needed after recovering from a lock loss. A good example is shown in the attached screenshot. In that case, diff lost lock, and kicked both etmx and etmy suspensions (top right plot showing the diff error signal in purple). At that point the green transmitted power in the X arm (bottom left plot) dropped to 0, and came back to 0.5 after the test mass settled down (instead of expected 1). This was due to the alignment : comparing the pitch of the test mass with the oplev before and after the event, we see that etmx pitched down by ~1.5urad (left middle plot in green). Neither ISIs HEPIs SUS were tripped during those times, the Ry DC values (corresponding to sus pitch) from ST1 ST2 ISI and HEPI were identical, etmx yaw was identical, itmx pitch and yaw were similar.
Sheila then used itmx (bottom right plot in yellow) to realign the cavity, pitching it by ~1.5urad which was just enough to bring the transmitted power back to 1 (bottom left plot in red).
It would be interesting to know if this is what happens all the time.