We're done with the initial alignment using the total station and the red laser. The final fine alignment should be done in chamber with ISCTEX in place.

Angle:

TMS yaw angle was adjusted by pushing the TMS SUS cube, and pitch by adjusting the sliding mass on the ISC table, such that the red laser beam from the total station is centered on the aperture on the ISC table. We used a small target placed in the aperture, but putting a target on the ISC table throws the PIT balance off. In the end we placed the second (dummy) target that is identical to the real target such that two targets are symmetrically placed around the center of the table.

Centering relative to ETM:

TMS centering relative to ETM was measured by the total station after putting the table/tele on the alignment stabilizing tooling such that the set screws barely touch the ISC table, then mounting the large target on the large input aperture of the telescope secondary plate.

TMS was 5 to 6mm lower than the ETM and off to the outside of L shape of the IFO by 1.5mm or 2 according to Jason. So the centering error is 

sqrt(6^2+2^2) = 6.3 mm

in the worst case.

This is very acceptable both for the green and IR beam.

Green:

Outside of the arm on the AR side of the ETM, the green arm mode has the waist radius of about 6mm, the Rayleigh range of about 200m, the divergence angle of about 6mm/200m=30urad, and the waist  is 1500m away from the ETM into the arm (see e.g. T1200200).

If we inject a beam from the center of TMS (6.3mm offset from the arm mode at the ETM) such that there's no lateral displacement at the waist, the misalignment angle would be 6.3mm/1500m = 4.2urad.

The power mismatch would be (4.2urad/30urad)^2 = 2%. This is nothing.

IR:

The requirement for the centering tolerance for the IR beam is much larger than the green, as the only important thing for IR is that both of the QPDs will see the light. Even if the IR beam is half radius off of the center of the QPDs that would be OK. Having said that, just for the completeness I'll show some numbers.

Outside of the arm on the AR side of the ETM, the IR arm mode has the waist radius of 8mm, the Rayleigh range of 200m (same as green), divergence angle of about 40urad,  and the waist is 1500m away from the ETM into the arm.

If the TMS is aligned as described above (no lateral displacement at the waist but 6.3mm offset at the ETM) the power mismatch parameter would be (4.2/40)^2=1%. 

... you get impatient and drive HEPI in the same band as driving a suspension transfer function with the same type of excitation. 

[J. Kissel, H. Paris, A. Pele]

The full story:
Hugo was finishing up the extremely long (over-night and into-the-day) measurements of HPI-HAM2, and I'd asked him in what frequency band he was currently running. Since he'd said 10 [mHz]-100 [mHz] when I'd initially asked him (and [I didn't realize / he assumed I knew] the measurement would continue on to higher frequency after this band was done), I launched the 5 hour PR3 M1-to-M1 acceptance transfer functions, to set-and-forget and just be done with it.

Once my measurement was finished, I processed it as normal (see 2013-09-04_1062347744_H1SUSPR3_M1_ALL_TFs.pdf), and found that most degrees of freedom looked spectacular as expected. However, the Vertical and Roll DOFs, only in the 0.3 to 4 [Hz] band, showed a frequency comb of exactly 0.5 [Hz]. What?! To DTT!
(The thought-process narration goes through 2013-09-04-1062347744_H1SUSPR3_M1_0p01to50Hz_DTT.pdf, and the panel ordering is "1" = UL, "2" = LL, "3" = UR, "4" = LR)
After checking to see whether 

- Did awg have a problem from poorly cleared test points? No. (See pg 1, panel 1: Looks like the standard Schroeder-phased transfer function excitation)
- Did my euler basis drive saturate the DAC? No. (See pg 1, panel 2: DAC counts are at most +/-1000 [ct], with T2 and T3 having a DC (pitch) offset in place)
- Did the frequency band or amplitude (driving from 0.3 to 4 [Hz] at 0.01 [Hz] resolution) get screwed up some how? No. (See pg 1, panel 3: an expected 150 [uN/rtHz] from DC up to 4 [Hz] in the Euler Basis, where the OSEM Basis, in DAC counts, the drive is split up evenly between the three OSEMs, and "anti-dewhitened" to compensate for the analog dewhitening.)
- Did the matlab analysis tool some how screw up the data analysis, like with data corruption from frame builder or something? No. (See pg 1, panel 4: I've gathered the transfer function soley from DTT infrastructure, replotted and calibrated the TF. Same exact result in that band. The sky-rocketing magnitude above 4 [Hz] is expected -- it's just noisy incoherent signal.) 
- Did the OSEM sensors saturate, i.e. were we swinging wildy out of the linear range from too large a drive? No. (See pg 2, panel 1: time series of sensor response shows no clipping or anything close to a saturation.)
- Is this craziness in the sensor or the actuator? The sensor (See pg 2, panel 2: ASD of the calibrated OSEM and Euler basis signals)

Well shoot.

Then, I went on to "trust but verify" Hugo's statement that he was only driving up to 100 [mHz]. I find that his excitation has *finished* the 10 to 100 [mHz] band, and the script automatically moved on to working it's way through the 700 [mHz] to 10 [Hz] band during the V and R suspension excitations, and in particular, a 0.5 [Hz] comb between 0.5 and 10 [Hz]. This is shown by the HPI excitation signals in Pg 2, panels 3 and 4. And get this, since suspensions still uses a flat drive instead a comb for their Schroeder phased excitation, the drive from HPI is only coherent at the comb frequencies of HEPI. But it *is* coherent (see pg 3)!

ANYWAYS, of course, had I known the frequencies that Hugo was driving, of course I wouldn't have started the measurement. OH WELL. Lesson learned. And a good commissioning exercise. 

Transfer functions are running overnight on both HEPI-HAM2 and HEPI-HAM3.

Days Activities

Alignment of ITMx @ BSC3:  rough check done yesterday

Modify annulus piping (kyle will prep and then apollo will work on piping

Sprague on X-arm

Hugh at HAM6

Cyrus rebooting/working vacuum vmes at all outbuildings in the morning

Instrument air alarm at MY (Ski)

******I had to leave the Control Room to assist with TMS work at EX around 1pm.  Justin covered for me, and below are notes from his shift*****

1320 - Justin takes over for Corey at ops
1325 - Arnaud running excitation and taking measurements on BS
1330 - Hugo working on HEPI watchdogs for output HAMs (WP#4114)
1330 - Kyle giving tour to vendor
1343 - Corey/Cheryl/Jason working on TMS at EX
1538 - H1IOPSEIB1 crash - Dave B power cycling the chassis; DAQ restart
1550 - Lights came on in H1PSL ante room mysteriously

Vented annulus (minus gate annulus) for Apollo rework of annulus piping -> Pumping annulus with aux. cart.  

Leaving Vertex etc. pumped only by IP1,2 and 5 -> Resulting pressure should level off to < 1 x 10-7 torr in this configuration

h1seib1 froze up after the HPI DAQ-RESTART button was pressed. We power cycled this front end and then restarted the DAQ due to a change of the h1hpiitmy INI file for Vincent's measurements.

Continued modifications on clean room curtains for BSC 3 and modified a bridge platform spanning E-module to work platform.
Modified annulus piping on GV-2 to allow handrail installation.
Tyler removed heli coils from a mounting plate for Lisa A.
Relocated a baby bull snake that Karen found at End Y back to it's natural habitat.

HugoP, JimW
 

The payload flag input was disabled on the following HEPI top-level models:

• h1hpiham4.mdl
• h1hpiham5.mdl
• h1hpiham6.mdl

This modification was performed to allow commissioning on those HEPIs. Changes will be reverted once suspensions are installed.

The $Id$ and $HeadURL$ tags were updated as well.

Models are recompiled, restarted, and commited under the SVN.

Work was performed under WP #4114, which is now closed.

Stefan recently had upgraded the PSL's frequency stabilization servo (FSS), and its interaction with the input mode cleaner (see LHO aLOG 7571). However, because new Guardian development only got the mode cleaner up and running the evening Jamie left (see LHO aLOG 7472), it's been in a sort of unused, half-baked, off, state sense then. Jamie's on site again, now so we'll continue debugging and getting the Guardian infrastructure up and running to production-level, leave-on-all-the-time state. Until then, while we want to use the mode cleaner for characterization studies, I've restored the full hierarchical lock using, "the shortest IMC autolocker," from (the admittedly unofficial and obscure location):
/opt/rtcds/userapps/release/ioo/h1/scripts/imc/sballmer/MClockwatch
originally cited in LHO aLOG 7475.

This script is now (stupidly) running on opsws3. If it dies for some reason, we'll restart on the guardian script machine like we've done with the various other version of the autolocker (see 7289). If the real guardian stands up (please), we'll drop this auto-locking method like it's hot. 

Following alogs https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=7609 and https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=7604, I have performed measurements to evaluate:
- The origin of the 6.18Hz noise
- The effect of the feedforward
- The transmissibility while driving HEPI (to be above the noise floor of the instruments when the ISI is controlled and excited by the ground motion)

Results from the past:
1- There was already a tiny feature (barely noticeable) around 6Hz when the isolation loops were closed for the first time on June 20th (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=6832). In the presented spectra, feed forward control was not engaged.
2- In https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=4874, feedforward stability analysis was performed on ETMY. It was shown that the risk of instability was limited when using the feedforward from stage 0 to stage 1.


New results:
I drove (white noise) simultaneously all HEPI actuators in Cartesian basis such that GS13s are above their noise floor when the ISI is controlled. Then, I measured transfer functions from the HEPI L4C to the GS13 in two configurations (with and without feedforward). Transfer functions are presented in attachment.
1- The coherence below 100mHz is low since the white noise was injected by the HEPI Feedforward path (parallel path to isolation path) and the HEPI is controlled in position at 100mHz
2- The 6.18Hz spike is not visible in Y, RZ and barely visible in Rz. It is more visible in the vertical degrees of freedom.
3- Feedforward is decently tuned to tackle the [2;15]Hz frequency band. The zero created by the feedforward is around 6.18Hz (Is it coincidence?).
4- There is no coherence at 6.18Hz from the input motion to the GS13. (spikes don’t seem to be created by the input motion)
5- Isolation at 1Hz is pretty good (80dB)
6 - Note a pretty high transmissibility on Y and Z around 30Hz created by the zero of HEPI.

Started DTT transfer functions to study vertical to longitudinal coupling on the BeamSplitter (~1hour)

I've completed the vacuum crate reboots as specified under WP4113.  h0vemx, h0vemy, h0veey, and h0veex have all been rebooted using the new VxWorks boot server, vxboot, with no apparent issues (at this time).  These are the last of the VME systems requiring reconfiguration, which means the old boot setup can now be retired.  At the same time I moved these systems over to the new network switches installed in the outbuildings, in preparation for the old switches being removed.

PRM lower masses transfer functions from July 15th have been exported and are plotted in the attached documents below

(1) H1 PRM M2-M2 (July 2013) TF in 3 DOF (L P Y) plotted against hsts model (in blue) L1 PRM (July 2013 in orange ) and H1 PR2 (July 2013 in pink)

(2) H1 PRM M3-M3 (July 2013) TF in 3 DOF (L P Y) plotted against hsts model (in blue) L1 PRM (July 2013 in orange) and H1 PR2  (July 2013 in pink)

Both set of measurements are showing good agreement with the model, llo prm and lho pr2

Data, scripts and pdf files have been commited to the svn as of this entry

Note :

Since PRM M2 triple acquisition driver chassis hasn't been modified yet, the calibration factor in "calib_hsts.m" (living in sus/trunk/HSTS/Common/MatlabTools/) has been set to 0.32 mA/V, as described in the hsts electronics drawing summary. Value will need to be changed to 3 mA/V accordingly with driver's modif.

on opsws8, at 04-Sep-2013 09:35:28 PDT. It's gunna take 5* hours. 

*This is ridiculous!  I can get this done in DTT in an hour. I'm gunna dive into the what-has-become 16 nested layers functions and find out why it's taking so darn long. Sheesh!

After "resting" one of the three cooling units in the MSR, here is the subsequent temperature increase (two day minute trend plot). The Temp probe is located on top of the racks at the mid point.

Attached are plots of dust counts requested from 4 PM September 2 to 4 PM September 3.

Transfer functions are running overnight on both HEPI-HAM2 and HEPI-HAM3.

In the attached spectra (stage 2 Z motion), the isolation is really good except at 6.18Hz. It seems that some electronic noise is reinjected in the system. Some noise hunt is ongoing.