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.

(Alexa, Keita).

We measured the green beam power at several points along the ISCTEY table; notably we have a lot less power into the chamber then we do at EX:

• Upstream of the first faraday: 21mW
• Out of the first faraday: 19mW
• Towards the chamber downstream of the first PZT: 15mW
• Towards the chamber, before the sample/pick off: 15mW
• Towards the chamber, after the pick off before the periscope: 13mW
• Return beam after the pick off (toward TCS), first and second beam included: 0.9mW

Serial # S1300240, chn 4 Dual PD amp, U5B AD284 replaced.

For the past week the IMC ODC has been reporting bad times (this problem started last tuesday) due to the WFS gain being lower than expected. You can see ODC plots on the LHO summary pages (https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/) or more specifically at https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20140421/imc/odc/

H1:IMC-WFS_GAIN is set to 0.25, while the ODC is requiring == 1. Previously this gain had always been 0 (off) or 1 (on), so if a different value is going to be commonly used, we can adapt the ODC to match. 

The h1guardian0 computer appeared to have run out of all memory, logging in remotely was impossible, and logging in to the console was difficult.  No commands could be run on the console, with insufficient memory messages.  So I rebooted the computer.  

I do not know if any processes need to be started by hand to get guardian to run.  The computer is now working again.

model restarts logged for Sun 20/Apr/2014
2014_04_20 12:00 h1hpiham2
2014_04_20 12:01 h1hpiham3
2014_04_20 12:27 h1suspr3
2014_04_20 12:29 h1suspr3
2014_04_20 12:30 h1sussr3
2014_04_20 13:32 h1susmc1
2014_04_20 13:39 h1susmc2
2014_04_20 13:41 h1susmc3
2014_04_20 13:46 h1susprm
2014_04_20 13:51 h1suspr2
2014_04_20 14:16 h1suspr2
2014_04_20 14:22 h1sussr2
2014_04_20 14:28 h1sussrm
2014_04_20 14:41 h1susomc
2014_04_20 15:44 h1susim
2014_04_20 16:14 h1sushtts
2014_04_20 16:31 h1broadcast0
2014_04_20 16:31 h1dc0
2014_04_20 16:31 h1fw0
2014_04_20 16:31 h1fw1
2014_04_20 16:31 h1nds0
2014_04_20 16:31 h1nds1
2014_04_20 16:34 h1susim

no unexpected restarts. Another busy software development day followed by a daq restart.

Overview still shows DAQ problem with HEPI BS and ETMY, perhaps those models require a DAQ reconfigure?

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.

The chillers at all stations produce seismic noise in the 5 to 25 Hz band because of turbulence in the pipes. The chillers can be the dominant source of seismic noise in their band. The chiller signal at EY tends to be peaked at 9 Hz (e.g. here), while the chiller signal at the LVEA and EX tend to be broader band, between 10 and 25 Hz (e.g. here). Studies have shown that the seismic level can be reduced by reducing the chiller pump speed (same links). For this purpose we have installed variable frequency drives at several pumps so that we can run them at reduced frequencies (typically around 35-45 Hz instead of 60 Hz). The chiller turbulence frequencies overlap with one of the most troubling resonances in the seismic isolation system, at about 10 Hz, so it is likely that we will want these VFDs on both pumps at the end stations.

The chiller turbulence does not bear primary responsibility for the recent unusually sharp peak at just above 10 Hz that is troubling SEI commissioners at Y-end, but it makes sense to try and reduce the background for them. With this in mind John and I have upped the pressure in the chilled water lines at both end stations and I have set the VFDs properly. The Y-end VFD pump is not yet being used because I could not get the chiller to start remotely, but I hope John and Ski can get this started Monday.

The figure shows the results of the changes we made at the other end station, X-end. A week of minute trends for the 10-30 Hz band is shown. Notice the regular spikes in quiet periods prior to the 4^th day. These have a 40 minute period, correlating with the cycling of the temperature control valve. We attempted to reduce them by increasing coolant pressure at the beginning of the 4^th day. This seems to have worked, but there is a short resurgence at the beginning of the 5^th day. My switch to VFD on the 6^th day is likely responsible for the significant drop in the quiet-time background after that.

I record the keying instructions for the VFD changes I made because the manual, like at least some other Mitsubishi manuals, is extremely poor (e.g. some keys are labeled differently on the controller than in the manual).

1) Set Pr. 79 operation mode to 3 (combined operation, external and hand). This mode allows external on/off and hand unit setting of frequency. 

Switch below controller OFF, PrSET, 79, READ, 3, WRITE

2) Set the minimum frequency to 30 Hz

HAND, PrSET, down arrow to Pr.LIST, READ, down arrow to Min.F1, READ, 30, WRITE

3) Set the run frequency to 35 Hz

HAND, 35, WRITE

Robert S. John W.

Summary: moving both red and green beams to a single periscope seems to have greatly reduced the periscope contribution to the RMS. In HIFO-Y the contribution was about 7 Hz while in HIFO-X, after the move, it is roughly 0.5 Hz. About half of the current HIFO-X periscope peak contribution comes from the periscope on ISCT1 (65-75, 95-105 Hz in the spectrum) with the rest coming from the periscope inside HAM1 (the 68 Hz sharp peak). The forest of peaks between 250 and 700 Hz come from optic supports along the beam paths on ISCT1.

I investigated vibrational noise in the current HIFO-X spectrum. Figure 1 shows coherence between H1:LSC-REFL_SERVO_SLOW_OUT_DQ and the environmental sensors with the most coherence, accelerometers on the ISCTEX table at EX, and the PSL and ISCT1 periscopes at the corner station. Vibration is the source of most of the signal 60 - 900 Hz, and may also become dominant at lower frequencies as other noise sources are reduced. Of course vibrational levels in the region around 100 Hz are now roughly a factor of two or three above what we hope they will be in science mode.

I tap tested ISCT1 while the arm was locked to confirm that the broad peaks in the HIFO-X spectrum at 65-75 Hz and 95-105 Hz were due to the ISCT1 red/green periscope. They do not closely follow the shape of the periscope peak in the accelerometer on the periscope (Figure 1), probably because the features in the HIFO-X spectrum are produced by differences in periscope motion along the red and green path, not total motion. Tap testing also showed that the forest of peaks between 250 and 700 Hz is mainly due to individual optic supports along the red and green paths on ISCT1.

Tap testing did not excite the sharp 68 Hz peak that sits on top of the ISCT1 periscope peaks. Figure 2 shows that I was instead able to excite it with a frequency-sweeping shaker on a blue cross beam of HAM1. The lower plot in Figure 2 shows that the shaker could not have been exciting HAM2 or ISCT1 enough to produce the peak, supporting the conclusion that the peak is due to motion inside HAM1. A very likely source of the 68 Hz peak is the tall periscope inside HAM1 (shown in Figure 3) used to direct the beams to the red/green periscope on ISCT1. Other optic supports in HAM1 should have much higher frequencies.

Moving the two beams onto a single periscope, suggested by Stefan, seems to have worked very well. In HIFO-Y the red and the green ISCT1 periscopes added about 7 Hz to the HIFO-Y RMS (here). In Shiela’s calibrated H1:LSC-REFLBIAS_OUT spectrum, with the calibration thought to be good to a factor of a couple at this frequency, the 65-75, 95-105 Hz portion of the ISCT1 periscope peak adds about 0.20 Hz to the RMS. The 68 Hz HAM1 periscope peak adds about 0.17 Hz (it added a lot more before the clean room was turned off).