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.

Re ISI offloading SUS ISI M0 motion calibration--Looks like it works just fine

As the SUS model is running at 16khz and the ISI is running at 4khz, thought it best to confirm the calibration filters are easily ported to the other model.  The CAL filter running on the ISI (just ITMY for the moment) is just a copy of the SUSpension Cal filter.  Gratefully, the SUS filter bank had a 4k to 16khz filter to process the GS13 data coming from the ISI.

Spectra shows the comparision with solid coherence out to 100hz whereafter it falls off  by a few 100s of hz.  Well that is only true with a 1hz bw.  When I do a .01bw spectra, the coherence starts to falter around 4hz.  The .01hz spectra is attached.

TITLE: 03/10 day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY:'Mainly stayed locked on DRMI all day
LOG:
15:58 Jeff B out to LVEA for parts.
16:23 Jeff out o LVEA
16:26 Christina moving pallets around:into highbay and over to warehouse.
16:52 Christina/Karen finished moving pallets
16:58 Kyle out to EX
17:02 Notification: "ISI_RINGUP: ETMY ISI ringing up"
17:30 Jeff out to LVEA to terminate dust monitor plumbing.
17:40 PEM ISC Timing slave power supply swap starts -Fil
17:45 Robert out to EY
17:48 Fil out of LVEA; Jim rebooting PEM ISC
18:00 Begin initial alignment. Jim working on stability blends due to increasin winds; Sheila restoring a bad safe.snap inhibiting IMC
18:35 Kyle back from EX
 21:25 Jeff B to End Station Compressor rooms
22:15 Jeff back from Ends

[Cao, Aidan]

We have restarted the code on both HWS. We'd like to having them running continously right now. The ITMY HWS is aligned to the Spot 1 position in alog 25905.

I've set the ITMY magnification to a nominal value of 7.5x, per T1400686

Filiberto, Jim, Brynley, Vinny

We powered down the CS-EBAY LSC IO Chassis, and changed the power supply to the timing card to an alternative 12V power supply. It will be left this way while we check if this reduced the 0.5Hz combs in DARM.

WP 5770

Power down h1lsc0 computer to allow modification of timing slave power in I/O chassis.

[Aidan, Cao]

In the online TCS simulation, I updated the absorption coefficients for ITMX, ETMX and ETMY to reflect actual measured values: https://dcc.ligo.org/LIGO-T1400685

• H1:TCS-SIM_XARM_POWER_WATTS_PER_INPUT_UNIT 2.606
• H1:TCS-SIM_YARM_POWER_WATTS_PER_INPUT_UNIT 2.378
• ETMY_SURF_ABSORPTION: 253E-9
• ETMX_SURF_ABSORPTION: 160E-9
• ITMX_SURF_ABSORPTION: 520E-9
• H1:TCS-SIM_ITMX_SURF_ABSORPTION 520E-9  # alog 16578caput H1:TCS-SIM_ITMX_SURF_ABSORPTION 520E-9  # alog 16578
  caput H1:TCS-SIM_ITMY_SURF_ABSORPTION 250E-9
  caput H1:TCS-SIM_ETMX_SURF_ABSORPTION 160E-9 # aLOG 19867
  caput H1:TCS-SIM_ETMY_SURF_ABSORPTION 253E-9 # aLOG 19835

Additionally, I rescaled the TR_X and TR_Y values to reflect the arm powers, courtesy of some calibration work from Cao.

I have a script (copied below) I've been using to update these values as this allows me to store references to measurements and calibrations.

load_IFO_SIM_COEFFICIENTS.sh

caput H1:TCS-SIM_IFO_XARM_LENGTH 3994.47   # aLOG 20149

caput H1:TCS-SIM_IFO_YARM_LENGTH 3994.47

caput H1:TCS-SIM_IFO_SILICA_REF_INDEX 1.44963  #Suprasil 3001, "Heraeus reports 1.44963 as the index at 1064", GLB email Sept 5, 2014

caput H1:TCS-SIM_XARM_POWER_WATTS_PER_INPUT_UNIT 2.606  # estimate of peak value of 105.9kW in arms (needs ref) between 1141200000 and 1141300000 coupled with measurements of TR

_X

caput H1:TCS-SIM_YARM_POWER_WATTS_PER_INPUT_UNIT 2.378

caput H1:TCS-SIM_IFO_cdsMuxMatrix1_1_1 0.5

caput H1:TCS-SIM_IFO_cdsMuxMatrix1_1_2 0.5

caput H1:TCS-SIM_IFO_cdsMuxMatrix1_2_1 1.0

caput H1:TCS-SIM_IFO_cdsMuxMatrix1_2_2 -1.0

# PRC BLOCK

caput H1:TCS-SIM_IFO_PRC_ITM_R3 24.3931    #T0900043-v11, Table 1

caput H1:TCS-SIM_IFO_PRC_R3_R2 16.1558

caput H1:TCS-SIM_IFO_PRC_R2_RM 16.6037

caput H1:TCS-SIM_IFO_PRC_R3_ROC 36.021  # https://galaxy.ligo.caltech.edu/optics/  PR3-01

caput H1:TCS-SIM_IFO_PRC_R2_ROC -4.543 # https://galaxy.ligo.caltech.edu/optics/ PR2-04

caput H1:TCS-SIM_IFO_PRC_RM_ROC -10.948  # https://galaxy.ligo.caltech.edu/optics/ PRM-04

# SRC BLOCK

caput H1:TCS-SIM_IFO_SRC_ITM_R3 24.1176    #T0900043-v11, Table 1

caput H1:TCS-SIM_IFO_SRC_R3_R2 15.4607

caput H1:TCS-SIM_IFO_SRC_R2_RM 15.726

caput H1:TCS-SIM_IFO_SRC_R3_ROC 36.013  # https://galaxy.ligo.caltech.edu/optics/  SR3-02

caput H1:TCS-SIM_IFO_SRC_R2_ROC -6.424 # https://galaxy.ligo.caltech.edu/optics/ SR2-04

caput H1:TCS-SIM_IFO_SRC_RM_ROC -5.638  # https://galaxy.ligo.caltech.edu/optics/ SRM-05 ????? - CHECK

# SPRING CONSTANTS

caput H1:TCS-SIM_IFO_YARM_PEND_SPR_CNST 1.0  # ??????

caput H1:TCS-SIM_IFO_XARM_PEND_SPR_CNST 1.0  # ??????

# ACOS PRC BLOCK

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_OFFSET 0.87

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A0 0.5155940062460905

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A1 -2.0281847857870914

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A2 -3.6292076586482307

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A3 -14.378615634122346

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A4 -69.29856186065047

caput H1:TCS-SIM_IFO_ACOS_PRC_A_D_A5 -373.821577053177

# ACOS SRC BLOCK

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_OFFSET 0.87

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A0 0.5155940062460905

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A1 -2.0281847857870914

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A2 -3.6292076586482307

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A3 -14.378615634122346

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A4 -69.29856186065047

caput H1:TCS-SIM_IFO_ACOS_SRC_A_D_A5 -373.821577053177

# ACOS YARM BLOCK

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_OFFSET 0.87

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A0 0.5155940062460905

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A1 -2.0281847857870914

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A2 -3.6292076586482307

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A3 -14.378615634122346

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A4 -69.29856186065047

caput H1:TCS-SIM_IFO_ACOS_XARM_SQRT_G_A5 -373.821577053177

# ACOS XARM BLOCK

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_OFFSET 0.87

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A0 0.5155940062460905

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A1 -2.0281847857870914

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A2 -3.6292076586482307

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A3 -14.378615634122346

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A4 -69.29856186065047

caput H1:TCS-SIM_IFO_ACOS_YARM_SQRT_G_A5 -373.821577053177

# OPTICS gains

caput H1:TCS-SIM_ITMX_SUB_DEFOCUS_RH_GAIN -9.0E-6

caput H1:TCS-SIM_ITMY_SUB_DEFOCUS_RH_GAIN -9.0E-6

caput H1:TCS-SIM_ETMX_SUB_DEFOCUS_RH_GAIN -9.0E-6

caput H1:TCS-SIM_ETMY_SUB_DEFOCUS_RH_GAIN -9.0E-6

caput H1:TCS-SIM_ITMX_SUB_DEFOCUS_CO2_GAIN 62.3E-6

caput H1:TCS-SIM_ITMY_SUB_DEFOCUS_CO2_GAIN 62.3E-6

caput H1:TCS-SIM_ITMX_SUB_DEFOCUS_SELF_GAIN 4.8709E-4

caput H1:TCS-SIM_ITMY_SUB_DEFOCUS_SELF_GAIN 4.8709E-4

caput H1:TCS-SIM_ETMX_SUB_DEFOCUS_SELF_GAIN 3.8577E-4

caput H1:TCS-SIM_ETMY_SUB_DEFOCUS_SELF_GAIN 3.8577E-4

caput H1:TCS-SIM_ITMX_SURF_DEFOCUS_RH_GAIN 1.066E-6

caput H1:TCS-SIM_ITMY_SURF_DEFOCUS_RH_GAIN 1.066E-6

caput H1:TCS-SIM_ETMX_SURF_DEFOCUS_RH_GAIN 1.066E-6

caput H1:TCS-SIM_ETMY_SURF_DEFOCUS_RH_GAIN 1.066E-6

caput H1:TCS-SIM_ITMX_SURF_DEFOCUS_SELF_GAIN -3.652E-5

caput H1:TCS-SIM_ITMY_SURF_DEFOCUS_SELF_GAIN -3.652E-5

caput H1:TCS-SIM_ETMX_SURF_DEFOCUS_SELF_GAIN -2.931E-5

caput H1:TCS-SIM_ETMY_SURF_DEFOCUS_SELF_GAIN -2.931E-5

TITLE: 03/10 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
QUICK SUMMARY: Nothing IFO unlocked; wind speeds <20mph; .1-.3 uSei hovering between 1-2um/s; DIAG_MAIN showing, "OPLEV_SUMS:SR3 sum is low"

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

Kiwamu, Stefan

Looking at the cross-power plot in alog 25768, we see a coherent noise floor following the shot noise a factor 3.3 below.

Looking at alog 21167, this seems cosistent with our old firend the excess 45.5 MHz noise in DARM.

Shot noise of 20mA: 8e-8mA/rtHz: a factor of 3.3 below that: 2.4e-8mA/rtHz. This is roughly consistent with the residual coherence seen in alog 21167.

Kiwamu will make an all-O1 plot to nicely resolve that noise. We need to add this noise to the mystery noise projection in alog 25106 (this plot).

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.