Find attached the watchdogs trips summary of last week/beginning of this week. We'll discuss about it during the SEI portion of the testing meeting today.

Stefan, Sheila

After locking the Xarm (we turned on the opLev damping, and slowed down the gain ramping in the guardian for the ALS COMM ). We aligned the IR to the X arm using IM4 and PR2.  Then we tweaked to BS alignment, and saw flashes of up to 350 counts on ASC_Y_TR_A_SUM.

We went out to the Y end to try to aling the beam onto the camera and LSC PD, but we didn't see the beam while the cavity was flashing and we notied that we still need power to the analog camera on the table. 

We came back to the corner and looked at the separation of the green beams on ISCT1; right before the prism they are separated by 9 mm. They were well placed on the prism as we found them. 

We currently have both the X and Y transmitted beams on the ISCT1 camera, and have marked both of their current positions on the monitor in the control room.  Tomorow we can use this as a reference for the BS alignment. 

(Keita, Alexa)

We adjusted the phase shifter delay line to 20ns. We optimized this by looking at the X-Y plot of the demod IMON error signal and the PD DC readout (see first picture).

With this phase, and the following common mode board settings, we took an open loop transfer function of the PDH:

• Input 1 gain: -14dB
• Input 1 pol: POS
• Common comp: ON
• Boost 1 stage: ON
• Boost 2 stage: ON
• Fast gain: ON
• Fast pol: POS
• Slow opt: enabled

The OLTF gave a UGF of about 5.6kHz with a phase margin of about 20 deg. I have attached a picture and the data (119 --> mag, 120 --> phase). However, this was not exactly reproducible as the lock kept dropping and the alignment was drifting.

We pulled the PDH common mode board SN S1102632 to make adjustments to the second boost stage as made for EX (see alog 9357). We also pulled the generic interface for the ISC tables (D1002932) SN S1103811 since two out of the four ±12V DC output were not working. Both these units are currently in the EE shop.

We also found a bad connection between the phase modulation panel on ISCTEY and the pockel cell. We reconnected the cable and this seemed to help. We measured the EOM RF power, and found 240mV RMS.

Attached is a spectra of ITMY and ETMY optical lever with ISI blends in two different configurations : 

BLUE : Tbetter on both stages and for every DOF (except for Ry which stayed on Tcrappy)
PINK : Tcrappy on both stages

The sensor correction on stage 1 was running during the measurement for both ISIs.

There is no major difference in the YAW spectra (bottom two plots) since Ry stays in Tcrappy, but the difference can be clearly seen in Pitch (top two plots). Tcrappy improves the microseism (~.1Hz) but gives less attenuation at the sus resonance frequencies (~.5Hz).

J. Kissel, for S. Dwyer, J. Rollins, D. Barker, A. Pele, J. Batch, H. Radkins, D. Sigg, K. Kawabe, S. Ballmer

Several things went down at the same time during my melee with the front-ends yesterday (see LHO aLOG 11464), with little indication of the problem, which gave us a proper Monday morning adventure. 

After much digging we think we've uncovered the time-line of how things went bad:
(1) 2014-04-20 18:51 UTC (Sunday, 11:51 PDT) Kissel requests IMC Guardian to enter DOWN state, MC REFL Camera loses signal. Unclear what this did, but the guardian does not touch any alignment signals #foreshadowing. This is very shortly after I post the "I'm getting started" LHO aLOG 11463.

(2) 2014-04-20 20:40 UTC (Sunday, 01:40p PDT) After two successful front-end model install/restarts (PR3 and MC1), the install/restart of MC3 causes h1sush2a front-end computer's IOP throws a FIFO error. This results in the familiar error that drive appears to come out of the user model, but does not get past the IOP out to the real world. (see LHO aLOGs 7385, 8424, 8964)

(3) 2014-04-20 21:38 UTC (Sunday, 02:38p PDT) The guardian computer crashes because it ran out of memory. This rendered all guardians non-functional.

Fixes (in chronological order):
(A) (for 2) 2014-04-21 16:45-17:00 UTC (Monday, 09:45a-10:00a PDT) all h1sush2a user models (h1susmc1, h1susmc3, h1susprm, h1suspr3) killed, h1iopsush2a restarted, all models started
(B) (for 3) 2014-04-21 16:50-18:00 UTC (Monday, 09:50a-11:00a PDT), Jim physically reboots guardian machine, Jamie logs in remotely and fixes things.
(C) (for 1) 2014-04-21 18:25-19:00 UTC (Monday, 01:25p-02:00p PDT) Fix (2) and (3), and *realign MC WFS path* to regain WFS centering and good camera shot.

Detailed Commentary:

(A,2) The FIFO error (2) is frustrating, not only because I still haven't put the error indicator on the SUS screens (totally my fault, accepted), but also because the error indication itself is indicative of two different things: 
- When a USER DACKILL has said "I'm in a bad state, ignore the DAC outputs from my model."
- When the IOP throws a FIFO error.
Maybe other things of which I don't know, as well. 
This is bad because, although hopefully now much more rare, the USER DACKILL trips whenever the USER watchdogs trip to ensure that no drive signal gets out of the USER model's domain. This connection between USER watchdogs and USER DACKILLs was established in the overly-cautious time after the 2012 fiber break, when we weren't sure that stopping the last output (i.e. what the user watchdog does) actually stopped the drive. Perhaps it's time to just remove this layer... 

(B,3) The only information I have about the guardian failure is what you see in LHO aLOG 11470. Hopefully Jamie can give a more complete report in the coming days.

(C) We have NO IDEA why the MC REFL path had changed. Note that Stefan recalls a similar incident in February (see LHO aLOG 10335).
Once we recovered the MC SUS drive, and guardians re-aligned SUS and HEPIs, we spend the usual hour or two convincing ourselves that every drivable object was in the same place:
- The TRANS path showed good behavior. The transmitted light from the mode cleaner looks as it did before, H1:IMC-TRANS_OUTPUT is ~3800 [ct], H1:IMC-IM4_TRANS_SUM_OUTPUT is ~25 [ct], and the splotch on the IMC TRANS camera looks centered and the same. 
- Moving around the PSL PZT only decreases the TRANS signal, indicating that the input pointing is still good.
- SUS are in the same place. All bottom stage OSEMs showed the same locations as before, alignment sliders had correct offsets in place, MC WFS offload values were roughly the same (and small compared to the offsets).
- HEPI were in the same place. Aside from trends of the CPS on both HEPIs and ISIs, we slowly translated HEPI in X and Y, which moved BOTH REFL and TRANS camera signals, indicating the REFL change is not common to both signals. 
- Sheila locked up the X arm to get a straight-shot to PR3, which bounces off of PR3, through PR2, then back to HAM1 and onto ISCT1. Since the beam is large on PR3, its also quite sensitive to HAM2's alignment. The green remained aligned on PDs in ISCT1.
Given that there's *no* active steering between MC1 and the REFL WFS / Camera, we just don't understand how a reboot of any computer would change this paths alignment. The best theory is that there's a loose optic in the path on HAM2, which gets jostled during a HEPI / ISI trip/reboot. Conscious of shaking more important things, I always ramp down the control and offsets the ISIs and HEPIs before doing model restarts, but ... like I said, it's all we've got.
Sarah would be proud.

More great progress was made on the assembly of 3IFO actuators. Scotty and I should be able to finish with the assemblies tomorrow. I was also able to get some ICS time in today.

All VEAs in laser Hazard today

859 Moderate dust alarm in HAM 5 cleanroom (Karen mopping)

900  David, Matt, Aidan, TVO working on TCSX

950 Jim Batch power cycles the guardian server which had hung up

1030 Gerardo working in H2 enclosure

1052 Betsy et al working in West Bay

1059 Patrick removing two ALS channels from conlog

1140 Corey, Sheila and Justin doing laser safety walkthrough in HAM 6 bay (Squeezer Bay)

1145 Justin misaligned ITMY via guardian per Sheila request

1200 Justin reset local alarm on dustmon5 which had been pinging all morning

1305 Fil and Aaron working on ESD cabling at EX...will be cautious around chamber

1300 TCS crew back at it

1338 Corey compiling equipment in HAM6 bay in anticipation of WP4582

This log expands on LHO alog 11342. The intention is to completely damp out the first two coupled longitudinal and pitch modes of the quad to make the cavity lock more robust. Full state feedback is advantageous in that you can specify how much damping you want the controller to give you, and it just gives you that controller. In this case, I asked for a Q of 0.67 on the ~0.5 Hz is long-pitch modes. The controller is obtained using the MATLAB 'place' function.

Previously, in log 11342 I did very little to optimize the noise performance. In this case I improved the 10 Hz noise performance by 3 orders of magnitude without comprising the amplification of the ~0.5 Hz long-pitch modes. This was done by designing the estimator with the MATLAB LQR algorithm in the frequency domain (ref T1300301). An estimator is needed because full state feedback requires knowledge of all stages of the pendulum.

See the attached plots in the pdf. The first page shows a transfer function from longitudinal motion of the quad's suspension point to test mass pitch. The second page shows an impulse response of the same input and output. The 3rd page shows the expected OSEM sensor contribution to the cavity from both the longitudinal and pitch OSEM noise. In all cases the bright green curve is a simulation with the currently installed damping filters, the red curve is full state feedback as given by LHO log 11342, the blue curve is the new response with the optimized estimator. Note that the 10 Hz noise in the new design is only about a factor of two from the 1e-20 m/sqrt(Hz) 10 Hz technical noise requirement.

The jpg figure shows the weight applied to the optimized estimator for trusting OSEM signals. Small weight means we trust the OSEMs (for useful damping), high weight means we don't trust them (for filtering the noise).


The limitations of this design, like the previous full state feedback design, are that the OSEM noise below 5 Hz is really bad, it is not AC coupled, it is not unconditionally stable (goes unstable if you ramp it off/on), and implementing it would require modifying the frontend simulink model. It might be possible to reduce the < 5 Hz noise with a global damping approach to this. Hard to say without more study since much of the noise is from pitch, not longitudinal. Many of the other limitations likely have some workarounds. For example (thinking out load here) making the 'plant' AC coupled with a pre-filter and controlling that lumped system; perhaps switching between damping schemes instantaneously does not cause much of a disturbance if both are AC coupled.

I've got a 3rd IFO Prometheus laser set up in the Squeezer Bay on the ISCT6 Table [per WP 4582].  I'll use this laser to look at green & IR late through different filters with our GigE Cameras (filters are scheduled to arrive tomorrow).  So, I worked on getting set-up today.

Unfortunately, I could not use the camera.  Since we don't have a CDS Network Cable for the cameras running down to the Squeezer area, I was going to power/view a camera locally on something called a PC.  This PC thing unfortunately would not boot (after many attempts); granted it is old.  So, I'll have to wait to see if Jonathan can dust the cobwebs off another PC, or I can install Windows on my old Mac via a Virtual Machine---the software for the Basler GigE Cameras require Windows.

This one was my fault, I tried turning off the RZ isolation. 

Sheila, logged in as alexa

Thomas and I made changes to the OPS medm overview. Sheila noticed this morning that the BSC-ISI indicators can still be "green" if stage 1 is isolated but stage 2 is tripped---I inserted a second level of indicators to the five ISI chambers that should flash red if either Stage 1 or Stage 2 WD is tripped (also goes red if Master Switch is active, or if either the SUS or frontend DACKILL is tripped).

Laser Status: 
SysStat is good
Output power is 27.5 W (should be around 30 W)
FRONTEND WATCH is tripped 
HPO WATCH is tripped

PMC:
It has been locked  1 h 40 minutes (should be days/weeks)
Reflected power is 1.4 Watts  and PowerSum = 11.3 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 31 min (should be days/weeks)
Threshold on transmitted photo-detector PD = 0.64 V (should be 0.9V)

ISS:
The diffracted power is around 7.4 % (should be 5-15%)
Last saturation event was 1 h and 24 minutes ago (should be days/weeks)

I removed the following two channels from conlog:

H1:ALS-Y_LASER_HEAD_CRYSTALFREQUENCY
H1:ALS-Y_LASER_HEAD_CRYSTALTEMPERATURE

These are constantly servo-ed by a script and are changing around 357,988 times an hour.

To remove these I added them to '/ligo/lho/data/conlog/h1/input_pv_list/exclude.txt'. I then ran '/ligo/lho/data/conlog/h1/input_pv_list/create_pv_list.bsh'. This was a mistake, because there were also changes to the autoBurt.req files that I did not want to incorporate until tomorrow (Tuesday maintenance). So instead of updating conlog with the pv list made by this script, I told it to subtract the channels in '/ligo/lho/data/conlog/h1/input_pv_list/exclude.txt'.

I then had it write the list of monitored channels to '/ligo/lho/data/conlog/h1/output_pv_list/monitored_pv_list_2014apr21-11_06.txt'.

There are currently:
122,672 total channels
116,438 monitored channels
6,234 unmonitored channels

Done for the moment. 

===

1. First plot shows how the mode matching is bad now

I thought I've improved it, but it turns out that it's not much.

Green is forward going beam (going to the chamber) picked off right after Faraday, red is the beam coming back rejected by Faraday. The overlap is 0.63.

This doesn't mean that the matching to the arm is 0.63, it  could be better by about a factor of 4 i.e. 1-(1-0.63)/4 = 0.91, and it could also be much worse than 0.63, but we already know that the matching to the arm is somewhat less than 1750/(1750+250)=0.88.

It was worse when I started (overlap 0.58). But this doesn't necessarily mean that the matching to the arm is better, either.

z=0 corresponds to the steering mirror downstream of the BS that separates WFS and PDH beam.

===

2. Second and third plot show the beam propagation in the far firled WFS path when the first lens (L6) is placed 3in farther than the nominal position.

Jax's Gouy telescope design (which is a copy of Bram's) is that the near field telescope doesn't do much to the Gouy phase (except that it blows up the beam size). In the far field path, one lens makes a reasonable waist that is not too small so that the Gouy phase doesn't change rapidly, and place a second lens to blow up the beam at a pre-calculated position near the waist.

Since the actual beam parameter shown in 2. above is so much different from the design, placing things at a nominal location  we need a path length of like 4 or 5m, which is not practical. I moved the first lens 3" downstream, and obtained the 3rd and 4th plot. Note that the agreement of the upstream and downstream measurement is very good. Measurements downstream of the first lens (shown as crosses) come on top of the lines that are the fit of the upstream measurements (circles) fit to Gaussian and propagated through the lens.

The waist size is about right, but I decided that it's difficult to fit this on table without totally ruining the area reserved for Hartman sensor.

===

3. Final (for now) FF WFS path = WFSB. Moved the lens again by 3" (4th and 5th plot)

So it's 6" downstream of the nominal design. I haven't measured the downstream points this time, as the downstream measurements agreed with upstream quite well in the previous step.  L7 is placed 65" downstream of L5. WFSB position is not important at all as far as the beam size is reasonable.

===

4. NF path=WFSA (6th and 7th plot)

===

5. z coordinate and distances:

• Steering mirror downstream of PDH-WFS splitter: z=0
• WFSA-WFSB splitter: z=12.5
• WFSA (NF)  path:
  • L5 (f=0.5):  4" downstream of the splitter
  • L5-pico=3.5"
  • pico-L5a=2"
  • L5a-WFSA=5"
• WFSB (FF) path:
  • z(L6) = 25.5"
  • L6-L7=65" (folded once)
  • L7-pico=18.5"
  • pico-WFS2=13.5"

Here is the list of commissioning task for the next 7-14 days:

Blue team (Y-arm):

• Establish green cavity locking.
• Find best alignment in corner for both red and green.
• Look at separation of the two green transmitted beams.
• PDH transfer function/noise measurements/model.
• Test WFS cabling.

Green team (X-arm):

• Noise hunting.
• Investigate power/gain dependence of COMM PLL PD.
• Revisit the WFS with the now improved beam quality.
• Look for clipping in green transmission.
• Make a mode scan of the red higher order modes.

Red team:

• Center the red QPDs in EX.

SEI/SUS team:

• Change UIM drive strength in EX/EY.
• Commission EX ESD drive.
• Commission high bandwidth length drive to SUS/ESD.

Since Saturday the DAQ data from HPI BS and ETMY was out of sync between FE and DAQ and therefore suspect.

I performed a manual "DAQ Reload" from the GDS_TP MEDM screen for h1hpibs and h1hpietmy 10:24PDT.

Arm and BS were realigned. Beam was found in ISCT1 again. 00 Transmission was about 1750 counts, 20 was about 250 or so (this is just reading the unlocked fringe peaks). Tried to lock it but we were hit by another  big EQ which made it impossible to do anything meaningful.