We finished welding ETMY on Friday evening. It was hanging with about 5 or 6 mrad of differential pitch wrt the PUM. It was left hanging over the weekend. When we looked at it this morning, two fibres had broken and the other two were lying against one of the earthquake stop rails. All the horns and stock were still intact. We scribed off the stock from all 8 horns and filed them back to 6mm above the ears. Work is ongoing to clean up the remains of the two shattered fibres and to pull enough fibres to allow welding again first thing in the New Year.
Angus, Travis & Betsy

[Arnaud, Kiwamu, Keita]

After HEPI work earlier, BS was restored using oplev.

POP beam yet to be found. PRY alignmnent was restored, PRY was locked, but couldn't see anything on MC tube baffle. Thinking that the beam is already clearing the baffle hole, we went to ISCT1 but couldn't find the beam (actually there was some beam but it didn't move when we misalign ITMY). We might have to go 10W before we can find anything.

PRY alignment is dubious. When PRY locks, the beam look low on BS AND ITMY. When we set the beam height on ITMY using ITMY video image, BS beam position came up and looked OK-ish (maybe still low). However, with this new alignment, we couldn't steer ITMY enough to re-establish the PRY cavity as F3 BOSEM output railed.

PRX scanning efforts.  With PRY path aligned (to dubious alignment) and then ITMY misaligned, we scanned ITMX to see if we can see PRX cavity flash, but we weren't successful. We will set PR3 angle such that the beam hits the center of ITMY and scan ITMX tonight.

ITMX oplev is dubious. When we scanned ITMX, OSEMs (M0, L1 and L2) responded nicely but we got nothing from oplev.

ITMX camera should be zoomed out if possible. We cannot see any beam on the ITMX camera, but it's mostly looking at ITMX face.

Today, I found that we hadn't retored the BS and ITMY HEPIs back to the HIFO alignment. So I restored them back to the position of July 25th.

BS HEPI:

Local sensors needed to be as follows in order to get back to the HIFO alignment:

• H1 = -9000
• H2 = -11650
• H3 = 220
• H4 = 6900
• V1 = -14800
• V2 = -12300
• V3 = -14200
• V4 = -14000

I newly set the Cartesian targets (i.e. H1:HPI-BS_IPS_X_TARGET  and etc.) to be:

• X = 127911.0
• Y = 380717.0
• Z = -536093.0
• RX = 15438.9
• RY = 32281.4
• RZ = 7990.8
• HP = -524654.0
• VP = 104698.0

ITMY HEPI:

Local sensors needed to be:

• H1 = 15
• H2 = 25
• H3 = -30
• H4 = -50
• V1 = 85
• V2 = 60
• V3 = 120
• V4 = 20

I newly set the Cartesian targets to be:

• X = -205.7
• Y = -822.6
• Z = 2762.9
• RX = 33.5
• RY = 502.2
• RZ = -47.3
• HP = -1551.1
• VP = -4847.1

In preparation for tomorrows RCG upgrade from tag-2.8 to tag-2.8.2 I have created a build area for tag-2.8.2. All release pointers now refer to 2.8.2.

I have pre-compiled all user models against tag-2.8.2. All models compiled except for h1susim and h1sushtts, which were expected to fail. These two systems will stay back at 2.8.

I ran the systems through my slow channel configuration checker script (/opt/rtcds/userapps/release/cds/common/scripts/slow_chan_config_checker.py) and they all passed. This means there no mismatches between the slow channel order defined on the front end and that used by the DAQ via the model's INI file.

Tomorrow morning we will do the final make-install and restart all models. (h1susim and h1sushtts will be restarted but will run the 2.8 code).

This will give us another data point in how quickly the PSL recovers from a front end shutdown.

The test over the weekend of turning off the cleanroom after running the ALS alignment servos for a while is kind of inconclusive.  the attached plot shows PZT outputs over the weekend.  The red arrow indicates the time when the cleanroom was turned off, you can see a small blip in the alignment servos, but it is small compared to the normal drift in the servos.  However, the plots attached to alog https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=7146 show similar drifts in the PZT aligment, even before the cleanroom was turned off.

One problem with the test we just did is that the green wasn't on the PD when we started, we can try this again after realigning if we need to.

Kyle opened GV1 (WP 4344)
Sheila removed two beamsplitters from the H1 PSL table
Thomas and Kiwamu aligned the optical levers at ITMX and ITMY
Dust monitor 9 dropping in and out of communication

09:09 Filiberto installing analog camera for ITMX (WP 4343)
10:10 Corey to end X to add sign to lab door
10:10 Jim B. labeling IO chassis in CER
10:25 Jim B., Jeff K. restarting h1seih23 models and IOP
11:33 Kyle done opening GV1
12:02 cardboard container pickup
12:43 Filiberto, Louis cleaning up cabling by HAM 4
13:03 - 13:09 Jim B. labeling cables for h1seib3
13:21 Jeff B. and Andres looking for parts near the LVEA test stand
13:40 Richard to end X to look at pressure gauge
13:56 cardboard container dropoff
14:12 Jeff B. and Andres done
15:13 Corey to squeezer bay to put away parts

Tom V. and others needed GV1 open -> New combined volume pumped only by XBM turbo -> GV5 left soft-closed -> Demonstrated XBM turbo safety valve closes when foreline measured value is above setpoint

KiwamuI, ThomasV

We aligned ITMX and ITMY optical levers to the position of the test masses at approximately 2013-12-16 12:00 PT. We may need to adjust the alignment if the pointing changes due to commissioning activities. 

We've been pumping on the vacuum jacket of the CP3 LN2 dewar. This morning the pressures are 2.8 e-3 torr at the scroll pump inlet and 7 microns at the TC gauge. Back in November the pressure was ~700 microns at the TC gauge.

I changed the IMC locking thresholds because the incident laser power was increased from 300 mW to 1W.

• Boost trigger was increased from 200 to 800 counts.
• The LSC low pass filter trigger was increased to 3000 counts.

It's locking fine.
 

Chris, Kiwamu, Sheila

On friday night, we added IPC receive parts to the h1susprm and h1suspr2 models for ISC-L, ASC_PIT, and ASC_YAW.  

There were already place holders in the model and IPC send parts in the LSC and ASC models , and everything went smoothly.

Since Kiwamu had issues locking the power recycling cavity using M3 actuation of PRM, I ran a quick dtt tf on middle and lowest stage of PRM in one dof (L) to check for any actuation issues. Both stages look ok (cf attachements), so I'm not sure where the problem could come from.

J. Kissel, J. Batch, H. Radkins, H. Paris

We discovered this morning that HAM2&HAM3 ISIs and HPIs (run on the h1seih23 [computer /  I/O chassis]) were not sending drive signals out to the chambers even though 
- Drive was requested
- The ISI & HPI overview screens indicated the ability to drive (Watchdogs all green, master switch on, "you can drive" border all green)
- The user model FEC state words were all green
- The user model GDS_TP DAC bits were all green

It turns out the only indication of badness is on the FEC STATE WORD of the IOP (in this case H1:FEC-53_STATE_WORD) -- the 8th bit (or 7th if you count from 0), marked "WD" on the CDS_OVERVIEW screen, which is a mislabeled bit representing the "DAC ENABLE" function, which can be triggered by several things other than watchdogs. A minute trend of this bit shows that it has been triggered since Dec 15th 2013 12:51 PST, 2013-12-15 20:51 UTC, 1071175876

Hugo informs me that this symptom has been seen before (I'm sure there are aLOGs, but they'd be written by four different people, each, like me, unsure of how to explain the problem exactly, and probably tagging it with different tasks or use different buzzwords), but the cause is unknown.

Jim had initially suspected the the IOP's FIFO buffer had somehow been emptied, which would cause this bit to go bad, but after looking at the front-end's log, by doing
controls@opsws3:~ 0$ ssh h1seih23
controls@h1seih23:~ 0$ dmesg
where he expected to see some error from the h1iopseih23 process indicating this fact, but no obvious error was reported.

As with all problems like this, we rebooted all front end processes and it cleared the problem and actuation ability has been restored, but the root cause remains a mystery.

@DetChar: can you take a look? If anything just to narrow down exactly when the IOP bit failed *this time*, but maybe get a long history of he channel to see how often this happens, if it only happens on this front end or if it happens on other front ends, etc. etc.

@SEI: Y'all should include the STATE WORD for the user model and the IOP on your overview screen, and include this DAC ENABLE bit in your logic for computing the "you can drive" border.

I removed the two beam splitters on the PSL table installed for the faraday isolation measurement, so that we can use more power to search for the POP beam.  After removing both there was no noticable change in alingment on irises on the PSL, so I did not adjust the alingment at all.  I also rotated the half wave plate which will soon be in the motorized stage, so that there is now 0.95W incident on the bottom periscope mirror.  These powers were measured with the PD300-3W power meter head with the filter on. 

This means there is 0.76mW transmitted through the bottom periscope mirror (measured with filter off) , and 59uW transmitted by IO AB BS1.  I powered up the PD that was placed after IO_AB_M12, which was saturated with this power so I moved it to the location of IO_AB_PD2 in the drawing, where there are 16uW incident on it now, resulting in -4.96V.  With the beam blocked this PD has a 60mV offset.  This is a PDA55. 

I also removed the lens, PD, beamsplitter and beam dumps that were used with the two beamsplitters for the farday measurement, I put all the components in the IO cabinet in the anteroom.  This unblocked the PATH from IO_MB_WG1, this path seems to be aligned onto  IO_AB_PD1 already.

I also unblocked the ALS path.  

J. Kissel

Though folks found a temporary solution that worked for the time being while I was off-site last week (see LHO aLOG 8894 and LHO aLOGs 8901), I wanted to try sixteen more ways arranging signals in the h1susim.mdl and/or h1sushtts.mdl front-end simulink models to get what I want out of the calibrated, Cartesian ISI GS-13 signals projected to each optic's EULER basis. Still no dice. Gosh darn it.

I attach to pages of pdf. These are cartoon mimicry of the top level of a given suspension type's front-end Simulink model. I drew the cartoon so you can see a simplified view of the important parts for this discussion, and you can see into the subsystem blocks.

Pg 1 -- a cartoon of what every other suspension type (which only have one optic per model) has. Note, that here, goto/from tags and bus creators/selectors are used going straight from the IPC blocks at the top level, and skipping down two levels (both of which are separate library parts) to a cdsFilt bank. We've been told that skipping levels like this shouldn't work. But it has and does, in this configuration.

Pg 2 -- a cartoon of what I *want* to do with the HSSS, which have many suspensions per model. Here, I send the GS13 signals into a (non-library) subsystem named after the suspension type (HTTS or IM), and calibrate the GS13s once. Yes, I skip a level, but if pg 1 works, so should this. Also, the subsystem in the (HTTS or IM) block has an underscore in the block name -- trying to preserve the channel name format across sus types -- so maybe this is fooling the RCG. From there, the calibrated signal is sent up and out to the top level again, sent to the common HSSS_MASTER block renamed to reflect each of the optics in the model.

As drawn, the model doesn't compile, complaining that just about every bus selectors is not connected.

Where you see roman numerals in double square braces, e.g. [[ii]], I've tried inserting 
- dummy epicsOutputs
- Simulink gains of 1.0
- Test points
- Terminators and Grounds
and can only get it to compile in something equivalent to the temporary configuration where the IPC is fed directly to the HSSS_MASTER.mdl block. 

Very frustrating.

After an initial assessment that stated "not too bad, not too good" (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=8919), which was based on just two data points (beam radius on WFSs), I added the third point further downstream of the WFS2 and it turns out that actually it's excellent.

In the attached plot, blue circles represent the measured beam width, blue crosses on both sides of blue circle represent the potential position error (Jamie claims +-1cm though probably it's too generous), red line is a fit over the three points, green is the curve generated by the design parameters.

As you can see, in both horizontal and vertical direction, the waist is very close to the middle of the WFSs, and the waist radius is very close to the designed 250um.  Gouy separation for X (horizontal) and Y (vertical) are 82.6 and 87.1 degrees, respectively.

This was obtained from just two iterations of measurming at WFS1 and WFS2 and pushing RM2 toward RM1 based on the measurement. Downstream was measured just once after we were satisfied with WFS1 and WFS2.

Distance from RM3 to the first lens on the sled is, according to Jamie, between 48.0 and 48.25 inches.

Also, as noted earlier, the above data was obtained after having moved RM2 toward RM1 by 22.5mm. Everything else is the same as what Sheila reported much earlier.

We also measured at one point between RM3 and the sled (14.5" downstream of RM3).  Together with upstream number measured yesterday (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=8893), these are:

In all of the above measurements, "Profile averages" was 10, "Rolling profile Averages" was 3, the actual number of measuremets (i.e. the number of scans performed before I stopped the measurement) were larger than 10 but I don't know if the software was taking more than 10 points into the statistics or not.