[J. Kissel, A. Pele]

We've launched acceptance transfer function measurements on H1 SUS BS, using a matlab session on operator1 computer. Measurement start 30-Jul-2013 18:23:34 PDT. We expect it to take 12 (!!) hours, so it should finish 31-Jul-2013 06:30 PDT.

[S. Biscans, K. Izumi, J. Kissel, A. Pele, J. Rollins]

Log of how we brought the IMC back up to locking today after the RCG 2.7 upgrade in rough chronological order:


- SUS (for each SUS --  MC1, MC2, MC3, PRM, PR2, PR3, BS, ITMY, IM1-IM4)
   - Given to us as it comes up from a reboot, in SAFE -- watchdogs tripped, masterswitch off, (stale*) alignment offsets OFF. ** 
   - Reset IOP watchdog
   - Reset Inner-most USER watchdogs
   - Reset USER DACKILL
   - Turned on Masterswitch (damping loops should already be trying to run)
   - Turned stale alignment offsets (in anticipation of having to burt restore ripe offsets that are not that different)
   - Recovered ripe alignment offsets for MC1, MC2, and MC3
       - snapped to 2013-07-29 20:00 (Local)
       - /ligo/cds/lho/h1/burt/2013/07/29/20:00/h1susmc*epics.snap

- HPI-HAM2 & HPI-HAM3
   - Given to us as it comes up from a reboot, in SAFE -- watchdogs tripped, masterswitch off ***
   - Make sure no offsets are requested, ramp down master gain
   - reset watchdog
   - turned on master switch
   - manually restored offsets in OUTF 
      - put in a 10 sec ramp 
      - entered and turned on offsets from LHO aLOG 7180 (offsets turn on use the ramp time now as well)


- ISI-HAM2 & ISI-HAM3
   - Given to us as it comes up from a reboot, in SAFE -- watchdogs tripped, masterswitch off
   - Make sure no offsets are requested, ramp down master gain
   - reset watchdogs
   - Turned on Master Switch
   - Used Command window, to 
      - damp ISI
      - isolate ISI Level 2 

- PSL
   - Runs entirely on Beckhoff, and was unaffected by the the RCG 2.7 upgrade so there was no recovery needed

- IOO
   - Given to us as it comes up from a reboot
   - burt restored h1ascimc.snap (mainly to restore alignment of Beckhoff controlled mirror at the top of the periscope -- all other mirrors are fixed)
      - 2013-07-29 20:00 (Local)
      - /ligo/cds/lho/h1/burt/2013/07/29/20:00/h1susascimc.snap
   - turned off IMC WFS loops
      - ramp down master gain in bottom left corner
   - turned on guardian ****
      - go to IMC screen, have the guardian screen handy/visible
      - In a terminal
         ]$ ssh h1gaurdian0
         ]$ screen -RAad imcguardian
           (opens a "screen" environment, which looks just like a new terminal)
         ]$ cd /opt/rtcds/userapps/release/ioo/h1/scripts/
         ]$ ./runIMCGuardian
           (some lights should go green on the IMC Guardian Screen)
           (hit successive crtl+a, then ctrl+d which "detaches" the screen session, taking you back to the original h1gaurdian0 terminal)
         ]$ exit 
           (logs you out of h1guardian)
      - the guardian starts up not doing anything (state request or current state are blank)
      - hit "manual", "quiet," or "damped" on the IMC Guardian Screen (since there are currently no "goto_" scripts for "locked," hitting "locked" doesn't do anything)
      - Manually Ramp IMC WFS master gain back up (guardian doesn't know to touch it)
      - IMC Locks up like a charm


* Because the safe.snaps for most suspensions had been captured a while ago, one can never trust the alignment offsets. 

** For MC1, MC2, BS, and ITMY, the safe state came up with the BIO settings frozen and red -- specifically the Test/Coil Enable switches were red, and changing the state request didn't change the filter settings. Scared that this was a bug in RCG's interaction with RCG 2.7, I had considered going through a full boot process and/or declaring a failure mode of the upgrade. However, since this did *not* appear on MC3, PRM, PR2, or PR3 (which ruled out that the bug was common to a given computer), my quick test to see whether it was frozen on a given SUS was open open the BIO screen and randomly pick a field to try to change. When I got to the beam splitter, my randomness drove me to try changing the TEST/COIL Enable bit instead of the State Request. When I requested to turn on the SUS-BS M3 TEST/COIL Enable, it flipped the M1 and M2 TEST/COIL enable and all BIO functionality returned, and the stages began behaving independent as expected and as normal. I went back to the other suspensions, and saw similar behavior i.e. that the BIO EPICs record was stuck, and the SAFE burt restore didn't sufficiently tickle the EPICS database to get the BIO request and monitors to report back correct information. Once tickled in the right way, all functionally returned. YUCK!

*** Sebastian, having never seen spectra of LHO IPS, we had assumed that the HPIs were locked, or the IPS were broken. Because of the nonsense in described in ** I told him to wait a bit. Then we convinced ourselves that we needed to power-cycle the H1SEIH23 I/O Chassis (because we'd heard that Dave had to restart the PSL I/O chassis this morning because it complained it had lost connection with the dolphin network or something). 

**** We tried to follow Chris' instructions from LHO aLOG 6920, but this failed because the h1script0 machine is still running Ubuntu 10.4 (as opposed to 12.04 that h1guardian has been updated to recently, like the rest of the control room machines) -- so we don't know how Chris did it. Thankfully Jamie was helping and identified the problem immediately after querying Jim.

WP 4065

this morning we upgraded CDS to tag advLigoRTS-2.7. All daqd systems were compiled from source, all front end models were rebuilt, all front end computers were rebooted.

At the same time, the EY computers were powered down and will remain off for several weeks while we reconfigure EY to the aLIGO configuration.

The EY systems were taken out of the Dolphin manager, and their channels were marked as acquire=0 in DAQ so that they are not written to the frame. Their channels are still in the DAQ to allow trending of the old data.

h1dc0 required a reboot to load the new GPS drivers. h1susb123 and h1psl0 were power cycled for permit comms with their IO Chassis. 

I did not update the PSL models today. This system was burt restored to 8am today.

We are testing the new science frames features in the DAQ. We have found some problems with the channel stats.

Unfortunately our dataValid flags are still incorrect (set to ONE, should be ZERO). Jim rebuilt tag 2.7 on the DTS and its DAQ there is writing correct dataValid values. We are investigating what is different between the two.

Jeff reports strange binary I/O behavior on the sus models (QUAD and HAM). The BIO readbacks are bogus until an output channel has been switched, at which point the data becomes correct. We are investigating.

Was able to open GV5 and leak test the gate annulus piping joints on GV6 today -> 1 of 5 CFF was found to be leaking.  


Volume = Y1, Y-mid, Y2, YBM, XBM, HAM2-3, BSC1,2,3,7,8 being pumped by CP1, CP2, YBM MTP (backed by leak detector), CP3, CP4 and IP9.  
Helium background 6.5x10-8 torr*L/sec -> 1.33 CFF on North side of GV6 climbed steadily from background to 1.5x10-7 torr*L/sec beginning 18 seconds after filling bag until purged with air at the 200 second mark.  Demonstration was repeated after signal fell back to near the original starting value. 

Started fluid draining this morning and today got 8 liters out.  Also, all the HEPI electronics at the Piers were removed and all the Actuators were disconnected from the Crossbeam Feet.  Actuator lock-down is ongoing.  Additionally, most of the ISI cabling sans EM Actuators were disconnected from the chamber and the CPS racks brought down.

Greg & Hugh

Took a new safe_snapshot of ITMY using save_safe_snap('H1','ITMY') matlab script. It includes the new gain values for the 2.1 damping filters recently installed.

h1susitmy_safe.snap is located in /opt/rtcds/userapps/release/sus/h1/burtfiles

EY:  Cleanroom move, ISCT-EY move to LVEA, powering down lots of electronics, rerouting VAC conduit

CDS work:  RCG 2.7 work begins (which takes down pretty much everything), reboot h0pemmx, much of afternoon devoted to restoring systems from RCG work.

Terminals upgraded to software to make medm faster (BUT, we can no longer look at out-building videos on Control Room terminals....because they freeze the computer(!))

Snow Valley working on Chillers, Praxair made a delivery, Sprague on-site

I measured the ETMX OL values

prettyOSEMgains('H1','ETMX')

M0F1 19894 1.508  -9947
M0F2 29453 1.019 -14727
M0F3 30661 0.978 -15330
M0LF 24512 1.224 -12256
M0RT 24724 1.213 -12362
M0SD 21784 1.377 -10892
R0F1 28922 1.037 -14461
R0F2 23013 1.304 -11507
R0F3 25716 1.167 -12858
R0LF 26662 1.125 -13331
R0RT 24388 1.230 -12194
R0SD 21961 1.366 -10980
L1UL 24267 1.236 -12133
L1LL 26538 1.130 -13269
L1UR 24545 1.222 -12273
L1LR 26259 1.142 -13130
L2UL 17935 1.673  -8967
L2LL 18726 1.602  -9363
L2UR 25124 1.194 -12562
L2LR 25518 1.176 -12759

When the ETMX came up after the software upgrade, I attempted to measure the OL values on the OSEMs, which had been installed and left retracted by Betsy yesterday.

I noticed that four channels, R0 F1/F2/F3/SD were behaving oddly. Trending revealed that these channels had gone bad at 00:09 Pacific this morning (see attached). Richard replaced the satellite amp and they came good.

Summary:

Off-center the beam on curved mirrors significantly in one direction and everything is within tolerance (first plot, this is the best quality data we managed to squeeze out of this setup).

Center the beam on the curved mirrors and the data looks OK-ish but things are somewhat out of nominal tolerance (second plot, some green error bars are outside of two vertical lines representing the nominal tolerance), and the ellipticity and the astigmatism become worse (you can tell by the fact that X data and Y data moved in the opposite direction).

The third/4th attachment show how off-centered the beams were on the secondary and on the primary when the good data was obtained.

The 5th/6th attachment show the centering on the secondary and the primary when the second set of data was taken.

This is repeatable. Every time a good looking data is obtained, the beam position on the primary is offset to the left. Every time we re-centered the beam on the primary and the secondary, the scan data is worse (but still OK-ish, not terrible).

Sounds like a problem of the mirror surface figure to me. Maybe we got unlucky on this pair.

This is the best we can achieve, and since it's not terrible when the beam is centered on the curved mirror, I'll declare that this is the final tuning of the H1TMSX. Tomorrow we'll mate the ISC table to the tele.

Today I processed the data from the lower stage transfer functions taken few weeks ago on the 3 MC suspensions.

Attached are the plots showing respectively M2 to M2 and M3 to M3 Phase 3b DTT undamped transfer functions for MC1 MC2 and MC3.

Measurements are consistent with the models (blue curves). Only MC2 M2-M2 and M3-M3 pitch show a small discrepancy at around .85Hz, frequency that corresponds to the first vertical mode. 

*Measurement and data processing details*

dtt templates are saved and commited under :

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/${susID}/${sagLevel}/Data/${date}_H1SUSMC1_M2_WhiteNoise_${DOF}_0p01to50Hz.xml

mat results files are saved and commited under :

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/${susID}/${sagLevel}/Results/${date}_H1SUS${susID}_${sagLevel}

During the process, a function called "calib_hsts.m" has been created under /ligo/svncommon/SusSVN/sus/trunk/HSTS/Common/MatlabTools and is being used in plotHSTS_dtttfs_${M1/2/3}.m, since the calibration of the second stage of MC2 is different than MC1 and MC3 (different coil driver).

the function defines the DC scaling factor to calibrate data with inputs :

susID ('MC1','MC2','MC3',...)

level ('M1','M2','M3') 

is sensor input filter engaged ? ('true','false')

Initially we were unable to do some needed leak testing on GV6 a few weeks ago as the helium background signal in the site vacuum system was too high (~2 x 10-6 torr*L/sec).  We have reduced this via valving-in the YBM turbo during the day then valving it out at the end of the day over the past few weeks (must be attended when open to the BT).  As of the end of today the helium background is about 2.5 x 10-7 torr*L/sec, still too high for leak testing.  

Based upon the physical parameters, the rate of removal via the YBM turbo pump suggests a reservoir of helium with some independent conductance to the vacuum system as opposed to an initial quantity of helium fully present in the vacuum system.  As such we have vented then pumped and or purged adjacent volumes which had been exposed to helium spraying in the recent past (GV1 annulus, GV3,4 gate annulus, HAM4 annulus, HAM4-5 OMC volume, HAM1-2 annulus, HAM1 interior.  This had no significant effect, i.e. the reservoir+conductance could be withing the vacuum envelope(?)

Today we were able to "take the gloves off" (HIFO Y ended) and demonstrate the the large, 2500L/sec, ion pumps are the source of helium.  We conclude this by noting that soft-closing GV5 resulted in a slight increase in the helium background at the Vertex (IP9 and IP11 not yet saturated-still pump helium a little bit) and that valving-out IP1, IP2, IP5 and IP6 resulted in the plummeting of the helium signal, i.e. t0=1100hours=3.1x10-7 torr*L/sec, 1110hours=1.7x10-7, 1120hours=9x10-8, 1130hours=5.0x10-8, 1140hours=2.7x10-8, 1150hours=1.5x10-8, 1305hours=1.2x10-9, 1430hours=1.1x10-9.  

Conclusion: We believe that this is the first instance that we have ever had a leak detector valved-in while one or more 2500L/s ion pump(s) was simultaneously valved-in.  Nominally, leak testing is performed on an isolatable volume pumped only by a turbo which is backed by a leak detector.  When initially attempting to leak test GV6, the YBM turbo, IP1, IP2, IP9 and IP11 were all valved-in (GV6 was open at the time).  Therefore we don't know if the helium concentrated/dissolved in the ion pumps that we see now is the result of years of low level residual exposure or, conversely, one single large recent exposure "event".  So we don't know if this is a new issue or an old issue(?)  

Rick, Doug, Jason, Craig, Pablo
The P-Cal periscope alignment successfully finished up today. Targets worked well and the positioning and angles are better than required in most cases.
Actual values to be added here shortly. We will break done the setup tomorrow and begin the ETMx test stand alignment

Remove light pipes from ISCEY - Sheila

Replace check valves at MY and EY - Ski

Hard close GV-18 - Kyle

Soft close GV-5  - Kyle

Relocate the old BSC 10 ISI from termination slab - Apollo

Sweeping both X and Y arms - Stripe Rite

Upgrade all CDS to RCG2.7 - Dave and Jim

Power down all EY CDS computer and networking systems - CDS

Over the weekend I tested recruiting the IMC cavity feedback to simultaneously damp the MC2 longitudinal DOF. It is possible to make a cavity controller damp a the longitudinal modes of a suspension of 3 or more stages if three rules of thumb are met:

1. Cavity feedback exists below the top mass for at least 2 of the stages. Those are M2 and M3 here.
2. The feedback on the stages below the top mass have unity gain frequencies (UGFs) greater than the longitudinal resonances. The highest mode in this case is 2.75 Hz.
3. The damping increases as the UGF of the highest stage below the top mass decreases towards the highest frequency longitudinal mode. Here the M2 UGF decreases towards the 2.75 Hz longitudinal mode.

This is part of the more general global damping scheme described in G1200774. Global damping is intended to both isolate OSEM sensor noise from the cavity degrees of freedom and decouple the damping design from the control of the optics.

Parameters for this test:
1. The IMC was locked with feedback to MC2 M2 and M3. 
2. There was also ~10 kHz feedback to the laser frequency, but this was unimportant for this test. 
3. The MC2 M1 longitudinal (MC2_M1_DAMP_L) damping was off. 
4. The varying parameter is the gain on the M2 feedback loop (MC2_M2_LOCK_L). The gain was set to 4 different values [0.03, 0.06, 0.12, 0.3], corresponding to M2 UGFs at [3.3, 4.0, 6.0, 14.7] Hz respectively. 0.03 is the default gain.

The M3 loop was not adjusted. Its gain was left at -1000. Fortunately, the existing IMC cavity control was designed with oodles of phase margin, making it relatively easy to adjust the M2 gain by an order of magnitude without redesigning any filters (except for the addition of a 41 Hz notch filter for stability as described in 7257).

See the three attached figures.

1. IMCCavityRingdown.pdf shows the impulse response of the cavity at these different M2 UGFs. The impulse was applied to the M1 stage. Note that the Q of the top mass is a strong function of the M2 UGF, and is positively correlated with it. The magnitudes of the curves in this plot were normalized because they are naturally different since the cavity has differing loop gains with the differing UGFs.

2. MC2M1Ringdown.pdf is structured exactly like IMCCavityRingdown.pdf except the M1 response is shown rather than the cavity response. The results here are the same, the M1 Q drops with the M2 UGF. The curves here are not normalized, since we are not looking at a stage with cavity feedback (no changing loop gains at this stage to effect our scaling).

3. MC2M1toM1TFs.pdf shows longitudinal transfer function measurements on M1 (MC2_M1_TEST_L_EXC to MC2_M1_DAMP_L_IN1). Like the previous two plots, a curve is shown for each UGF case. Here we see again, but in the frequency domain, that the Qs of M1 decrease with M2 UGF. For reference, the transfer function without cavity control or L and P damping (other damping on) is plotted in green. This reference shows clearly how much the cavity control influences the top mass dynamics.


More general comments:

1.  In general, if cavity feedback is applied to the two stages below the top mass in a 3 or more stage pendulum, and that feedback has UGFs beyond the longitudinal modes, some longitudinal damping will be observed. However, by carefully placing the UGF of the stage right below the top mass near that mode, one can maximize the damping provided by the cavity. In this way, no noisy top mass longitudinal damping is required for the pendulum that receives this cavity feedback. The loss in loop gain by dropping this UGF can be compensated for by increasing the UGF at a lower stage.

2. Note, if the cavity feedback is sent to each pendulum in the cavity equally, all longitudinal modes seen by that cavity are damped by the cavity feedback. There are then undamped longitudinal modes not seen by the cavity (or more precisely seen weakly). However, this can be overcome by damping these modes by recombining the OSEM sensors into a global coordinate system orthogonal to the cavity as discussed by G1200774.


Some more nitty gritty measurement details:

1. The impulse is applied at the M1 L stage with MC2_M1_TEST_L_EXC. DTT was used for this by filtering its native impulse excitation through a filter with two poles at 10 Hz. The 10 Hz roll-off is greater than the longitudinal modes, so the ringing response should be true to an impulse. However, it is also smoothed out enough that the otherwise extremely tall and short excitation will excite the suspension and not saturate the DAC.

2. I left the cavity pretty much as I found it when I was done. i.e. the MC2 M1 L damping was turned back on, and the MC2_M2_LOCK_L gain was set back to 0.03. The one exception is that I left a 41 Hz notch filter in place in MC2_M2_LOCK_L at filter module 5 since the cavity seems to be more robust with it there. aLog 7259 describes the notch more fully. The IMC cavity was still locked when I left.

3. The MATLAB code that generates these plots is found at 
.../sus/trunk/HSTS/Common/FilterDesign/H1MC2_CavityControlTest_27July2013.m

Yesterday, Gerardo bonded on the 1st prism to the LLO destined PUM.  He used the new procedure which incorporateed adding borosilicate glass beads to space the glue joint more appropriately.  He intends to proceed today with gluing in the magnet/flag discs and then the 2nd prism today/tomorrow.