The crew has been able to clean 680 meters of Y-Arm beam tube including vacuuming and capping the support tubes in that same distance since Feb. 5th, some of which time was spent at LLO. The most recent stopping point is at HSW-1-041. 
Test results are posted here. 

As part of the VE control system upgrade at EX we had to redo the PI controller to maintain the level of the tank.  Though settings are not optimal they will certainly work with some small overshoot. Settings are Gain 6. Integral 360, Derivative 0.  ideally I would like to eliminate the overshoot but this system is so slow I want to let it run like this for a couple of days.  Will be good to see what happens Tuesday when the LN2 get delivered.

When we shook every chamber with external shakers, the BS chamber produced the most upconversion. The peaks produced by line injections have large side bands, suggestive of scattering (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25132). Figure 1 shows photographs of things that might move in the light when the BS isolation shakes. These are pictures from the point of view of the beam spot on an ITM compensation plate or a beam spot on the BS itself. The ITM eliptical baffle is an obvious candidate. The baffle is mounted on stage 0 of the BS isolation. To test that it might be scattering, I shook stage 0 and stage 1 on Monday at two slightly different frequencies. The results in Figure 2 are consistent with scattering from something on stage 0, but not stage 1 or 2. I think we should B&K test the ITM elliptical baffles at LLO to get resonances for further testing of the hypothesis that we are seeing scattering from the ITM elliptical baffles.

I reset the ITMY HWS magnification to 7.5x (it's set to 17.5x by default in the code).

aidan.brooks@opsws4:~$ caput H1:TCS-ITMY_HWS_MAGNIFICATION 7.5

Old : H1:TCS-ITMY_HWS_MAGNIFICATION  17.5

New : H1:TCS-ITMY_HWS_MAGNIFICATION  7.5

Alos, I had a quick look at the change in the spherical power measured by the ITMY HWS after the IFO lost lock this morning.

1. The measured change in defocus was, very roughly, 0.8 micro-diopters. (over about 40 minutes taken from immediately after 1141749205)
2. Around 95% of the lens forms/decays in this time. 
3. The magnification was set to 17.5 instead of 7.5, so we need to multiply the spherical power by (17.5/7.5)^2 = 5.44x
4. The steady-state, double-passed, lens measured by the HWS is then 8E-7/0.95*5.44 = 4.6E-6 diopters
5. The single-pass, steady-state, lens is then 2.3E-6 diopters
6. The single-pass, steady-state, lens gain (diopters per Watt absorbed) is 4.87E-4 D/W for self absorption
7. Therefore I calculate about 4.7mW absorbed power in ITMY
8. The arm power was around 11.9kW during this time
9. Hence, the absorption is (very roughly) 4E-7

This is a very rough calculation - and assumes that the HWS-Y beam is correctly aligned (we need to combine our evidence to really confirm this).

Nevertheless, I've set the ITMY absorption to 4E-7 in the simulation.

aidan.brooks@opsws4:~$ caput H1:TCS-SIM_ITMY_SURF_ABSORPTION 4E-7

Old : H1:TCS-SIM_ITMY_SURF_ABSORPTION 4e-09

New : H1:TCS-SIM_ITMY_SURF_ABSORPTION 4e-07

For comparison, ITMX absorption estimated to be 5.7E-7.

Some of the peaks in Kiwamu’s cross spectrum match PSL jitter peaks (see figure). The figure also shows that estimated ambient levels at some peaks are just factors of 2 or so below DARM. It is not clear how much the periscope work in September improved the peaks between 70-250 Hz, because the post-O1 injection was not loud enough to bring up the peaks in this region, just loud enough to show things were the same or better. I should do louder PSL injections as they may help distinguish between jitter peaks and a broad-band background in this region.

On Monday morning, the winds were too high to make much progress locking, so Sheila and I took some time to look at optic motion when using narrow band sensor correction. Because we couldn't get very far locking, we left the optic aligned and looked at the oplev. The 3 configurations I looked at were : sensor correction using the buried seismometer, no sensor correction and sensor correction using the building seismometer. First attached plot shows the oplev pitch for the 3 configurations, red is using the buried STS, blue is no sensor correction and green is with the building STS (this scheme holds for the other plots, too). Using sensor correction definitely improves pitch at the microseism (as expected, based on my design). Using the building STS seems to do a better job of suppressing the microseism, but injects tilt below the microseism (as expected), although I don't trust the oplevs much at low frequency as length to angle coupling gets worse. Second attached plot shows the building STS spectra for the 3 measurements, mostly pretty similar, though the low frequency motion on the green trace (while using the building STS) was the worst of the 3 measurements, maybe explaining at least some of bad low frequency motion at the oplev. The last plot is the minute trend of the wind over the time of the measurement. As usual, more investigation needed. I tried a different configuration this morning, using blend with the 2 STSes. I'll post that data in a while.

I logged in this morning to check how the ITMY-HWS ran overnight. It seemed to be running relatively normally until around 2:50UTC when it just stopped (HWSX was running fine).

I logged into H1HWSMSR and attached to the tmux session. Through some investigations and irregularities, I eventually realized that there were three tmux sessions running and two instances of the HWSX and two instances of the HWSY code running. Clearly this is not ideal.

We'll have to figure out how to prevent additional tmux sessions from being started, but until then, please take care not to start extra sessions (always use the syntax tmux attach).

I don't know if multiple sessions fighting each other are the reason that the HWSY code stopped taking data, but I can't imagine it helped things.

I killed all HWS code (Run_HWS_ITMX, Run_HWS_ITMY), killed all but one tmux session and then restarted the HWS code. I also added a line to the .bashrc file to indicate the number of active tmux sessions when you log in.

The landscape crew has cleared X & Y access roads of tumbleweeds (for the moment) and will be starting to bail on the inside of the X arm this morning. The tumbleweeds typically build up on the inside of the arms against the tube enclosures and when the pile gets high enough even a small gust of wind will start to blow them over the tube and landing on the road again blocking the access road. Hopefully we can get ahead of this pile on the inside and keep the roads clear for a while longer. 

TITLE: 03/11 day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind Avg: 7 mph
    Primary useism: 0.03 μm/s
    Secondary useism: 0.31 μm/s 
QUICK SUMMARY:IFO locked on ENGAGE_ASC_PART3 since 09:04:05UTC.

Jenne, Hang, Robert Ward, Stefan, Matt, Lisa

Today we spent some more time on ASC

1) We realized that ASB36 has the DC centering and SRM both orthogonal to the BS signal, so this is a better signal to be using for BS than 36A. We swithced to this, and also switched SRM to ASB36 I, since we saw that the error point was good for SRM in full lock when we have MICH controlled with ASB36 Q.  This loop is not insensitive to the centering (it is basically parallel), but we seem to be OK.  

2) 25999

3) We have the CHARD at high bandwidth in the guardian, although this is quite rough and we need to think about how to engage it more smoothly.  

4) We have measured several sensing matrices, Hang will post them.

5)We are able to engage the soft loops even when they all have ofsets of about 0.1, and they converge very slowly without bringing our buildups down, with all the rest of the ASC on.  We think this means that we don't (at least not any longer) have a problem with error points changing, but we might still have a problem with loops are cross coupled.  We have done this 3 times now. 

We are now having trouble with the OMC locking, it seems to be locking on the side of the fringe, even though the dither line is supressed.  We tried a bust restore (the computer was restarted today.) but that hasn't solved the problem.  We will come back to this tomorow. 

Kiwamu, Matt

Thanks to the new cross-correlation data, we can make an updated mystery noise budget.  This time, the recently remembered RF AM noise is included.  There is some calibration correction required to make the uncorrelated noise flat (zero at 193Hz, pole at 215Hz), but this might be expected due to calibration drift over the run.

The curves on the attached plot are:

• black - total measured noise
• grey - measured cross-correlation
• yellow - measured cross-correlation minus correlated noise (including mystery noise)
• purple, red, light blue - known quantum, coating thermal and RF AM noises
• green - a 1/f² mystery noise.  This is the shallowest slope and highest value that seems to make sense.
• blue - sum of known noises and mystery noise
• orange - same as blue, but without shot noise (so, just correlated noises)

The conclusion is that there is no "great mystery noise" any more.  It looks like the unaccounted for noise, in this simple noise budget, is mostly just scattering peaks.  A 1/f² curve is included to give the total a reasonable shape and to guide the eye, but it shouldn't be taken too seriously.  (See 23350 for a real H1 budget, and 25092 for L1.)

Suggested course of action:

1. work on reducing the shot noise (increasing the power)
2. and the scattering between 60 and 100Hz
3. look for coherence between 45 and 55Hz

TITLE: 03/10 day Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ed
QUICK SUMMARY: ASC work still on going.
 

J. Kissel

While helping Nairwita debug the HAM-ISI noise budget model, I've found myself dreadfully ignorant of the HAM FF design which Jim has worked so hard. In this aLOG, I show and explain as much information as possible on the design of the filter, just that it (hopefully) becomes clear. This documents the design original elluded to in Jim's LHO aLOG 19292.

------------
Units.
Let's start at the overview screen, HAMISI_OVERVIEW.png. The filter banks marked as "FF" are our path, and notice that we have the option of using either the HEPI L4C or in-vac ST0 L4C sensors (both intertial sensors of the same time, just in different locations). For reasons to be discussed elsewhere, we've chose the ST0 L4Cs. Also recall that these L4Cs, like every ISI inertial sensor, has been *partially* calibrated, such that the high-frequency velocity response asymptotes to a flat 1 [nm/s], and rolls off at low-frequency as f^2, where the corner frequency for all instruments has been modified to be 1 [Hz], with a critically coupled Q of sqrt(2)/2. In short, we'll call these "velocity cts." The L4Cs are projected into the ISI's Cartesian basis and is piped into the FF filter where the green pepper is shown.
The output of the filter (indicated by the small explosion) is added into the feedback isolation loop path at the control point. That mean the output of the FF filter must be in the same units as the output of the feedback loop. Though we know the calibration from these "force counts" to N, we don't calibrate it in real-time, because we want to keep the control scaled to DAC counts, as per LIGO convention. 
That means the filter must have units of 
   (force ct) / (ST0 L4C velocity ct)
when installed into foton.

The Ideal Filter
Recall the point of feed-forward: to minimize the forces on the suspended stage. There are two mechanical forces on the stage:
    (1) Motion of ST0 couples through the mechanical plant and forces ST1 to displace. This transfer function is simply the stiffness of the springs.
    (2) Control forces from ST1 actuators displace ST1.
Using the notation from T1300645, 
    (1) = P^{'(0-1)} = "damped displacement plant" = fundemental units of [m/m] and 
    (2) = P^{'(1-1)} = "damped force plant" = fundamental units of [m/N].
In the absence in of any sensor corrected feedback control, that means the ideal filter, F^{FF} filters the control force such that it perfectly balances the input motion of the displacement plant
   F^{FF} P^{'(1-1)} + P^{'(0-1)} = 0
which we can manipulate to get an expression for the ideal filter:
   F^{FF} = - P^{'(0-1)} / P^{'(1-1)}
We immediately find was we expect -- the units of the above equation cancel out nicely to have the same units as a stiffness: [m/m] / [m/N] = [N/m]. The problem: this design process requires you to have a very good measurement (or model) of both P^{'(1-1)} and P^{'(0-1)}. While our actuators are strong enough to characterize the driven transfer function, P^{'(1-1)}, with oodles of coherence, we must rely on what SNR  we get get out of the residual ground motion to determine P^{'(0-1)} (i.e. coherence between our ST0 sensor and our on-board ST1 sensor)

Where / why we use Sensor Correction vs. Feed Forward
In reality, we have a sensor-corrected feedback system that's also trying to suppress the motion of ST1 at low frequency. That feedback loop alters the shape of the displacement and force plants in the region where the feedback loop gain is large. In this region, it reduces the coupling of the ST0 motion ot ST1 motion (i.e. P^{'(0-1)}) to essentially zero. Thus, we can only use feed-forward where the loop gain is small, and there remains enough coherence between ST0 and ST1 that P^{'(0-1)} can be measured well enough to design the ideal filter. In practice, that turns out to be between about 5-30 [Hz] for the HAMs.
Where the loop gain is large (below 5 [Hz]), we correct for excess coupling of ST0 at the error signal instead of the control signal, i.e. sensor correction. In a sense, this is also feed forward, (and in fact the filter design process is strikingly similar) but the injection point is ahead of the control filter and hence we distinguish it with different nomencalture. On advantage of sensor correction over feed-forward: the filter need not change if the feedback design changes (which is not true for feed forward, since both P^{'(0-1)} and P^{'(1-1)} are modified by the feedback loop suppression). One drawback of sensor correction: it relies on the feed-back loop gain. Feedback stability is quite restrictive at high frequency. Thus we use feed-foward to where-ever there is residual coherence in the P^{'(0-1)}.

The Measurements
We want to improve the isolation from 5-30 Hz, beyond what sensor-corrected feedback can do. So, all measurements are taken with the sensor correction and feed-back loops closed. For P^{'(1-1)}, one drives at the excitation point of the (at this point empty) feed-forward filter bank, and measures the response of ST1 (in the case of the HAM, we use the ST1 GS13 inertial sensors). In raw form, that means this "driven" TF measurement has units of
    P^{'(1-1)} = (ST1 GS13 velocity ct) / (ST1 force ct)
               = H1:ISI-HAM4_BLND_GS13Z_IN1_DQ / H1:ISI-HAM4_FF_Z_EXC
where the GS13s have been partially calibrated in the same manner as the L4Cs. For P^{'(0-1)}, with no drive, one measures the "passive" TF between the ST0 sensor and the ST1 sensor,
    P^{'(0-1)} = (ST1 GS13 velocity ct) / (ST0 L4C velocity ct).
               = H1:ISI-HAM4_BLND_GS13Z_IN1_DQ / H1:ISI-HAM4_FF_Z_IN1_DQ
Because the L4C and GS13s have both been calibrated in the same fashion, that means that the ratio of these transfer functions are already in exactly the right units for the ideal filter:
    F^{FF} = - P^{'(0-1)} / P^{'(1-1)} = (force ct) / (ST0 L4C velocity ct)
Though it's not needed for the filter design, if you want to model the platform motion in physical units, you've got to do a little unit juggling. From Eq. 9 in T1300645, the two terms concerning feed-forward are 
    z_{ST1}^{FF} =   P^{'(0-1)} / (1 - e G') z_{ST0}
                   + P^{'(1-1)} / (1 - e G') F^{FF} z_{ST0}
so if you which to input motion of z_{ST0} in displacement units, say [m], and you have a force plant in units of m / (force ct), then you'd better convert whatever filter you pull out of foton into units of [(force ct) / m], i.e. finish the calibration of the L4C by removing the displacement response,
    cal_m_p_ct_L4C.c   = (1/nm_p_m) * zpk([0 0 0],-2*pi*pair(1,45),prod(2*pi*pair(1,45))/(2*pi).^2);

The fit vs. cutoff-frequencies
On you have the measurement, and have computed the ratio of the two transfer functions, whereever their remains coherence in the measured P^{'(0-1)} measurement you want to fit that ratio as best you can. Outside of this region, you want to roll-off the feed-forward control as quickly as possible, while still maintaining as much fidelity of the in-band filter as possible. The pdf attachment reverse engineers Jim's design, with a whole bunch more labels, and shows the transfer function ratio cast into a few different units for comparison.

For a model of the predicted performance of the design -- we need Nairwita's work, since the performance depends on models of the feedback loop and force plant. Hopefull we'll get there soon!

Details:
You can run the script that generates the design study here:
/ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM4/FilterDesign/FeedForward/designstudy_h1isiham4_ff_Z_20160310.m
as long as you update the following folders:
/ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM4/Data/Transfer_Functions/Measurements/Isolated/  << to get all of the recently committed data
/ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/ << to get a new function readdttexport.m

Related to alogs 25918, 25975, 25768

I have confirmed that the calibration of my cross spectra is accurate and deviation is as small as 1% at 36 Hz and smaller at higher frequencies.

The plots above show the time evolution of the peak height at 36.7 and 331.9 Hz. Because they are driven by Pcal, they should stay unchanged throughout the run if the calibration has been properly done. The line at 36.7 Hz showed a good stable calibration most of the time and had a upward trend. Overall, I would say it is as good as 1%. For comparison, I plot the peak height from the C01 frame. As expected the line height changed by ~ 7% which is presumably due to the test mass charge.

The other line at 331.9 Hz showed a very good stability throughout the run. The deviation is much smaller than 1% as seen in the plot. In contrast, the C01 data showed more active variation throughout the run by roughly 6% peak-to-peak.

Sheila, Jenne, Hang, Rob, Lisa, Matt, Stefan

Comparing the AS port WFS DC centering vs RF90 centering we came across the following observation, that in retrospect makes perfect sense, put certainly was initially surprising to me:

Observation:

We are in DRMI-locked, no arms, i.e. the light at the AS port is completely dominated by the 45MHz fields. Moving the OMs in pitch (e.g. up) we see both DC- and RF90-centering signals move up. But moving the BS in pitch sends the two centering signals in opposite direction.

Why?

Since we only have the two 45MHz fields contributing, the only way to get the DC- and RF90-centering signals to disagree is to have BOTH a spatial mismatch AND amplitude difference between the upper and lower sidebands. A BS misalignment will generate upper and lower sideband with opposite sign (because they are passed on opposite sides of the MICH fringe), thus taking care of the spatial mismatch. The SRC cavity passes the upper and lower  at a different location, thus creating the amplitude mismatch.

Below is a plot of the centering loops response to a BS move (at the -1 min mark) and a OM move (at the 0min mark).

During O1 run we have monitored slow variations in the DARM actuation and sensing functions with several ~35 Hz and a ~350 Hz line at both observatories.

Systematics in the actuation function mostly affect systematic errors at frequencies below UGF, while systematics in the sensing mostly show up at higher frequencies.

Variation in the DARM sensing is parametrized with an overall sensing gain κ_C and a cavity pole frequency f_C. Most dramatic changes in both of these parameters appear in the beginning of locks, which could be a result of changing of cavity modes due to thermal heating of test masses and possibly some other effects.

Variation in the DARM actuation is parametrized with κ_TST and κ_PU. The κ_TST is a scalar gain factor of the ESD driver actuation which drives only the TST stage. We believe that it changes mostly due to charge accumulation on the surface of an ETM. The κ_PU is a scalar gain factor of the actuation functions of the upper stages PUM and UIM. The coil-drivers as used to for actuation of these stages. We do not believe that κ_PU should change over time, but monitoring it helps to make sure that we do not miss any slow variations that we did not account for.

Time-frequency plots of the known time-depedent systematics in the overall DARM response function calculated from κ_TST, κ_PU, κ_C and f_C in O1 run are attached.

Update: replaced figures (portrait -> landscape orientation) for convenience.