J. Kissel, K. Izumi

While we were showing Sudarshan some things, we recalled that FM3 of the 
H1:CAL-CS_DARM_ANALOG_ETMX_L3
bank included a filter to compensate the 2e3 pole for the high voltage ESD driver. Since we'll be using ETMY for the engineering run, which has a new low noise driver without this pole, we have turned this filter off.

First update to the CAL-CS calibration for ER7 woo!

This change was seen by the SDF system, and I've accepted the change.

J. Kissel

Since we seem to have asymptotically approached the conclusion that we will NOT be engaging the new ESD driver's low pass filter for ER7, and ODC people are complaining that their numbers aren't green, I've restored the gain of the hardware injection bank to 1.0.

This re-increased the continuous wave injection amplitude to its originally intended value (see LHO aLOG 18681).

This had been reduced to 0.1 a few days ago when we were trying to commission the low noise driver in hopes we could get it running for ER7 (see LHO aLOG 18699).

Since Evan saved us from the case when the Oplev damping gets enabled while the suspension is in the damped, but not aligned state (thus having too little light on the QPD for the loop to work), we decided to enable the LIMITS.  (Thx Evan and Sheila)

LIMITs of 50 have been enabled on the ITMX and ITMY L3 OPLEV PIT and YAW loops.

LIMITs of 150 have been enabled on the BS L3 OPLEV PIT and YAW loops.

I've accepted these changes in SDF.

With the help of commissioners, I have been cleaning house on the SDF alarms today and last Fri.  Still a few to go...

However, when we switched a few things on some SUSes today during one of the lock loss periods, we noticed that the SDF put a strange time stamp on the DIFF.  See the ITM DIFFs attached.  We added a LIMIT value and turned the LIMIT switch on all within the same few minutes just now.  However, on both the ITMs (and the unpictured BS) the switch time stamp shows last Wed at ~11:57am.  What the heck?

Laser is ON
Output power is 33.1 W (should be about 30 W)
Watchdog is active
PSL SYSSTAT: VB program online is red, LRA out of range is red (only VB program online should be red)

PMC
Last relock 6 days, 1 hour ago (should be days/weeks)
Reflected power is ~ 11% of transmitted power (should be 7% or less)

FSS
Locked 1 hour (should be days/weeks)
TPD is ~ 1.4 V

ISS
Diffracted power is around 5.5% (should be around 7%)
Last saturation event was ~ 1 hour ago (should be days or weeks)

Andy, Josh, Dan, 

We found (using the script described in 17791 and 18588) that some of the COMM channels (LSC-Y_COMM_CTRL_OUTPUT, LSC-X_COMM_CTRL_OUTPUT) used for tidal offload from the IMC were hitting their limits during some of the recent H1 locks. The attachments show: 

1) LSC-Y_COMM_CTRL_OUTPUT and LSC-X_COMM_CTRL_OUTPUT at the end of the first short observation intent time from the summary page today. Note, they are saturating at 10 um for this whole lock. 

2) Same channels for the end of the next lock, COMM tidal is not saturating during this lock. 

3) IMC-F during the lock when COMM tidal is saturating, note it is running away to very high values. 

4) IMC-F for the second lock, when COMM tidal isn't saturating.

Additionally, we see some additional noise during the first lock where COMM was saturated, and at those times DARM coherence with MCL, PRCL, and SRCL also increases. This may or may not be caused by the saturation, but we thought it worth reporting. 

5) Spectrogram of DARM during first lock. 

6) Coherence-o-gram of DARM vs MCL (note: a followup spectrogram indicates MCL got much noisier at the time with higher coherence) during first lock. 

Side note: We also saw ISI-GND_BRS_ETMX_RY_OUTPUT going between its limits, but Jeff says this is an out of loop tilt sensor, so we'll ignore it. 

I have been setting the observation bit to undisturbed even though the range is incorrect.

The calibration of DRMI (PRCL, SRCL and MICH in um, alog 14067) has been entirely moved to the CAL-CS model from the OAF model (alog 16698). In addition, I updated the optical gains so that they are accurate in full lock.

For those who remotely access the DRMI spectra, here are the channels that you can look at:

• MICH/PRCL/SRCL unsuppressed displacement in um: H1:CAL-CS_MICH(or PRCL, SRCL)_DQ
• MICH/PRCL/SRCL suppressed error signal in um: H1:CAL-CS_MICH(or PRCL, SRCL)_ERR_DQ
• MICH/PRCL/SRC feedback signal in um: H1:CAL-CS_MICH(or PRCL, SRCL)_CTRL_DQ

Also, be careful that all these channels have digital whitenings for preseving numerical precision and therefore need anti-whitening using zpk( [100; 100], [1,1], 1) for real data analysis.

The scripts to estimate the optical gains and compare the models with some measurements can be found in the calibration svn:

aligocalibration/trunk/Runs/PreER7/H1/Scripts/lsc

The scripts are named as:

• H1MICH_OLTFmode_20150517l.m
• H1PRCL_OLTFmodel_20150517.m
• H1SRCL_OLTFmodel_20150517.m

To estimate the optical gains, I used the data from 2015-May-14th that Evan measured for me (alog 18487) in full lock.

BTW, since the OAF model is still running, one can still get some data out of it. The calibration in OAF have not been maintained at all and therefroe the calibration must be wrong.

Here are some plots for entertainment purpose:

Note that the MICH open loop measurement deviated from the model at high frequencies above 60 Hz or so. Not sure why.

VAC:
Tuesday:
Routing steel tubing at end stations for TMDS
Run up turbo to replace gauge at end station

FAC:
Membranes for RO are on order, may be replaced Tuesday

In the first observation intent time from today, there are DAC glitches in MC2 M3. They don't obviously appear in DARM at the time we checked, but they do appear in a number of channels. The first plot is an Omega scan showing glitches in MC_L, and the second shows that they correspond to zero crossings in MC2 M3 control.

Observation Bit: Commissioning 

16:07 Realign after Lockloss
18:10 Dick G. - Going into Optics Lab
19:20 Dick G. – Out of Optics Lab
20:10 IFO locked at LSC_FF
20:15 Observation bit set to Undisturbed
20:36 Lockloss Reason unknown
21:45 IFO locked at LSC_FF
21:50 Observation bit set to Undisturbed
22:03 Adjust ISS diffracted power from 12% to 8%
22:17 Lockloss – Reason unknown
22:21 Re-Start initial alignment after Lockloss
22:40 Complete initial alignment
22:43 Start Guardian locking
23:14 Lockloss – restart locking process
23:55 Lockloss at Engage_ASC
00:00 Due to problems locking left IFO in a down state. 

   Very difficult to do initial alignment and to get the IFO to lock. There was a large amount of activity in the 1 -3Hz and 3 - 10Hz seismic ranges and several periods of higher winds (upper 30 mph and mid 20 mph). Large ring up in Bounce and Roll modes each time reached Engage_ASC stage. Limited success in suppressing these.     

All times are Pacific Standard Time:

All locks are at 24W LASER Power:

Tried to reset the R0 water pump twice. No luck. It will remain off until Bubba can look at it on Monday morning.

IFO wasn't re-aligned all day. AS Air image had a bit of a bulge to it. It didn't seem to matter...much.

07:30 in a bit early. I was up. Why not?

07:31 Dan on site from last night. Looks like we had a nice 6-7 hour lock. Bounce, Roll and violin modes have been mercilessly beaten down to almost nothing and Dan sauys this is now the status quo.  NICE!

08:17 IFO re-locked. Dan and I re-tweaked some bounce mode filters and did some dithering alignment to the OMC Intent bit set to undisturbed.

09:03 Jeff Kissel on site.

09:08 OIB set to comissioning

09:10  Jeff increasing DARM gain. (was too low)

09:24 OIB set to UNDISTURBED

10:25 Dan went home. He reduced the OMC dither gain in Guardian before he left because he noted that it was pushing a bit to hard on the mass. 

10:30 went out to try and reset the RO pump. no luck.

10:35 Jeff noted that a small plane flew overhead.

11:02 Bubba called in about the RO pump status. The alarm is NOT ringing in the control room and he said the pump can stay off the rest of the day and he'll look at it tomorrow. Unless it becomes a nuisance ro we run out of potable water..don't worry about it.

11:54 Jeff went home. I'm singular.

12:00 ripples showing up on strip tool, probablty as a result of the 5.0 mag quake that struck the Aleutians at 18:07:45UTC? ( i don't think the timing is coincidental enough)

12:10 Got some SRM vocalizations, AS Air cam got a bit jittery but she's holding steady as a rock!(famous last words?)

12:50 HPI-PUMP_EX_DIFF_PRESSURE alarmed (Yellow).

13:39 both ITM oplevs and the BS oplev are showing oscillations in Pitch ~15min prior and also starting to wander up and down.

13:42 Lockloss. OIB auto-switched off.

13:56 Re-locked @ DC readout 

14:10 Set the gain on ETMX_M0_DARM_DAMP_R to 200 to improve roll mode after lock settled awhile. Turned on DHARD_P filter 9 (:12^2) because Dan told me that it was a good idea. No Dither align on OMC this lock.

14:14 OIB set to UNDISTURBED

14:40 Oplevs starting to show "ringing" . This time it seems to be ETMY being the biggest offender with ITMY and ITMX tied for second place. The BS doesn't seem to be involved in this heat.

14:54 Lockloss

15:10 Re-locked. Adjusted/Engaged filters as before except turned gain on ETMX_M0_DARM_DAMP_R up to 500. I intitially set the gain at 300( then changed it to 500 after the intent bit was set) I then turned on dither alignment to OMC @ .07 master gain. Range about 58Mpc.

15:59  ETMY oplev showing large oscillation again. Lockloss. All yours Jeff. 

Tonight I worked on (re)commissioning the OMC alignment dither and measuring the AS power as a function of DARM offset.

OMC Alignment Dither

Since (re)commissioning the OMC ASC dither last month, the yaw loop had become unstable.  In case this becomes a persistent problem, I've written a script that will measure the dither sensing matrix, invert, and loads the resulting control matrix into the appropriate fields in the DACTMAT matrix.  (Not sure what DACTMAT means...I would have called it DITHER2DOF.)  The script is here (I have committed it to the svn):

~userapps/release/omc/common/scripts/ditherDCsense.py

The script inserts DC offsets into the OMC ASC loops and measures the response in the dither error signals.  It's gentle enough that it can be run in DC readout without breaking the lock.  Using the script I recalculated the dither control matrix and turned the dither loops back on; a screenshot of the new control matrix is attached.  They work, but I recommend very low gain - 0.05 on the OMC ASC master slider.  This reduces the UGF of the loops enough that noise is not being injected into the OMC alignment; with the gain too high there is clear scattering noise at low frequencies.  Enabling the dither gave the range a 1-2Mpc boost.  For now this is not in the Guardian, but we should start using the dither alignment.

If you use the script, keep an eye on the OMC SUS and make sure the offsets to the ASC loops don't saturate the drive.  If this happens your matrix will have a problem and you will not go to dither today.

Interestingly, the optimal alignment on the QPDs is different in the 2.3W and 23W states.  Is this due to some junk light in the DRMI?  For now I have left the QPD offsets to have the optimal low-power alignment, assuming that the dither will be engaged later on.  At high power the dither alignment pushes the OMC in pitch such that the outputs to the DAC are ~90k counts.  This seems like a lot to me, and we can't offload the drive anywhere, except perhaps some pico-motoring on the AS WFS to make the tip-tilts point the beam at a charitable angle.  We need to work out a HAM6 centering scheme that doesn't use the OMC SUS.

DARM Offset Scan

With the alignment into the OMC optimized I scanned the DARM offset at 2.3W input power and measured the DCPD Sum.  Plot attached; the curve is very well fit by a quadratic with a small static offset from the origin, about the same magnitude that Stefan, Keita and I observed two weeks ago - a few tenths of a picometer.  So, no surprises.  Note, the data points in the plot have error bars representing the 1-sigma statistical noise in the measurement, but they are too small to see.

In the second plot attached I have scaled the data to 125W input power, to make a comparison with Fig. 7 of the LSC design document (T1000298).  From this simple scaling it looks as though the DARM resonance we observe is much narrower than in T1000298...but I think I'm forgetting what parameters are assumed in Fig 7.  There was an error in my plotting - the data are a reasonable match to Fig 7 if a factor of 125/1.84 is applied to the DCPDSum, where 1.84 is the power incident on the PRM with 2.3W into the IMC.  (Note on this log-scale plot you can see the slight assymmetry in the data points, indicating a static DARM offset.)  Our standard low-noise, high-power configuration is 23W, and an offset of 1e-5 counts, which we think is 14pm.  With these settings we get ~18mA in DCPD Sum.

Other Notes

Tonight I've been increasing the ETMX roll mode damping gain to 200.  Also I've been engaging the DHARD rolloff filter (:12^2), this seems to improve the noise around 20Hz.

There is a very narrow line at exactly 3801Hz that I haven't seen before.  There's no sign of aliasing - the high-frequency features in DARM, as measured by the 64kHz DCPD channels from the DAC, have not changed dramatically.  The line has been slowly growing all night.  This could be an 8th harmonic violin mode of ETMY, although the exact integer frequency is a little suspicious.  I have added another notch to the ETMY_L3_LOCK filter bank, vStop8+9, but I have not turned it on.

Evening Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning 

16:00 Re-locking the IFO after several earthquakes 
16:45 Dale – Locking the LSB and leaving
17:00 Kiwamu - Damping the bounce and roll modes before full locking
18:35 Jeff – Running PCal TFs 
18:35 CS_WS_RO – alarm
18:40 – Bounce and roll modes low enough to try full locking
18:42 - Lost lock - Guardian recovering IFO
19:00 – Reset RO system
19:20 – IFO bounce & Roll modes low enough to try relocking
21:23 CS_WS_RO alarm – Will leave down for rest of the night
21:51 Jeff – Finished running TFs
21:52 Evan – Take IFO to 24.2w
22:00 Lost lock – Guardian recovering IFO
22:14 IFO locked at 24.2w
22:19 Lost lock – Guardian recovering IFO
22:36 IFO locked at 24.2w
22:42 Jeff - Turned down continuous wave injection by factor of 10
23:28 Set intent bit to Undistributed

J. Kissel, K. Kizumi, S. Karki

While trying to commit our results from last night to the CalSVN, we discovered that every folder was complaining that the it was not a working copy of svn, e.g.:

jeffrey.kissel@opsws5:/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts$ svn st
svn: warning: '.' is not a working copy

Totally confused, we went to the trunk of the repo, and it said messages about discrepant svn client versions:

/ligo/svncommon/CalSVN/aligocalibration$ svn st
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy.  Please upgrade your Subversion client to use this
working copy.


In order to make progress on the work stations (i.e. the h1boot server) Kiwamu made a back of the repo into 
/ligo/svncommon/CalSVN/aligocalibration_backup_20150530/
and made a fresh checkout of the repo, in the normal path:
/ligo/svncommon/CalSVN/aligocalibration
which regained its normal functionality.

He then started digging around the log history to figure out what happened and found a bunch of commits from the LHO PCAL team yesterday evening... and then Sudarshan joined us for a happy (??) Saturday discovery.

We've diagnosed the problem (a totally innocent user just doing what the computer told him to do -- he should not be blamed for any of this!!):
Sudarshan was at the End Station trying to check in pictures of PCal camera on (new? old?) CDS Laptop called cdsmbp0. He tried to do an svn st just to check on things, and an svn update before he committed (very good!), but he got the following error message:
[controls@cdsmbp0 Measurements]$ svn st
svn: E155036: Please see the 'svn upgrade' command
svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6)
[controls@cdsmbp0 Measurements]$ svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6)

He obediently then followed the instructions:
[controls@cdsmbp0 Measurements]$ svn upgrade
svn: E155019: Can't upgrade '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' as it is not a pre-1.7 working copy root, the  root is '/ligo/svncommon/CalSVN/aligocalibration'
[controls@cdsmbp0 Measurements]$ cd ../../../
[controls@cdsmbp0 Runs]$ cd ../../
[controls@cdsmbp0 aligocalibration]$ ls
branches tages trunk
[controls@cdsmbp0 aligocalibration]$ svn upgrade
Upgraded '.'
Upgraded 'trunk'
Upgraded 'trunk/Runs/'
#etc
#etc
#HERE'S A CRAZY BIT
Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-27'
Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-28'
nfs server cdsfs0:/ligo: not responding                               # <<< what the heck??
nfs server cdsfs0:/ligo: is alive again
Upgraded 'trunk/Runs/PreER7/H1/Measurements/DARMASDs/'                # <<< OK... moving on... ??
Upgraded 'trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/'
#etc
#etc
Upgraded 'branches'
Upgraded 'tags'
[controls@cdsmbp0 aligocalibration]$

This upgraded the hidden .svn configuration file in the entire repo in a way that is incompatible with any version of the svn client prior to 1.7. YUCK!!

It turns out that every computer does not source the svn client binary from the h1boot server as I would have imagined -- so this laptop was using its own copy of the svn binary /usr/bin/svn, which was of a later version than what is normally used on the work stations:
work stations: svn, version 1.6.17 (r1128011) compiled Aug 13 2014, 20:41:52
this laptop: svn, version 1.7.10 (r1485443) compiled Aug 13 2013, 15:31:22

What's worse, is that this "upgrade" to svn version 1.7.10 caused the entire h1boot server's copy repo to fail on the work stations as shown above immediately degrading the whole repo to just a normal unrepoed directory structure and it's not at all backward compatible. Even still more confusing -- svn version 1.6.17 doesn't even have an option to svn upgrade so we didn't believe (at first) what Sudarshan did was even possible.

Thankfully
- Sudarshan left the terminal open on this laptop so we were able to document everything that happened in great detail from this laptop's terminal session
- Kiwmau has made the back up mentioned above, 
- *and* Sudarshan ran an svn st after the upgrade on this laptop, so we know everything that wasn't committed of was modified. (see attached)
So nothing should be lost, we know the status of everything, and we can work to merge the backup back into the repo and move with out too much guess work.

However -- the SysAdmins (don't worry -- this wasn't your fault either!! This is a *terrible* backward compatibility issue with the SVN clients. I blame them!!):
 We should make sure all computers on site running svn cleint 1.6.17. IF and when we want to upgrade to svn client 1.7 or higher, we need to be absolutely sure that we do it to all computers at once.
OR we should demand that all computers are using a client that is hosted on the h1boot server, such that no computer is using an individual copy of an svn client.
 
#scaryscaryscary
#yakshaving

THIS ALOG DISAPPEARED FROM THE ALOG LAST NIGHT, THIS IS A REPOST.

J. Kissel, K. Izumi

I've finished the analysis of the calibration of the H1 SUS ETMY actuators that are involved with global DARM control, where we've used the "free swinging Michelson method" (i.e. using the IR laser's wavelength as a frequency / length reference). The results are as follows:

    'iStage'     '[m/ct] @ DC'    '1-sigma Unc.'
    'ITMX L2'    [ 3.9461e-13]    [    0.013313]
    'ETMX L3'    [ 8.0906e-14]    [    0.026998]
    'ETMY L1'    [  4.851e-11]    [    0.026588]
    'ETMY L2'    [ 3.8468e-13]    [    0.026885]
    'ETMY L3'    [ 1.4543e-15]    [    0.027057]

The messages:
- Kiwamu is still finalizing his analysis, but we can safely see that a similar calibration using the ALS DIFF VCO as a frequency / length reference agrees with the above results.
- Assuming the ETMX ESD driver's DC gain is 40 [V/V] and the new ETMY driver's DC gain is 2 [V/V], then this translates to an ESD force coefficient of
    'optic'      '[N/V^2]'
    'ETMX L3'    [2.21e-10]
    'ETMY L3'    [7.96e-11]
This means that the ETMY ESD drive strength is 2.78 times weaker than ETMX.
- Though we've used the  full complex transfer functions for transfer function ratios and multiplication to get the final answers for each stage, what discrepancies we find in the phase of the final transfer function that determines the magnitude answer are ignored. This is because we determine the phase response / frequency dependence of the DARM actuator and DARM Sensor collectively when comparing the DARM Open Loop Gain Transfer Function against a model of the full loop, e.g. LHO aLOG 18186.
Curiosities that don't affect the answer, but are none-the-less irksome:
- We need to flip the sign of the measurement of the ITMY L2 stage drive to MICH, the ETMX L3 stage drive DARM, and the ETMY L3 stage drive to DARM in order for the overall phase of the final results to make sense.
- The phase of the ETMY L2 stage is offset from the model by ~10 [deg]. 
- We'll now use the above numbers to change the DC calibration of the DARM model parameter file that has been used for creating the DARM loop model, compare against a DARM OLGTF measurement and therefore make a statement about the optical gain.
- This method of determining the actuation coefficient -- especially for the very weak ETMY L3 stage -- is *very* time consuming, cumbersome and only gets quality results in the 4 to 7 [Hz] band, therefore we should do it rarely if at all in the future. PCal should become our new standard technique of determining the actuation coefficients and these kind of measurements should be the checks!

-------
Details
-------
MEASUREMENT METHOD
A lot of the methodology for this calibration technique has been outlined before (see most recently LHO aLOG 14135, most clearly (IMHO) P0900120, and originally in T030097), but I'll repeat it briefly here, because one needs to understand how we've augmented the technique further in order to obtain the ETMY L3 actuation strength.

One begins with the measurement from which the technique gets its name:
(A) After locking and aligning the IFO into a dark Michelson configuration (with PRM, SRM, and the ETMs misaligned), break the lock and measure the AS port's demodulated Q-phase signal ("AS_Q") and DC power ("AS_DC") while the Michelson freely swings through fringes. For the aLIGO IFO, that's H1:LSC-MICH_IN1_Q (a scaled version of H1:LSC-ASAIR_A_RF45_Q_ERR_DQ) and H1:LSC-ASAIR_A_LF_OUT, and we grabbed ~300 [sec] worth of data. As the Michelson evolves through fringes the AS_Q error signal proportional to the displacement of the mirrors:

AS_Q = (1/2) * A_{pp} * sin( (4*pi/lambda) * dl )             (1)

where A_{pp} is the peak-to-peak amplitude of the signal, lambda is the laser wavelength, and dl is the Michelson displacement, (lx - ly). We assume that the displacement is small (thanks SEI team!) such that 

AS_Q ~ A_{pp} * (2*pi/lambda) * dl = k * dl                   (2)

leaving the AS_Q signal proportional to the Michelson displacement by a real constant, k, the optical gain of the Michelson. Over the years, we've found that simply taking the peak-to-peak of the fringing time-series is prone systematic errors in determining A_{pp} due to drifts in alignment during the long uncontrolled stretch. As such, we've taken advantage of the sin / cos relationship of AS_Q and AS_DC and plot the ellipse they form as the Michelson fringes. We chuck up the long time series into several smaller time series and plot the ellipses, fit each to determine the semi-major axis of the AS_Q vs. AS_DC ellipse, and take the mean of each fit's semi-major axis to determine A_{pp} (see first page of attached). Because the fit of each chunk is a measurement of the inherent value of A_{pp}, we assign the standard error of the mean (i.e. d(A_{pp}) = std( A_{pp}^{i} ) / sqrt(N) ) as the uncertainty. For this measurement, 

k = 1.112e+08 +/- 1.7181e+05 [(MICH Displacement [m])/ (MICH Sensor [ct])]


(B) We eventually want to drive a given stage of the ITMs to determine the actuation strength of that stage with our newly calibrated MICH sensor, MICH_IN1 (AS_Q). However, we need the Michelson locked on a dark fringe so that the MICH error signal remains linear. So we must measure the MICH loop suppression. Now with the MICH locked, measure the MICH_IN2 / MICH EXC loop suppression transfer function. A little bit of loop math will show that 

MICH_IN2 / MICH EXC = 1 / (1 + G_{M})                          

as desired. Note that one *could* measure the open loop gain transfer function, G_{M}, directly, as MICH_IN1 / MICH_IN2 = - G_{M}, but for ease of uncertainty propagation, we've just measured the suppression directly. The open loop gain and suppression are shown in pgs 2 and 3. The uncertainty for each frequency point is determined from the coherence of the measurement and the number of averages,

                         1 - C  
d|TF| =  |TF| *  sqrt ( ------- )  [ same units as |TF| ]
                         2 C N  
                                                              (3)
                  1 - C  
d <(TF) = sqrt ( ------- )   [ rad ]
                  2 C N   

ref LHO aLOG 10506, or originally Bendat and Piersol, "Random Data" 2nd Ed, p317.

(C) Pick any stage of either ITM and take a driven transfer function of iStage ITM drive to MICH_IN1. With the data from (1) and (2), create an absolute calibration of this [(MICH IN1 [ct])/ (iStage ITM drive [ct])] transfer function in terms of [m] by inverting the optical gain and loop suppression:

  ITM Optic disp. [m]      MICH IN1       1            
--------------------- = ( ---------- ) * --- * (1 + G)                                       (6)
iStage ITM Drive [ct]      ITM EXC        k           

                              MICH IN1 [ct]            MICH [m]        MICH IN2 [ct]  -1          
                      = ( --------------------- ) * ------------  *  ( ------------- )       (5)
                          iStage ITM Drive [ct]      MICH IN1 [ct]     MICH EXC [ct] 

Each frequency point of the loop suppression and itm drive transfer function's uncertainty is determined by Eqs. 2 & 3, and are propagated to the uncertainty in each frequency point of the overall calibration by adding the relative magnitude and phase in quadrature. To compress each frequency point into an assessment of the overall DC actuation strength of that stage, we divide the resultant transfer function by a model of the actuation from that stage to it's optic. This way, if we've modeled the actuation strength as a function of frequency correctly, each frequency point becomes an independent measure of the overall strength of the actuator. As such, the single number and uncertainty for this stage is formed by the weighted mean and chi-squared weighted variance in the weighted mean,

          sum (x_{i} * sigma_{i}^{-2}) 
bar{x} =  ----------------------------                                                       (7)
             sum ( sigma_{i}^{-2} )                                                          Wikipedia
                             1                  1             (x_{i} - 1)^2
sigma_{bar{x}}^2 = ---------------------- *  ------- * sum ( --------------- )               (8)
                   sum ( sigma_{i}^{-2} )    (N - 1)           sigma_{i}^2                   Wikipedia
     

(D) The rest of the game is just using various parts of the interferometer to propagate this known "reference" actuator's absolute calibration to other optics. This is done by locking up a configuration that involves the reference actuator and actuator / optic you want to calibrate, and measuring the response of that IFO to both drives and taking the ratio of transfer functions:

  Optic Disp [m]           MICH [m]           ITM EXC [ct]        Some IFO [ct]
------------------   = ( ----------- ) *  ( -------------- ) * ( ----------------- )          (9)
iStage Drive [ct]        ITM EXC [ct]        Some IFO [ct]       iStage Drive [ct]

and the uncertainty is propagated in the same way as described in step C -- the frequency points of each new transfer function's uncertainty is determined by the coherence and number of averages, the uncertainty in the frequency points of the resulting product are the quadrature sum of the component TFs, the absolute calibration of the stage to optic is divided by a model, and the hopefully unity magnitude residual's weighted mean and weighted uncertainty are taken as the absolution calibration.

We found out Wednesday that the former method used in prior IFOs /science runs of just using a single arm IFO and propagating directly to the ETM doesn't work for the lowest strength actuators (i.e. ETMY L3) because the frequency noise of the Single Arm pollutes the measurement enough that one cannot get any coherence. As such, we've used many measurements to propagate the the absolute calibration to the ETMY L3: using the X single-arm to propagate ITMX L2 to ETMX L3, and then the full IFO in DC readout to propogate ETMX L3 to each stage of ETMY, e.g.

   ETMY L3 [m]         MICH [m]          ITM EXC [ct]        XARM IN1 [ct]         ETMX L3 EXC [ct]     DARM IN1 [ct]
---------------- = ( ----------- ) *  ( -------------- ) * ( -------------- ) * ( -------------- ) * ( --------------- )         (10)
ETMY L3 EXC [ct]     ITM EXC [ct]        XARM IN1 [ct]        ETMX L3 [ct]         DARM IN1 [ct]       ETMY L3 EXC [ct]


So if you're keeping track, that's six transfer functions and and a time series we have to take, and the transfer functions all need to take up a lot of time to get enough coherence that the uncertainty doesn't blow up. It's an all day adventure just to get all of these transfer functions. Thankfully, because of Kiwamu's care in getting the coherence super high, we still manage to get good data with reasonable error bars between 4 and 7 [Hz]. Any higher a frequency than this, and the original ITM to MICH transfer function hits the MICH noise floor. Below 4 [hz] the ITM to ETM transfer functions with the single arm loose coherence from frequency noise. So in addition to the many transfer functions we have to take, we only get a small frequency band where we can really get any sort of precision, and MICH isn't good enough to let us measure into the gravitational wave band.

WHERE EVERY THING EXISTS
The raw .xml files live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-28/
2015-05-28_H1DARM_ETMX_L3_Drive.xml
2015-05-28_H1DARM_ETMY_L1_State1_Drive.xml
2015-05-28_H1DARM_ETMY_L2_State2_Drive.xml
2015-05-28_H1DARM_ETMY_L3_LVLP_Drive.xml
2015-05-28_H1MICH_freeswingingdata.xml
2015-05-28_H1MICH_ITMDrives.xml
2015-05-28_H1MICH_OLG.xml
2015-05-28_H1XARM_ETMandITMDrives.xml
which have been exported to .txt files with corresponding _ts, _tf, or _coh tags to indicate the contents.

The analysis is done with 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/analyze_mich_freeswinging_data_20150528.m


Stay tuned for more actuation coefficient measurement technique comparisons, and an update to the DARMmodel, and therefore the CAL-CS and GDS calibration pipelines, and therefore the DARM spectrum and Inspiral range.

Kiwamu, Jeff, Dan, Cheryl, Eric

We successfully tested the transient injection code tinj at LHO for the first time.  This is also the first test of tinj since we added interaction with EPICS channels and migrated to svn.  An earlier version had been previously demonstrated at LLO.  The tests were carried out between GPS = 1117004777 - 1117006270.  We scheduled the standard BNS injection (1.4 on 1.4 msun with optimal orientation at 45 Mpc) that has been used in previous tests [1].  This file, which lives in svn, is called injection_H1.out.  The goal of the test was to inject this waveform with increasing loudness until the folks at LHO could see the signal sweeping across the strain spectrum.

The first attempt failed to inject because H1:CAL-INJ_TINJ_ENABLE = 0.  We set the value to 1.  The next several attempts (GPS = 1117004777, 1117004993, 1117005152) failed to show up because the transient gain in the CAL model was set to zero.  We set it to one and started over.  The following injections were successful:

1117005396 2 1 injection_
1117005598 2 4 injection_
1117005756 2 10 injection_
1117005914 2 100 injection_
1117006170 2 100 injection_

The first column is GPS time, the second is injection type (2 = CBC), the third is scale factor, and the last column is the prefix for the injection file.  Dan and Kiwamu weren't 100% sure they were seeing the BNS signal until we injected with a scale factor of 100.  During the last injection, (scale factor = 100), Jeff and Eric watched the output of HWINJ filter bank.  At the very end, it reached a value of ~50 counts, which did not exceed the current HWINJ LIMIT  = 200.

We fixed a bug with tinj.  First, we fixed a bug, in which the value of TINJ_PAUSE was interpreted incorrectly (1 should have been 0).  Also, the binary executable for tinj included in svn yielded a library error:

tinj: error while loading shared libraries: libmwlaunchermain.so: cannot open shared object file: No such file or directory

So, we recompiled a version that works at LHO and recommitted to svn.  NOTE: we have left tinj running in the background for a stability test.  However, there are no planned injections currently scheduled.

[1] https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=17073