Displaying reports 65521-65540 of 83069.Go to page Start 3273 3274 3275 3276 3277 3278 3279 3280 3281 End
Reports until 07:46, Thursday 23 April 2015
LHO VE
bubba.gateley@LIGO.ORG - posted 07:46, Thursday 23 April 2015 (18022)
Beam Tube Washing
Scott L. Ed P. Chris S.

This report will cover the following dates: 4/21 & 4/22.

On Tuesday the crew cleaned 46 meters ending 10 meters north of HNW-4-008. Test results posted here.

Wednesday was spent removing and re-hanging lights, applying bleach/water solution, vacuuming support tubes and safety meeting.
Non-image files attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 04:45, Thursday 23 April 2015 - last comment - 12:56, Thursday 23 April 2015(18020)
More recycling gain work

Sheila, Gabriele, Evan

Tonight we spent some more time refining the locking sequence with good recycling gain. Some lessons learned:

Comments related to this report
sheila.dwyer@LIGO.ORG - 04:46, Thursday 23 April 2015 (18021)

This evening we had a look at which signals could be used for ITM ASC.  We dithered each TMS to find acombination of signal which is insensitive to TMS motion, the attached screen shot shows the combination we ended up with.  We has to move the picomotor on TMSY (M14 only).  While doing this we noticed that there is a bug in the software so that according to the epics record of the position it looked like we were moving M3 rather than M14. We drove down to the end station and saw that indeed, the right motor was selected in the driver.  We also see that the beam on the QPD reacts as we expected to moving the motor, so this must be correct.  

For anyone who tries to lock in the morning

We are currently using the guardian as is through the state resonance.  Sometimes there is an oscillation that gets rung up in this state and dies down, we have been waiting for this to ring down before moving onto analog CARM in our sucessfull locking attempts tonight.  We have also been skipping the states BOUNCE VIOLIN mode damping and INCREASE POWER.  We have also been using no whitening on the OMC DCPDs since the violin modes are still rung up and we haven't finshed re commisioning all the damping.

If we had more enegry...

we might try more violin mode damping, or investiagting why we aren't able to power up. Our last idea on this was to adjust the alignment to get a good recycling gain before attempting to power up, taking small steps and re-adjusting the alingment as we go.  Another option would be to commision the ITM loops to do this job for us, using the error signals in this screenshot.  

 

Also, we are leaving the intent bit undisturbed, even though this isn't a great lock.  We are missing some ASC cut offs which make the noise worse below 30 Hz, we are at 3 Watts, and we have our bothersome 90 Hz shelf still.  

Images attached to this comment
gabriele.vajente@LIGO.ORG - 11:52, Thursday 23 April 2015 (18025)

We measured the response of the TRANS QPD error signals to ITM motions. Here is the result, in QPD units over alignment slider units:

Pitch CSOFT_P DSOFT_P
ITMX 0

0.05

ITMY 0.15

0

Yaw CSOFT_Y DSOFT_Y
ITMX 0

-0.10

ITMY 0.05

0

keita.kawabe@LIGO.ORG - 12:56, Thursday 23 April 2015 (18028)

Right after the power increased from 3 to 10W (still no DARM offset and the IFO was locked with RF), all TMs moved by a large angle in PIT, mostly in SOFT:

ETMX +0.2 to 0.3 urad, ETMY +0.9, ITMX +0.5, ITMY +0.6.

It's possible that this is indeed DC radiation pressure pushing optics and the ASC fails to restore things back because we don't have the full DOF controlled, twisting other controlled optics to make the servo happy. If that's the case you need to be able to get back the recycling gain just  by pushing ITMs manually even if you get an instability by doing so.

Also, if the angular optical spring is messing with the stability of the ASC, it looks better to me to switch to true HARD-SOFT based business instead of optic-based. Update: Evan and Gabriele think that the instability is coupled to the centering.

Images attached to this comment
H1 IOO
kiwamu.izumi@LIGO.ORG - posted 18:21, Wednesday 22 April 2015 (18016)
IMC alignment shifted by 2 millimeters horinzontally, absorbed by IM2 and IM4

As reported in the previous alog (17990), we noticed that the IM4 trans has shifted by -0.7 counts horizontally after the pzt move (alog 17976) yesterday. I think that we have introduced a horizontal translation in the beam on the PSL mirrors by about 2 mm during the pzt move which resulted in the different IMC output beam alignment. I corrected the alignment of the IMC output beam, by moving IM2 and IM4 this morning.

 

(Estimation of the shift)

I did an A2L measurement (see Jax's alog 6676 for more details) on MC1 and MC3 to measure the amount of off-centerings. Since we have an active control for the MC2 spot position (DOF3), I did not measure it assuming the in-vac MC2 trans QPD has not moved. The table below summarizes the measurement from today with ones from Dec-2013 for comparison:

  Apr-22-2015 Dec-13-2013 (alog 8943) diff (today - past)
MC1 P  +2.2 mm   -1.8 mm  +4.0 mm
MC1 Y  +3.1 mm  +1.2 mm  +1.9 mm
MC3 P  -2.0 mm  +1.7 mm  - 3.7 mm
MC3 Y   -4.6 mm  - 2.2 mm  - 2.4 mm

Since we know that the vertical position on IM4 trans did not change this time, we ignore them for now. Apparently the horizontal position shifted by 1.9 mm and -2.4 mm on MC1 and MC3 respectively. Note that the MC1 and 3 have a beam radius of 2.12 mm (see T0900386-v7) and therefore the shift is as big as the beam size. If we believe these numbers, the beam must have shifted as depicted in the below cartoon:

Assuming that the distance from a mirror at the bottom of PSL periscope to MC1 is roughly 8 m, the translation we have introduced is about 2 mm toward the West, which I think does not sound too crazy.

If we want, we can correct this by steering a combination of some mirrors in the PSL so as to compensate the translation.

(Doublecheck with MC suspension biases)

In addition to the spot position measurement, I also checked the suspension bias sliders for double check. According to 2 days trend of the suspension bias values, it seems that the ASC servos introduced 35 urads differential yaw on MC1 and MC3 while MC2 did not move much in yaw after the pzt move. I attach a screen shot of the trend. Though, I have no idea what was happening in the vertical directions which also show some variation. Based on a geometrical arrangement of the IMC alignment (for example, J.opt.13 055504 ), one can write the amount of mis-centering on MC1 and OMC3 due to differental angles as

x_mc1 = -x_mc3 = 2 * sqrt(2) * L * theta_mc1

Substituting theta_mc1 = 35 urad, one can obtain x_mc1 = 1.6 mm for MC1 (and -1.6 mm for MC3). So this is consistent with the spot position measurement and explains large fraction of it.

 

(Moving IM2 and IM4)

I decided to correct the output beam of IMC by moving some combination of IMs in order to keep the same PRM spot position. Since I did not like moving IM1 as it is far from the input Faraday, I decided to move IM2 to recover the spot position on IM4 trans. Then I corrected the angle of the beam by steering IM4. Here is a table summarizing how much I moved the bias sliders.

  before  after
IM2 YAW bias 5274 urad  3314 urad
IM4 YAW bias -5130 urad  -3430 urad

The direction of the move on IM2 is consistent with the above arguments. Fortunately, the move on IM2 and IM4 were such that they reduced the absolute numbers.

Images attached to this report
H1 CDS
patrick.thomas@LIGO.ORG - posted 16:23, Wednesday 22 April 2015 (18018)
updated Conlog channel list
Added 1233 channels
Removed 416 channels

74 channels remain unmonitored (list attached)
Non-image files attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:07, Wednesday 22 April 2015 (18014)
Daily Ops Summary

8:53 Travis to LVEA

9:00 Travis back

9:59 Metal recycling container going on the truck

10:06 The truck left

10:08 Karen to Mid Y

10:57 Karen leaving Mid Y

14:13 Jeff B. to 3 IFO storage area in the LVEA

13:24 Jeff B. back

H1 IOO (IOO, PSL)
sheila.dwyer@LIGO.ORG - posted 15:54, Wednesday 22 April 2015 - last comment - 12:47, Thursday 23 April 2015(18017)
PSL input power monitor calibration has changed

After the PSL periscope PZT swap, the periscope bottom mirror is a different high reflector.  We are using the transmission through that optic to monitor the input power into the interferometer; since the transmission of the new optic seems to be a little higher than the old one our calibration of the power into the interferometer has been off since tuesday.  We used to get a maximum power input of 22.7 Watts, after the swap our monitor reads a maximum power of something like 23.7 W.  I adjusted the responsivity of the periscope PD, it used to be set to 0.35 and is now 0.311.  

Next time someone is in the PSL it would be good to check this calibration using a power meter.  

Comments related to this report
richard.savage@LIGO.ORG - 12:47, Thursday 23 April 2015 (18027)

Actually, we didn't change the bottom periscope mirror.  Rather, we placed what was the upper periscope mirror, the one actuated by a PZT stack, in the IO_MB_04 position, just downstream of the thin-film polarizers and just upstream of the bottom periscope mirror.

The original IO_MB_04 mirror was moved to the top of the periscope.

So the transmission through the bottom periscope mirror should have changed only slightly due to a small change in the incidence angle as we directed the beam to the upper newly-placed upper periscope mirror.

However, we didn't optimize the beam position on the power monitoring PD dowstream sampling the beam transmitted through the bottom periscope mirror.

We should have a look at this centering next time we are out in the Laser Room.

H1 SUS (ISC, SUS)
sheila.dwyer@LIGO.ORG - posted 15:31, Wednesday 22 April 2015 (18015)
bounce roll damping

Kiwamu, Evan

Yesterday after maintence time ITMY bounce mode was rung up.  Eavn and Kiwamu damped it with the following settings: +60 degrees phase shifter, bandpass at 9.73 (FM2+FM4 in ITMY_M0_DARM_DAMP_V) and a gain of -0.03.  We did not add this to the guardian, since we have not seen ITMY get rung up before we are assuming something unusual happened yesterday.  

Also, the ETMY roll mode damping which uses AS A 45 has changed sign.  the settings that evan found which worked today are -100dB, a bandpass at 13.9, no phase shift and a gain of -8.  

For bounce and roll, there shouldn't be any need to gues at which optic is rung up, if the motion is large enough.  If a mode is badly rung up we can usually see the bounce mode in the top mass vertical osem and the roll mode in the L2 witness sensors, either Pitch or Yaw.  Attached here is a template that is stored in /ligo/home/sheila.dwyer/Locking/BOUNCE_ROLL_MODE_CHECK.xml.  It shows you spectra and coherences with DARM of local sensors that should be used to identify which optic is rung up when our normal bounce or roll damping is not working. If the damping as it is in the guardian is not working, we shoudl turn off the damping to avoid confusion and run this template to identify which optic is the culprit.  

Images attached to this report
Non-image files attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 14:53, Wednesday 22 April 2015 (18012)
Adjusted step voltage current setpoints for 3 of 6 IP controllers at the Corner Station
CS pressure ~1 x 10-8 torr which is just below values programmed to step to 5000V -> Adjusted step set points from 1.5 x 10-4 amps to 3.0 x 10-4 amps for 3 of the 6 IP controllers at the Corner Station -> will continue optimal tweaking over the next few days
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:23, Wednesday 22 April 2015 - last comment - 11:17, Wednesday 22 April 2015(18009)
WHAM1 HEPI Not restored to Nominal State after Yesterday's Restart

The Orange OK == False on the Guardian should have caught someones' eye but it did not.  As a result, the HAM1 table has (and remains with until Kiwamu gives in)  a 110 urad Pitch and a 6 urad Yaw difference from before.

Comments related to this report
hugh.radkins@LIGO.ORG - 11:17, Wednesday 22 April 2015 (18010)

WHAM1 alignment (HEPI 'Isolating') restored 1818utc.

H1 SEI
hugh.radkins@LIGO.ORG - posted 10:09, Wednesday 22 April 2015 (18007)
LHO STS2-B Swap Study--Remains inconclusive

The STS2-B (ITMY) seismometer was exchanged yesterday for a fresh from repair unit.  Attached are ASDs, Coherences, and TFs between the three STS2s with References from Monday AM (before the change.)  There still seems to be a fuzzy picture of the situation.

Some feel the B instrument sitting on the vinyl floor is an issue, the new unit is also not under an igloo.  Also, the wind and different shapes/sizes of the building wings may have the instruments response less coherent than expected.

Generally, coherence is good with unity TFs between 150mHz to ~ 300mHz but outside of that band it is highly variable.  Even the unmolested A & C TFs are too variable from day to day (wind..?)

Images attached to this report
H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 10:05, Wednesday 22 April 2015 (18005)
PSL DBB/ISS Scans

DBB/ISS scans for this week.

Non-image files attached to this report
H1 PSL
jason.oberling@LIGO.ORG - posted 09:51, Wednesday 22 April 2015 (18004)
PSL ISS Maintanence

While running DBB scans this morning I noticed the PSL ISS diffracted power was down around 3%.  I adjusted the Ref Signal from 2.08 to 2.05 to bring the diffracted power up to ~7.5%.

H1 TCS (ISC)
eleanor.king@LIGO.ORG - posted 18:29, Tuesday 21 April 2015 - last comment - 15:07, Wednesday 22 April 2015(17993)
ITMX CO2 rotation stage hysteresis

Greg, Nutsinee, Aidan, Elli

In the current configuration, the ITMX CO2 laser is inputting 0.2W of central heating to ITMX, just as it has been doing so for the last few months.  The power put onto ITMX is still 0.2W, as measured by the power meter on the CO2X table (H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT).  But the requested power needed to get 0.2W output in now 0.71W, up from 0.35W yesterday.  The rotation stage does not appear to be returning to the same location.

 

Details:

The CO2 laser power is requested by a setting H1:TCS-ITMX_CO2_LASERPOWER_POWER_REQUEST to the desired value, and then a rotation stage moves a 1/2 wave plate to the required angle for that power.  After the model restart this morning, we had to request a very different power (0.44W this morning compared to 0.35W yesterday, compared to 0.3W in March) to get the same output power in H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT.  None of the gains or calibration values had changed this morning, so we suspect hysteresis in the rotation stage.  I moved the rotation stage back and forth between minimum power and 0.2W output power and back again.  I needed to keep requesting higher powers to bring the output power to 0.2W, although there seems to be no clear pattern to the change.  Perhapse the rotation stage is sticking sometimes.  See attached data set of 20 mins of data where I was moving the rotation stage around.

 

Other comments on ITMX CO2 laser:

We noticed a few other things while trending the output power:

The laser temperature as measured by H1:TCS-ITMX_CO2_LASERTEMPERATURE jumped from 23 degrees Celcius to ~27C on 17 March, see plot . The temperature has been fluctuating a lot more since then.   This does not corelate with the enclosure temperature, the laser power has been steady at 59W, and the chiller settings have not changed. Greg and Matt were poking around the CO2 lasers that day, although according to the alog no chages were made to the ITMX CO2 laser (alogs 17303, 17302). 

The laser has been mode hopping since 10 April when Greg swapped out the CO2 laser AOM (alog 17737).  We hadn't seen this previously.  The laser power has been fluctuating by >1% (1W  fluctuations from 59W output power).  This does not have a big effect on the power level going onto ITMX.

Images attached to this report
Comments related to this report
aidan.brooks@LIGO.ORG - 08:21, Wednesday 22 April 2015 (17999)

There's a correlation between spikes in output power of the laser and shifts in the rotation stage. This is quite possible if there is a small reflection from somewhere on or after the rotation stage that is coupling back into the laser and causing the laser mode to shift.

The laser temperature shift may be a glitch in the electronics box. Rich and I noticed something similar at LLO but we could never identify exactly where it came from and then it seemed to disappear. We'll look into this some more.

aidan.brooks@LIGO.ORG - 13:39, Wednesday 22 April 2015 (18011)

There definitely seems to be an electronics glitch associated with the laser interlock controller (D1200745). If we look at the attached plot from about a month ago, we see that during an event where the laser was turned off and back on again, there were jumps in the flowrate and temperature voltage monitors (both of which run through D1200745) at the same time that there was a 10% increase in the current to the laser. The laser interlock controller is connected to the laser RF driver to turn the laser on and off. 

Images attached to this comment
alastair.heptonstall@LIGO.ORG - 15:07, Wednesday 22 April 2015 (18013)

Taking a look at the laser head output, I'm not sure that those glitches are the laser mode hopping.  The power doesn't look like it jumps as much as you would expect for a mode hop.  I suspect Aidan is correct that it may be reflecting back into the laser a little which can cause some weird effects since the reflected beam can steal gain.

H1 TCS (DetChar, PEM, TCS)
andrew.lundgren@LIGO.ORG - posted 11:24, Tuesday 21 April 2015 - last comment - 03:53, Thursday 23 April 2015(17973)
Request to turn off HWS cameras in CS at a known time
Detchar would like to request that the HWS cameras in the center building be turned off for a few minutes at a known time. We're trying to track down some glitches in PEM and ISI sensors that happen every second, and Robert suspects the HWS. Just a few minutes with them off, and then on again, would be fine; we don't need the IFO to be in any particular state, as long as the ISIs are running fine. We would need the precise times (UTC or GPS preferred), as the channels that record the camera state don't seem trustworthy (alog).
Comments related to this report
eleanor.king@LIGO.ORG - 18:39, Tuesday 21 April 2015 (17995)

This afternoon I tunred all HWS off and I will leave them off all night (both of the corner station HWS were on prior to this).

andrew.lundgren@LIGO.ORG - 00:24, Wednesday 22 April 2015 (17997)DetChar, SUS, TCS
It seems like the HWS was in fact the culprit. The HWS was turned of at Apr 21 20:46:48 UTC, according to TCS-ITMX_HWS_DALSACAMERASWITCH. I checked the BLND_Z of the GS13s on BS and ITMX, and the table 2 PSL accelerometer. All three had glitches every second before the HWS was turned off. They all continued to glitch for 11 more seconds (until the end of the minute), and then all stopped at the exact same time.

Attached is a spectrogram of the ITMX GS13. It's hard to see the glitches in the PSL by spectrogram or even Omega scan, but they're very apparent in the Omicron triggers.
Images attached to this comment
joshua.smith@LIGO.ORG - 07:41, Wednesday 22 April 2015 (17998)DetChar, SEI

Here are three better spectrograms showing the transitioning off of the HWS and the loud once per second glitches going away in the ISI-*_ST2_BLND_Z_GS13_CUT_IN1 channels. These plots are made with https://ldvw.ligo.caltech.edu using 0.25 seconds per FFT and normalization turned on. Conclusions same as Andy's post above. 

Images attached to this comment
joshua.smith@LIGO.ORG - 08:45, Wednesday 22 April 2015 (18000)DetChar, SEI

David Shoemaker asked the good question, do these glitches even show up in DARM? Well, that's hard to say. There are once per second glitches that show up in the ISI channels, and once per second glitches that show up in DARM. We don't know if they have the same cause. Figures are: 1. DARM once per second glitches, 2,3, BS and ITMX, 4. overlay of all showing that the glitches in DARM are just slightly ahead in time (in this 0.25 sec/fft view, unless there is some sample-rate timing bias). 

In order to test whether they are both caused by the HWS it would be really useful if folks on site could turn the HWS on, then off, for a minute or so in each configuration during a low-noise lock and record the UTC times of those states. 

Images attached to this comment
Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 03:53, Thursday 23 April 2015 (18019)

We got to a low noise state which is not at as low noise as our best, with the spectrum about a factor of 10 worse at around 90 Hz than our best reference.  We were in low noise, HWS off from 10:42:30 UTC to 10:47:30 UTC, i turned the cameras on according to Elli's instructions and we left the cameras on from 10:48:20 UTC to 10:53:40.  

H1 CAL (CAL, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 12:57, Monday 20 April 2015 - last comment - 09:08, Friday 24 April 2015(17951)
Studies on the Precision of DARM Calibration
J. Kissel, K, Izumi

I had started the weekend hoping to improve the DARM calibration in the following ways:
(1) Including the compensation for the analog and digital anti-aliasing (AA) and anti-imaging (AI) filters.

(2) Decreasing the DARM coupled cavity pole by 25% to 290 [Hz].

(3) Establishing an uncertainty estimate of the optical gain (the DC scale factor component of the sensing function).

(4) Reducing the delay time in the actuation from four 16 [kHz] clock cycles to one 16 [kHz] clock cycles.

After study, and Sunday's improvement to the power recylcing gain, we've decided not to make *any changes to the calibration, yet. 
However, for the record, I put down what I've studied here, so we can begin to understand our uncertainty budget.

%% Details
-----------
(1) Including the compensation for the analog and digital anti-aliasing (AA) and anti-imaging (AI) filters
LLO has pioneered a method to compensate for the high frequency effects of the analog and digital (or IOP) AA and AI filters, by including the *product* of all four filters in the actuation chain of the front-end CAL-CS model (see the last few pages of G1500221 and LLO aLOG 16421). 

Further, Joe has analyzed a collection of 281 real, analog AA/AI filters that were tested during CDS acceptance testing to refine the exact frequency response of these filters (see first attachment, aLIGO_AAAI_FilterResponse_T1500165.pdf). In summary, the 3rd order Butterworth's corner frequency is statistically significantly lower; measured to be 8.941 (+0.654 /-0.389 or +7%/-3%) [kHz] instead of the ~10 [kHz] Butterworth model that we have been using (which was inherited from a .mat file the 40m). Though this does not appreciably affect the magnitude error at high-frequency, it does as much as 3 [deg] of phase by 2 [kHz], which can throws off our estimate of the residual unknown time delay by 5 [us] when we try to account for it in our fitting of the open loop gain transfer function.

However, after exploring what LLO has implemented, we've discovered a flaw in the implementation of this compensation. In going from the continuous zpk model of the filters to discrete, because we're trying to model these filters which have all of their response near, at, or above the Nyquist frequency, there is significant difference of modeled filter's response between the continuous and discrete models (see second attachment 2015-04-18_AAAI_FilterStudy.pdf). 

As such, we will *not* begin to compensate for the AA and AI filtering until we arrive at a better method for compensating these filters.

(2) Decreasing the DARM coupled cavity pole by 25% to 290 [Hz].
Over the past few weeks, we've established the DARM coupled cavity pole is now at 290 [Hz] instead of the predicted L1 value of 389 [Hz] (see LHo aLOG 17863). We've added one more DARM open loop gain transfer function to the list we're now comparing after the HAM6 vent,
Apr 13 2015 04:15:43 UTC % Post HAM6 Vent & UIM/TST Crossover; 10 [W] input power
Apr 13 2015 06:49:40 UTC % No loop parameter changes, but input power 15 [W]
Apr 15 2015 07:53:56 UTC % Input Power 15 [W] no change in control system from previous measurement 
with these three measurements, I made a statistical comparison of the model / measurement residual while using 290 [Hz] for the modeled coupled cavity pole frequency, and reducing the unknown time delay from 40 [us] to 30 [us] because I've used Joe's measured mean for the  analog AA / AI in the model (see third attachment 2015-04-18_290HzCCP_H1DARMOLGTF.pdf ). As one can see on the 3rd and 4th page, assuming each of the residuals frequency points is a measurement of the the true OLGTF value with a Gaussian distribution, the uncertainty in the frequency dependence of the OLGTF model is now a 1-sigma, 68% confidence interval of +/- 1.5% in magnitude and 1 [deg] between 15 and 700 [Hz] (IF we change the CCP frequency to 290 [Hz], compensate for the AA and AI filters, and include 30 [us] of unknown delay). Note that this assumption of Gaussianity appears to be roughly true for the magnitude, but not at all in phase (I'm still thinking on this). Also note the each one of these frequency points has passed a 0.99 coherence threshold on a 10 [avg] measurement (and most have coherence above 0.995), so the individual uncertainty for each point is sqrt((1-coh)/(2*nAvgs*coh)) = 1 to 2%.

Recall the frequency dependence of the model is determined by the following components included in the model:
- The 1/f^2 dependence of the [m/N] suspension transfer function (as modeled by the QUAD state space model)
- The 2000 [Hz] ESD driver pole
- The analog and digital anti-imaging filters
- The 130 [us] of actuation delay from 1 16 [kHz] cycle of SUS Computation, 3 65 [kHz] cycles of IOP Error Checking, 1 65 [kHz] cycle of IOP Computation, and 1/2 65 [kHz]  cycle for Zero-order Hold Delay
- The DARM filters
- The single-pole response (at 290 [Hz]) of the optical plant 
- The analog and digital anti-aliasing filters
- The 76 [us] of sensing delay from 1 65 [kHz] cycle of IOP Computation, 1 16 [kHz] cycle of OMC Computation
- The 30 [us] of unknown time delay

As a cross-check, I recalculated the comparison with the CCP frequency that's currently used in the model, 389 [Hz], and found that at around the high-frequency PCal lines, roughly ~535 [Hz] the model / measurement discrepancy is 25-30%. This is consistent with what the PCAL calibration reports at these frequencies, a DARM / PCAL (which is equivalent to model / measurement) discrepancy of 25-30% -- see LHO aLOG 17582. At the time, the PCAL team reports their internal uncertainty to be in the few-percent range.

This had convinced me on Saturday that I had enough information to "officially" change the DARM CCP frequency in the CAL-CS front end, but Gabriele and Evan have since changed the alignment scheme for the corner station to improve the power recycling cavity gain by improving the ITM DC alignment LHO aLOG 17946. This will have an effect on the signal recycling cavity and therefore the DARM CCP frequency, so we'll wait until we get a few more OLGTFs in this new configuration before changing anything.

(3) Establishing an uncertainty estimate of the optical gain (the DC scale factor component of the sensing function).
After refining the precision of the frequency dependence in magnitude, this allows to quantify the precision to which we can estimate the overall DC scale factor that one needs to scale the model to the measured OLGTF; a factor that we traditionally have attributed only to the change in optical gain between lock stretches. For this study, I've used *all* six DARM OLGTF TFs, see 2015-04-18_AllMeas_FittedCCP_H1DARMOLGTF.pdf. Note that this increases the uncertainty of the frequency dependence to a less Gaussian 2.5%, but as you'll see this is still plenty precise.

Recall that before transition to the OMC DCPDs, regardless of input power to the IFO, the OMC_READOUT sensor gain is changed to match the RF readout sensor gains which are already power normalized. That should mean that input power should have no affect on the measured optical gain, and this is a safe comparison. 

With 6 measurements, the mean scale factor for the OLG TFs is 1.05e6 +/- 26% [ct / ct]. This is consistent by the variation the DARM digital gain by 34% that was used for these 6 measurements. The current optical gain used for the sensing function the CAL-CS front end model is 1.1e6 [ct/m]. This 4% difference from the mean of the these 6 measurements is well within the 26% uncertainty, so we've concluded to *not* change anything there. 

All this being said, we have used the *same* actuation strength for all of these comparisons, but there is no guarantee that the actuation strength is not changing along with the optical gain.
- ETMY is controlled using the Test Mass (L3) and UIM (L1) stages
- The cross-over for these two stages in the two groups of measurements is ~1.2 [Hz] and 2.5 [Hz] (see 17713), and by 10 [Hz], the contribution of the UIM is roughly -25 [dB] and -15 [dB]. Therefore the ESD is the dominate actuator in the frequency region which we're we trying to 
- Static charge affects the actuation strength of the ESD by changing the effective bias voltage of the drive, as well as changing the amount of drive that's in the longitudinal direction (because the charge can migrate to different regions of the reaction mass / test mass gap), see e.g. G1500264, LLO aLOG 16611, or LLO aLOG 14853.
- If there is substantial residual charge on the ESD, the charge varies on the the ESD when Ion Pumps are valved into the chamber.
- It has been shown many times over that the charge varies on the few hour time scale when there is significant residual charge on the test mass and the ion pumps are valved in (see e.g., G1401033 or as recently as LLO aLOG 17772).
Thus, it is reasonable to suspect that the actuation strength is changing between these measurements. LHO has made no-where-near enough measurements (only a one-time comparison between ETMX and ETMY, see LHO aLOG 17528) to quantify how much this is changing, but here is what is possible:
- We have a physical model of the actuation strength (or at least more accurate equation for how the bias voltage determines the actuation strength, see above citations). I think we can take what we've seen for the variance (as high as +/- 400 [V] !!) and propagate that through to see how much of an affect it has on the strength
- PCAL lines at low-frequency (~30 [Hz]), compared against the DARM calibration lines should show how the optical gain is varying with time, it's just that no one has completed this study as of yet.
- Calculation of the gamma coefficient from the DARM lines should also reveal how the open loop gain transfer function is changing with time. In the past, we've assumed that changes in gamma are fluctuations in the optical gain because we've had actuators with non-fluctuating strength. 

Thus, for now, we'll incorrectly assign all of the uncertainty in the scale factor to optical gain, and call is 26%. Perhaps it will be much better to trust PCAL at this point and time, since it's precision is so much greater than this "scale the OLGTF model" method, but I would need a third measurement technique to confirm the accuracy. I think a power budget propagated to a shot noise estimate compared against the measured ASD (like in LHO aLOG 17082) is the easiest thing to do, since it can be done offline. Or we should resurrect the campaign to use the IMC VCO as a frequency reference, but this has the disadvantage of being an "offline, odd configuration" measurement, just like the free-swinging Michelson.

(4)Reducing the delay time in the actuation from four 16 [kHz] clock cycles to three 16 [kHz] clock cycles.
As mentioned above, the time delays that are included in this model are 
- The 130 [us] of actuation delay from 1 16 [kHz] cycle of SUS Computation, 3 65 [kHz] cycles of IOP Error Checking, 1 65 [kHz] cycle of IOP Computation, and 1/2 65 [kHz]  cycle for Zero-order Hold Delay
- The 76 [us] of sensing delay from 1 65 [kHz] cycle of IOP Computation, 1 16 [kHz] cycle of OMC Computation
- 30 [us] of unknown time delay (the equivalent of ~8-9 [deg] of phase at 700 [Hz])
for a total of 206 [us] of delay for which we've accounted, out of the total 236 [us] that's used to produce the above frequency-dependence comparison. So, there's a total of 3.4 or 3.9, 16 [kHz] cycles of known or known+unkuown time delay, respectively. Remember that the "L/c", light-travel time delay (13 [us]) is *less* than the one 16 [kHz] SUS clock cycle (61 [us]) delay that defines when the control signal arrives at the end station over RFM IPC, so we ignore it.

Since we only have the infrastructure add the delay in the actuation paths in CAL-CS, then we can only account for the *differential* delay between the two paths. If we assign the unknown delay to the actuation side of things, then the difference in delay between the two paths is (130+30)-76 = 84 [us] = 1.3 16 [kHz] clock cycles, leaving a residual overall delay of 76 [us]. If we assign it to the sensing function, we get 130-(76+39) = 24 [us] = 0.39 16 [kHz] clock cycles, leaving a residual of 130 [us]. Since we can't do less than 1 [kHz] clock cycle, we should chose to assign the unknown delay to the actuation function, apply one 16 [kHz] cycle delay to the actuation function, and suffer the 0.3 / 16384 = 18 [us] phase difference between the sensing and actuation path, and have to account for a 76 [us] delay in offline analysis.
Non-image files attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 22:52, Monday 20 April 2015 (17965)

Your list of known delays doesn't seem to include the 13us (L/c) delay from the interferometer response (see e.g. eqn. 16 in T970101).

jeffrey.kissel@LIGO.ORG - 09:22, Wednesday 22 April 2015 (18002)
Daniel's right, details below. As such, the unknown time delay is 16 +/- 5 [us], 
For clarity I repeat the new list of time delays:
the time delays that are included in this model are 
- The 130 [us] of actuation delay from 
     - one 16 [kHz] cycle of SUS Computation, 
     - three 65 [kHz] cycles of IOP Error Checking, 
     - one 65 [kHz] cycle of IOP Computation, and 
     - one-half a 65 [kHz]  cycle for Zero-order Hold Delay
- The 89.3 [us] of sensing delay from 
     - one L/c delay sensing the ETM motion in the corner, 
     - one 65 [kHz] cycle of IOP Computation, and
     - one 16 [kHz] cycle of OMC Computation
- 16.7 [us] of unknown time delay (the equivalent of ~3-4 [deg] of phase at 700 [Hz])
for a total of 219.3 [us] of delay for which we've accounted, out of the total 236 [us] that's used in the model.

Details:
--------
More on the L/c time delay, as explained by Daniel:
I have said above,
"Remember that the "L/c", light-travel time delay (13 [us]) is *less* than the one 16 [kHz] SUS clock cycle (61 [us]) delay that defines when the control signal arrives at the end station over RFM IPC, so we ignore it."

Daniel agrees:
The fiber delay is n * L/c or about 20us. It doesn't matter because it is part of
the SUS cycle delay.

However, there is a sensing function delay. When you push the ETM (from the DARM actuation) it takes at least
L/c before you can measure a signal in the corner. This is a pure optical delay. This sensed control signal is indeed what we're measuring when we take an open loop gain transfer function.

For gravitational waves the situation is similar, the photons which travel forth and back in
the arm are, on average, sampling h(t) from half a round trip ago. In reality, this
is only exactly true for perpendicular incidence. 

As such, we should subtract 3994.465(+/- 7e-4) [m] / 299792458 [m/s] = 13.3 [us] from the "unknown" time delay, leaving us with a timing uncertainty of 16.7 [us]. Unclear yet what the uncertainty is in this number, since thus far it's merely fit by-eye to make the phase of the OLGTF residual flat. From playing around with the number in the fit, I would suggest a 5 [us] uncertainty on this unknown timing residual.

I'll update 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/H1DARMmodel_preER7.m  
later today to reflect this knowledge.
koji.arai@LIGO.ORG - 10:18, Wednesday 22 April 2015 (18008)

OMC DCPDs have uncompensated poles at 13.7kHz and 17.8kHz due to their locations above the nyquist freq.
They cause the delay of ~18.5us. The details can be found in LHO ALOG 17647

jeffrey.kissel@LIGO.ORG - 08:12, Friday 24 April 2015 (18037)
I've confirmed Koji's statement with a bode plot, though I get a better "fit" with 20 [us] delay. But the point is moot.  I'll definitely just include this in the actual frequency response of the sensing function. This brings the unknown time delay to 0 +/- 5 [us] -- wow! Let's hope we don't find out about anything else. ;-) 

Also -- that means we should include this in the approximation for the super-Nyquist frequency response of the sensing function along with the digital and analog AA filters when we fix that it in the front-end.
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 09:08, Friday 24 April 2015 (18039)
I've reprocessed the results after adding the L/c arm delay and the OMC DCPD uncompensated high frequency poles mentioned above. Because we've replaced the equivalent unknown time delay with a known time delay of L/c 13.3 [us] and some very high-frequency poles, the results have actually changed very little and therefore the uncertainty in the frequency response of the OLGTF has changed very little: 
                                   Was                     Is Now
Magnitude Residual StDev:  1.0045 +/- 0.025318       1.0043  +/- 0.025309     
Phase Residual StDev:      0.4299 +/- 1.0307         0.23821 +/- 1.0534
However, there're less unknowns in the model, which is exactly what we want. 

As such, I stand by my earlier statement:

As one can see on the 3rd and 4th page, assuming each of the residuals frequency points is a measurement of the the true OLGTF value with a Gaussian distribution, the uncertainty in the frequency dependence of the OLGTF model is now a 1-sigma, 68% confidence interval of +/- 2.5% in magnitude and 1 [deg] between 15 and 700 [Hz] (IF we change the CCP frequency to 290 [Hz] -- which is now probably different, and find a good discrete approximation for compensating for the OMC DCPD poles, the AA, and the AI filters). Note that this assumption of Gaussianity appears to be roughly true for the magnitude, but not at all in phase (I'm *still* still thinking on this). Also note the each one of these frequency points has passed a 0.99 coherence threshold on a 10 [avg] measurement (and most have coherence above 0.995), so the individual uncertainty for each point is sqrt((1-coh)/(2*nAvgs*coh)) = 1 to 2%.


Details:
--------
I've added the following parameters to the params files:
par.C.omcdcpdpoles_Hz = [13.7e3 17.8e3]; % LHO aLOGs 18008 and 17647

par.C.armLength.x = 3994.4704; % [m] +/- 0.3e-3; LHO aLOG 9635
par.C.armLength.y = 3994.4692; % [m] +/- 0.7e-3; LHO aLOG 11611
par.C.speedoflight = 299792458; % [m/s]
and added the following lines to the DARM model
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/H1DARMmodel_preER7.m

par.C.uncompensatedomcdcpd.c = zpk([],-2*pi*par.C.omcdcpdpoles_Hz,prod(-2*pi*par.C.omcdcpdpoles_Hz));
par.C.uncompensatedomcdcpd.f = squeeze(freqresp(par.C.uncompensatedomcdcpd.c,2*pi*freq));

par.t.armDelay  = mean([par.C.armLength.x par.C.armLength.x]) ./ par.C.speedoflight;
Non-image files attached to this comment
H1 DetChar (CDS, DetChar, PEM, PSL)
andrew.lundgren@LIGO.ORG - posted 02:12, Sunday 19 April 2015 - last comment - 10:05, Wednesday 22 April 2015(17941)
PSL accelerometer signal glitching once per second
One of the accelerometers on the PSL table (PEM-CS_ACC_PSL_TABLE2_Z) is glitching once per second. The other accelerometers don't seem to have this problem. We noticed this because it was messing up our hVeto results. I searched for where these started, and as far as I can tell it's Apr 14 2:30 UTC (that's 7 PM on Monday local, I think). The onset takes a few minutes.

The first plot is an Omega scan from a few hours ago, showing the glitching. The second is a spectrogram of the onset.

We are seeing something similar in some of the ISI GS13s (maybe only ones in the center building?). They also have a once per second glitch, though it's not clear if it's related. Detchar will track that down more, and I'll alog it separately.
Images attached to this report
Comments related to this report
robert.schofield@LIGO.ORG - 14:11, Sunday 19 April 2015 (17943)

I have seen large 1 Hz combs in many places at the CS that are due to the Hartman Wavefront Sensor running at 1 fps (the capture rate of 57 at end stations makes a comb of huge peaks in DARM). I think that Ellie is going to keep the HWS off most of the time until we figure out why.

andrew.lundgren@LIGO.ORG - 01:56, Monday 20 April 2015 (17948)
Do you mean a 1 Hz comb in the spectrum, or glitches every second? This is the latter. Do you have an example of what this looks like? Also, is there an easy way to tell when the HWS is on?
aidan.brooks@LIGO.ORG - 11:11, Monday 20 April 2015 (17956)

We're implementing a Guardian script for ETM HWS control which engages the HWS when we lock, takes a measurement during the initial transient, then turns it off after thirty minutes or so. We'll look into implementing this at the corner station too.

Longer term - we need to look into what we might be able to do to eliminate the camera noise.

aidan.brooks@LIGO.ORG - 11:26, Monday 20 April 2015 (17957)

The camera can be turned on and off from Beckhoff. The channels you're looking for are:

H1:TCS-ITMX_HWS_DALSACAMERASWITCH

H1:TCS-ITMY_HWS_DALSACAMERASWITCH

eleanor.king@LIGO.ORG - 10:05, Wednesday 22 April 2015 (18006)

There are two channels to look at which are:

H1:TCS-ETMX_HWS_RCXCLINKSWITCH

H1:TCS-ETMX_HWS_DALSACAMERASWITCH

Displaying reports 65521-65540 of 83069.Go to page Start 3273 3274 3275 3276 3277 3278 3279 3280 3281 End