Elli, Nutsinee

CO2X laser mysteriously tripped this morning (*probably* due to PEM cable pulling). It untripped itself but the output power was never returned and the temperature kept dropping. We had to go in and restart the laser at the rack. Just wanted to point out that the laser READY status on Ops Overview screen doesn't always mean it's ready. Always keep an eye out for the laser power.

As Daniel noted we plugged in the 1PPS signal from the Trimble timing unit that was installed last week into the Master timing system in the MSR.  This is on Antenna cable 1.
I then moved the Master timing antenna to the weather station mast.  I did not change the cabling as this was already on 1/4" Heliax coax cable and the unit has 3/4" connection which would be hard to make up the the 1/2" heliax and N connector.
We then Moved the NTP server antenna to the weather station mast using antenna cable 2.  We needed to adapt the N connector the TNC at the antenna head.

This completed the intrusive GPS moves. Next will be to connect the Symmetricom GPS unit in the rack to another antenna.  This will done during another maintenance period.

the workstation in the front right corner of the control room doesn't work well, sometimes it stops  working completely, sometimes it is unresponsive for a few minutes then comes back.  

Aidan. Nutsinee

Summary:

The CO2 ITMX ISS AC anti-whitening filters where previously (naively) set up with the complete inverse of the ISS whitening filters in the electronics. This included a pole at zero, or an integrator. This caused problems at LLO when turned on as residual DC in the input to that channel was steadily integrated over time. We fixed this problem at LLO by moving the pole from 0 Hz to 1 Hz. I added the same fix here. Also, these filters were missing from the ITMY channels, so I added them at LHO as well.

Details:

In Foton, I loaded H1TCSCS.TXT and, in the following four channels,

• ITMX_CO2_ISS_IN_AC
• ITMX_CO2_ISS_OUT_AC
• ITMY_CO2_ISS_IN_AC
• ITMY_CO2_ISS_OUT_AC

I set the first three filter modules to:

• gain255 = gain(0.0039)
• HF78344 = zpk([200],[1],0.000013,"n")
• HF152 = zpk([200],[1],0.0066,"n")

The key change being the removal of a pole at zero and the addition of a pole at 1Hz.

After saving the file, I hit "Clear History" and "Load Coefficients" on all four channels.

Additional information:

The ISS AC channels tell us the intensity noise on the CO2 lasers. We're particularly interested in the region 10-200 Hz where we may couple noise into DARM. 

The master GPS clock has been switched from the internal GPS unit of the master/fanout chassis to the external Trimble unit. This simply required to connect the 1PPS ouptut of the new GPS unit to the 1PPS input of the master/fanout chassis. Plot 1 shows that this proceeded with a small 100ns transient in the OCXO error signal but otherwise went smooth without interruption of the timing distribution system.

Plot 2 shows 1 day of second plots trending the difference between the atomic clock and the internal GPS (DIFF_1), the difference between the NTP server and the internal GPS (DIFF_2) and the difference betrween the Trimble and the internal GPS (DIFF_3). The atomic clock was shifted by +1µs and the NTP server by +0.65µs to shift the histograms towards the origin. This measurement was done before the switch over still using the internal GPS as the master. The Trimble unit seems to have about twice the variance compared to the internal GPS and the NTP server. The difference between the Trimble unit and the internal GPS is about 25ns.

J. Kissel, B. Weaver

Betsy and I have updated the end-station SUSAUX top-level models to include Stuart's new library block for the HV and LV ESD analog readback monitors, as per WP 5373, ECR E1400232, II 859.
with the changes as described in LHO aLOG 18819, and obeying wiring diagram D1400177 , specifically p11.

They been compiled against RCG 2.9.5, we'll wait for Dave to confirm that we want 2.9.5 or 2.9.6, and will install later in the morning, as per today's schedule (LHO aLOG 19770).

As a precaution to working on the timing system ALL of the SUS and Seismic systems have been taken down using guardian.  The addition of the 1pps into the timing system should not cause a problem but if it did this should keep equipment from potential issues as a result of the front ends freezing.

Evan, Stefan
- Loops worked - simply lowered DHARD gain by 6dB.
- Had some low frequency transients right after - not clear whether they are related to the matrix - seemed to diminish later on.

Rana, Stefan

Using Rana's filter fitting tool (available in
   /ligo/home/rana.adhikari/Templates/DTT/LSC/FF
   or
   /ligo/home/controls/sballmer/today/FF
we remeasured and fitted the MICH FF transfer function.

The new fitted filter (FF3 in FM4) is
sos(-0.000543835088,   [  -1.93662264300273;   0.95485272408082;   0.30546714694311; -0.69453285305689;
                          -1.99510327713713;   0.99517904131748;  -1.99243149865104;  0.99250763632503;
                          -1.99954772753581;   0.99957826550970;  -1.99936615655289;  0.99939939939844;
                          -1.99965218293192;   0.99975661861859;  -1.99993380253468;  1.00003473727562;
                          -1.99969845455122;   0.99979417820973;  -1.99992371170330;  1.00002274176099;
                          -1.99981093117311;   0.99985759151419;  -1.99995617290421;  1.00000284176776;
                          -1.99985737603421;   0.99996014647150;  -1.99984813627844;  0.99995086001340;
                          -1.99992036795975;   0.99996576562300;  -1.99993708678199;  0.99998253575133;
                          -1.99944212960262;   0.99996998756589;  -1.99944272164552;  0.99997065091132;
                          -1.99975193818562;   0.99999930668374;  -1.99975187384463;  0.99999929435542;  ],"o")

Plot 1 shows the fit quality,
Plot 2 shows the achieved subtraction, with an artificial MICH drive.

Rana, Matt, Hang

We did some further investigation of HAM5's coherence with DARM, as suggested by Gabriele (aLog # 19756). A list of what we did:

05:35:10 (UTC): Tapped the lower middle flange south of HAM5. 
05:35:32 (UTC); Tapped the same flange harder.
05:35:54 (UTC): Tapped gull wing. The interferometer lost lock. Before the unlock, the IFO was operating at 24 W with LSC FF on.

A plot of the corresponded time series was attached (TSaccHam5vsDarm.png). We could see ringing corresponding to tapping the flange in HAM5 channel, yet they did not seem to have a significant effect on DARM.  The frequency of the ringing was 207Hz with a decay time of 1.6s. No 90 Hz feature seen. The gull wing tapping did not appear in the ACC_HAM5_SR1 that Gabriele noted.  Summary: no clear connection between this ACC and DARM.

As previously noted, there is a new fast front end running at EY.  I made a few (bad) screens to help access the filters and RMS outputs.  There is no link from the sitemap yet, so access is via

   /opt/rtcds/userapps/release/isc/h1/medm$ medm -x ISC_PI_START.adl 

Thus far we have had only a few multi-hour high-power locks, but no parametric instabilities have yet been seen.  (The fast output was, however, useful to confirm that the 6kHz line seen last night was not aliased from a higher frequency.)

I updated the IMC_LOCK guardian to make the ISS_ON state more reliably accessible when the IFO is locked.  Much of this was just moving some code from CLOSE_ISS.main to CLOSE_ISS.run, and using cdsutils.avg to acquire data.  I also created several helper functions to abstract some of the ISS switching.

The current guardian ISS enabling code has been tested a few times at high power, and it has worked without trouble.  One new feature is that the IMC guardian keeps the second loop output value small, averaged over long times.  This is a sort of "digital AC coupling" which may prevent problems with ISS actuator saturation over long locks.

With the ISS on, the DARM noise is significantly improved between 100 and 400Hz.  It doesn't seem that more gain is necessary at this point.

J. Kissel, B. Weaver, J. Driggers, R. McCarthy, D. Barker, D. Sigg, J. Batch

Here are the list of tomorrow's maintenance day tasks organized as we intend to execute them chronologically, and prioritized such that the tasks with the most global impact on the IFO are done first (such that we have the most time to recover from them). As with last Tuesday (LHO aLOG 19600), all tasks, associated estimated times for completion, and responsible persons (or "task manager") will be added to the reservation system when they are *actually happening*, and removed after the task manager has checked in with the operator and confirmed completion. PLEASE PAY ATTENTION TO THE RESERVATION SYSTEM (to help, we're going to put it on the big projector during maintenance). 

As always, please keep the operators informed of your activities as accurately as possible / reasonable throughout the maintenance day so the reservation list can be adjusted accordingly and remain accurate. We appreciate your cooperation!


Group 0 -- prep for maintenance (to be done either the night before, or just before start of maintenance):
    - Clear out all SDF system differences
    - Ensure an alignment offset back up snap has been captured / define a reference time to which we will restore them
    - Bring ISC_LOCK guardian to DOWN, Bring IMC_LOCK guardian to OFFLINE
    - Bring all SEI manager guardians to OFFLINE
    - Bring all SUS guardians to SAFE

Group 1 -- (tasks that can be performed simultaneously) to begin as soon as tasks dependent on group 0 are complete, otherwise, 08:00a PT
    - Timing master's GPS reference swapped for external reference 30 min - 2 hours (R. McCarthy)
        - We expect that this timing system swap will not glitch the timing system, and 
          therefore crash all front-ends, sitewide. However, we are preparing for the worst, 
          and bringing all systems to their respective DOWN / OFFLINE / SAFE state. HOWEVER if 
          the front-ends do crash, the recovery time will of order 2 hours to get all front-ends 
          back up and running. If not, we expect there to be little-to-no recovery time other than 
          to bring guardians back to their nominal states.
        - IF AND ONLY IF the front ends do crash and we have to restart them, we will recompile 
          any front-ends that have crashed against RCG 2.9.6 in order to gather in the bug-fixes that
          come with RCGs 2.9.1 through 2.9.6.
    - HEPI Pump Station Repair 30 min (H. Radkins)
        - Only one of four pump station appears noisey. The corner station can be run on only three 
          pump stations, so Hugh will merely ramp the errant pump out of the system and convert to
          running the corner station on three pumps. This ramp out should only cause a brief minor 
          HEPI actuator pressure glitch. The 30 minutes is a conservative over-estimate of how long
          it will take.

Group 1.5 -- can begin immediately after the effects of group 1 are known:
    - Potential recompilation and install of the front-end models of all front-end machine's 
      that have crashed. See above 2 hours (J. Batch, D. Barker, J. Kissel)
    - Cable routing / pulling for PEM Cosmic Ray Detector 2 hours (F. Clara, V. Roma, J. Palamos)
    
 Recovery of corner station SEI / SUS, and relocking the IMC can begin upon assessment of effects of switching the timing master's GPS reference

Group 2 -- can begin while or after the corner station is being or has been recovered:
    - PEM sensor calibrations 1 hour (V. Roma, J. Palamos)
    - Replace / Repair Timing Fanout at EY 30 minutes (J. Batch, D. Barker)
    - Upgrade BIOS on new EY SUS fast front-end 30 minutes (J. Batch, D. Barker)
    - EY SUS, EY Parametric Instability front-end models recompiled against RCG 2.9.6 and installed 30 minutes (J. Batch, D. Barker)
    - EX Low-Voltage, Low-Noise driver installation and cabling 1 hour (R. McCarthy)
    
 Recovery of all models at EY, restoration of settings, and bring up ETMY SEI / SUS, measure charge on ETMY SUS ESD to confirm ESD health

Group 2.5 -- can begin once work at EY is complete and/or while EY is being recovered:
    - Upgrade BIOS on new EX SUS fast front-end 30 minutes (J. Batch, D. Barker)
    - EX SUS, EX Parametric Instability front-end models recompiled against RCG 2.9.6 and installed 30 minutes (J. Batch, D. Barker)

 Recovery of all models at EX, restoration of settings, and being up ETMX SEI/ SUS.
 Confirm / commission the functionality of new ETMX LVLN ESD driver.
 measure charge on ETMX SUS ESD to confirm ESD health.

Group 3 -- can begin once work and retoration at EX is finished
    - Power cycle corner station front-end's network switch 10 minutes (J. Batch, D. Barker)
         - Work stations will briefly loose their connection to the h1boot server, so workstations will be down briefly.
    - Preventative maintenance reboots of the following computers
         - Conlog
         - EPICs gateway
         - Guardian machine

 Restoration of all alignment settings; recovery of FULL IFO can begin.

Group 3.5 -- can begin once workstations are back and preventative maintenance is complete.
    - Rename and include Mid Station / Beam Tube PEM Accelerometers into PEM MX and MY front-end models 10 minutes (J. Batch, D. Barker)
    - Parametric Instability monitor model install at EX 10 minutes (J. Batch, D. Barker)
    - SUS AUX model upgrade 10 minutes (J. Kissel, B. Weaver)
    - Fix LDAS communication fiber hardware 1 hour (J. Batch, D. Barker) 

 Complete IFO recovery and commission of new bits and pieces.


As seen last Tuesday, and many prior Teusdays, the above plan will not happen exactly as described above, as reality strikes. But, we will try our darnedest! Wish us luck!

Hannah, EvanStefan

Since we redid the AS_A_RF36 re-phasing (alog 19572), we never re-did a src coupling test while moving the SRC1_YAW offset (see alog 18436), so this was on the menu today - before redoing the SRCL decoupling.

- First we lowered the AS_A_RF36 whitening gain from 21dB to 18dB because some quadrants had too much signal.
- Again we found that for the matrix (see alog 19572)
    H1:ASC-AS_A_RF36_I_MTRX_2_1    0
    H1:ASC-AS_A_RF36_I_MTRX_2_2    0
    H1:ASC-AS_A_RF36_I_MTRX_2_3    -2
    H1:ASC-AS_A_RF36_I_MTRX_2_4    2
  an offset of -2500 counts in H1:ASC-SRC1_Y_OFFSET gives the lower POP90, higher AS90, and lower high frequency SRCL coupling. (see plot)
- Since I don't like running with offsets in WFS loops, I tried the following sensing matrix, which puts us to the same position:
    H1:ASC-AS_A_RF36_I_MTRX_2_1    0
    H1:ASC-AS_A_RF36_I_MTRX_2_2   -1
    H1:ASC-AS_A_RF36_I_MTRX_2_3    0
    H1:ASC-AS_A_RF36_I_MTRX_2_4    3
  This admittedly looks odd - it should also have a pitch content - but in alog 19572 we saw that the pitch signal is in a different phase anyway... whatever...
 - With that new lock point we observed:
  - The same SRCL coupling at low frequencies - this one seems steady
  - A lower average SRCL coupling at high frequencies - as a result the notch moved up in frequency from ~75Hz to ~110Hz
  - The high frequency part is also the more variable part - before and after the offset shift. Thus - even though the coupling now seems worse around the old notch frequency - that disadvantage should easily be compensated by the SRCLFF path.

 - We also updated the FM8 cut-off filter in SRCL - it is now a less aggressive low pass filter starting at 80Hz. This still kills the variable part of the coupling, but also reduces gain peaking in the SRCL loop - which before made the coupling worse.

Matt, Hang

We ran the a2l decoupling optimization code this evening for all test masses and for both pitch and yaw. It successfully reduced the low frequency noise. Please see the attachment (darm_spectrum.png). 

The changes were:
H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN: 0.93 -> 1.21
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_GAIN: 0.93 -> 1.32
H1:SUS-ETMY_L2_DRIVEALIGN_P2L_GAIN: 0.00 -> -0.02
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_GAIN: -0.70 -> -0.59
H1:SUS-ITMX_L2_DRIVEALIGN_P2L_GAIN: 1.95 -> 2.04
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_GAIN: 0.63 -> 0.74
H1:SUS-ITMY_L2_DRIVEALIGN_P2L_GAIN: 1.05 -> 1.06
H1:SUS-ITMY_L2_DRIVEALIGN_Y2L_GAIN: -2.05 -> -1.48

H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN 
More details of the measurements could be found under:
/opt/rtcds/userapps/trunk/isc/h1/scripts/a2l/rec. 
It contained both the raw measured data (I, Q and total), and plots of our linear fits as well as rotation. The optimal a2l gains corresponded to the zeros of rotated I's. Please again note that since our data were likely to be correlated, the errorbars shown should just be treated as a rough estimation.

=================================================================================================================================================================================

Besides, we also wrapped the python code into a bash shell that could be easily called in the future. It could be found under:
/opt/rtcds/userapps/trunk/isc/h1/scripts/a2l

To rerun the optimization, you can simply enter
./run_a2l.sh
in the command line, and the code will do the optimization for all test masses and all angular dofs. 

If you just want to optimize some specific optics and, say, only their pitch to length coupling, you can just edit the 'a2l_input.in' file.

In cases that the interferometer loses lock, please press "ctrl + c" to terminate the code. With this keyboard interruption, it will automatically set the not yet optimized drive align gains back to their original values and disable the dither input. 

For more instructions, please refer to 'readme.txt' under the same directory. 

Sudarshan, Jeff K.

The ESD calibration line at 538.1 Hz is moved up to 540.5 Hz, 0.2 Hz away from the Pcal Line at  Yend (540.7 Hz) to estimate the ESD actuation strength. This is a temporary arrangment and the ESD line will be moved back to its original position next week after we have some locked data to analyze. The SDF table is updated accordingly.

Kyle, Gerardo 

0850 - 0900 hrs. local -> In and out of Y-end 

Kyle, Gerardo 

Connected LD to exhaust of Y-mid turbo and sprayed helium on turbo fittings -> Found that this turbo has a "Leak valve" a.k.a. a solenoid vent valve which is either not connected or absent altogether on the site's other Main Turbo Pumps (MTPs) -> The turbo had been left levitated but not spinning since John W. and Gerardo's earlier investigation -> As such, this vent valve would be open -> Found that the clamp for the blank on this valve was loose -> Tightened -> With the turbo levitated but stopped, the QDP80 running but valved-out, safety valve and turbo bypass valve opened we sprayed the turbo's CFF and NW fittings with no obvious "smoking gun" -> It is likely that tightening the blank on the vent valve may have been the leak on the turbo side of the 10" gate valve 

For our next session we will vent the turbo volume and remove and replace the vent valve with a blank followed be a leak testing of the CFF joints on the Y-mid volume

Also, set IP9 to Fixed 7000V -> This leaves only the X-mid still in Step Mode (currently 5000V)