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).

March 11 01:24 UTC: I'm heading out and leaving the CP8 LLCV on manual control at 50% open. Currently the LN2 pump level is around 88%.

John noticed that some of the new EX VAC channels could not be minute trended back past 29th February. This is because the minute trends were offloaded from h1tw1 on that day. Similar to the renaming of the min trend files from their old HVE names to their new H0:VAC names on the running system, this was also done on the minute trend archives on h1fw0 and h1fw1 for all past data.

model restarts logged for Wed 09/Mar/2016 No restarts reported

model restarts logged for Tue 08/Mar/2016
2016_03_08 11:35 h1asc
2016_03_08 11:42 h1isiitmx
2016_03_08 11:43 h1isiitmy
2016_03_08 11:45 h1isibs
2016_03_08 11:48 h1isietmx
2016_03_08 11:49 h1isietmy
2016_03_08 11:54 h1broadcast0
2016_03_08 11:54 h1dc0
2016_03_08 11:54 h1nds0
2016_03_08 11:54 h1nds1
2016_03_08 11:54 h1tw1
2016_03_08 18:20 h1dc0
2016_03_08 18:21 h1dc0
2016_03_08 18:22 h1broadcast0
2016_03_08 18:22 h1dc0
2016_03_08 18:22 h1nds0
2016_03_08 18:22 h1nds1
2016_03_08 18:22 h1tw1
2016_03_08 18:26 h1broadcast0
2016_03_08 18:26 h1dc0
2016_03_08 18:26 h1nds0
2016_03_08 18:26 h1nds1
2016_03_08 18:26 h1tw1

maintenance day. New ASC and ISI models. DAQ restarts for model changes and new EX vacuum controls channels. Bad DAQ restart at 18:22 due to duplicate channels.

model restarts logged for Fri 04/Mar/2016 - Mon 07/Mar/2016 No restarts reported

model restarts logged for Thu 03/Mar/2016
2016_03_03 10:18 h1asc
2016_03_03 10:36 h1dc0
2016_03_03 10:38 h1broadcast0
2016_03_03 10:38 h1nds0
2016_03_03 10:38 h1nds1
2016_03_03 10:38 h1tw1
2016_03_03 15:51 h1asc
2016_03_03 15:55 h1ascimc
2016_03_03 15:56 h1asc
2016_03_03 16:00 h1dc0
2016_03_03 16:00 h1tw1
2016_03_03 16:02 h1broadcast0
2016_03_03 16:02 h1nds0
2016_03_03 16:02 h1nds1

maintenance thursday. ASC model change with DAQ restart. Later ASC and ASC-IMC changes with DAQ restart.

model restarts logged for Wed 02/Mar/2016 No restarts reported

model restarts logged for Tue 01/Mar/2016
2016_03_01 08:23 h1isiham4
2016_03_01 08:23 h1isiham5
2016_03_01 11:46 h1susitmy
2016_03_01 11:48 h1susetmy
2016_03_01 15:29 h1tcscs
2016_03_01 15:33 h1broadcast0
2016_03_01 15:33 h1dc0
2016_03_01 15:33 h1nds0
2016_03_01 15:33 h1nds1
2016_03_01 15:33 h1tw1

maintenance day. ISI and SUS model changes. Later tcs model change with associated DAQ restart. DAQ restart also complete raw-min-trend offload

model restarts logged for Mon 29/Feb/2016
2016_02_29 10:39 h1nds1
2016_02_29 11:04 h1nds1
2016_02_29 14:48 h1sysecatx1plc2sdf
2016_02_29 14:55 h1sysecatx1plc2sdf

Minute trend offload from h1tw1 started. Beckhoff SDF work.

[Kiwamu, AIdan, Elli, Cao]

Following from alog 25905, we attempted to realign the beam spot, which is suspected to be the  beam reflected from the HR surface of ITMY onto Hartmann sensor. In order to do this:

    1. Turn off CAGE SERVO, misalign the SR3 to the PITCH and YAW values:

                      PITCH: 1458

                      YAW:    -216.9

     2. Since this beam is most far off from the nominal values in PITCH, we start walking the SR3 PITCH back to the nominal value (563.4. At the nominal value, a beam is centered onto HWS, which we suspected it to be the one refleced from AR surface). The walking is done in in increment:

                 - Decrease the PITCH of SR3 until the beam of interest moves up sightly off the amera active surface.

                 - Start decreasing the PITCH of the upper periscope, then decrease the PITCH of the lower periscope to compensate. This essentially translate the beam upward, bringing the beam of interest back down into the image frame of HWS.

    3. After moving 400 radians in PITCH closer to nominal value, the SLED beam was clipped on the upper periscope mirror (2'' mirror). Initially prior to adjusting the periscope mirror, the beam was at the center. Therefore, a change in 1/sqrt(2) inch helps achieving a change of 400 rad in PITCH. At this point, the green beam in also close to upper edge of  th upper periscope mirror. We then moved the upper periscope upward by 0.7 inch order to accomodate another 400 rad change in PITCH of SR3 to move closer to nominal value.

   4. After reposition upper periscope mirror, we repeated the similar process of walking SR3 back to nominal values and tilting the upper periscope mirror. However, once achieving SR3 PITCH of 880, we started seeing clipping. Using IR viewer to look into the viewport, Kiwamu identified that the the beam is cipping on the top edge of the in vacuum lens (which was also the wong lens installed).  We noticed that the green beam was at the bottom of the upper periscope  mirror. We wondered if there was any separation between SLED beam and the green beam of the case of ITMY HWS, considering the y beams pass through SR2 and a wrong in-vacuum lens. We will need to check with Aidan for some ray-tracing model to investigate this.

   5. Due to this clipping,we could not proceed walking the desired beam onto HWS at SR3 nominal PITCH and YAW values. We then moved the upper periscope downward to initial position, misalign SR3 such that the HR beam candidate was centered onto the HWS and started the ring heater test. Each RH segment were turned on to 2W and we observed the measured spherical power from the HWS, compared to the simulation. This was indeed the first beam that we observed changes when RH is applied. However, looking at image RH_ITMY_9Mar.png , we noticed the trend of change did not follow what we expected from the simuation:

         i. When RH is on,we expected the spherical power to decrease, what observed was the opposite in which the spherical power measured increased with time. 

         ii. The rate of increase in spherical power was much lower than the simulated rate of decrease. Whereas in my recent study of the RH model for X-arm, the magnitude of spherical power simulated is much smaller than measured data. 

         iii. The measurement of spherical power was very noisy.

        For the first two points, I suspected it's either:

         1/  The beam may not be centerd on the test mass but off slightly to one side and what we're getting is an artefact .

         2/ The magnification and the change to a concave lens (the wrong in-vaccuum lens) have not been accounted for correctly, thus resulting in a flip of wavefront, giving rise to increase in spherical power measured.

      Either way, I will have a look at the gradient plot tomorrow and see if we can do some ray tracing modelling to identify where the problem comes from.

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.

I have extended the cross spectrum analysis (see 25009 and its comments) to the entire O1 run.

Preliminary conclusions are that:

• Noise in 80 -160 Hz seem to have fluctuated by about +/- 20%.
• Noise in 80 -160 Hz seem to have kept the same spectral color.

I will dig into some interesting days or periods and study how different things were.

[Setting up band limited rms]

To analyze the cross spectrum as a function of time, I decide not to do spectrogram type analysis which may contain too much information. Rather I wanted to study the time evolution of the band limited rms. This approach is very similar to what Gabriele does (e.g. 22514).

I selected eight interesting bands in which I avoided tall peaks in the spectrum because I am not interested in their amplitudes in this study. The attached below shows the eight selected frequency bands.

The frequency bands are chosen as follows,  Band 1 = [20 25], Band 2 = [30 35], Band 3 = [50 55], Band 4 = [81 95], Band 5 = [101 110], Band 6 = [121 126], Band 7 = [130 140] and Band 8 =[150 156].

[Time-varying calibration parameters are corrected]

I have corrected for all kappas, the time varying calibration parameters, by applying them to the H1 DARM model of the calibration group. Since one cross spectrum is produced from a twelve minutes integration, kappas are also averaged for twelve minutes. Therefore, the data sets that I analyzed here must be less sensitive to calibration errors due to the time varying parameters which can deviate roughly by 10% from the reference values.

[Glitches and transients are removed]

I have removed data segments that were contaminated by some glitches or transients because I am not interested in their characteristics. This was done by computing an average Rayleigh static over the frequency range from 60 to 100 Hz and rejecting the segment which had a Rayleigh statistic deviating from unity by more than 10%. So the data set I analyze here has more or less good Gaussianity.

[Result 1: time evolution]

The attached plot below shows the band limited rms of the selected eight frequency bands as a function of time in days starting from Sep-01 00:00:00 UTC.

Typically, the two lowest bands (band 1 and band 2) vary more than the others presumably due to the fact that they can be easily degraded by seismic activities, alignment loop and LSC feedforward. In contrast, the rest of high frequency bands (bands 3 -8) are more stable but still do fluctuate. Notice that the high frequency bands decreased their rms at t = 50 days or so. I believe that this is due to Robert's improvement of reducing the PSL jitter coupling (22497). Also, one can find many interesting periods where one of the bands increased the displacement while the rest stayed unchanged and so on. I will try to check those interesting days later.

The fluctuation of the four highest bands (bands 5 -8) are at 15-20 % level (or 30-40 % in peak to peak) with high sigma data points excluded.

By they way, I forgot to multiply sqrt(df) with df being the frequency resolution to all the band limited rms . The frequency resolution df is currently 0.1 and therefore all the data shown in the above plot should be lowered by a factor of sqrt(0.1) = 0.3. This does not change the main conlusions.

[Result 2: behavior of the high frequency bands]

Now, the plot below shows a primitive correlation plot.

where the horizontal axis represents the displacement of band 8 and the vertical axis is for the rest of the bands in order to show correlation with band 8. I have excluded the first 50 days in which the high frequency noise was higher due to the PSL jitter coupling. By the way, the x-axis is in log scale although it may look linear to some people. As seen in the plot, bands 4-7 show a positive correlation with band 8. Also their slopes seem to be identical. These indicate that noise level above 80 Hz fluctuate in such a way that it keeps the same spectral color. As mentioned above, the size of fluctuation is about 15-20% for bands 4-8.

All the data in the above plot should be lowered by a factor of 0.3 for the same reason as the time series plot . This does not change the main conlusions.