Displaying reports 65501-65520 of 83069.Go to page Start 3272 3273 3274 3275 3276 3277 3278 3279 3280 End
Reports until 09:44, Friday 24 April 2015
H1 CDS
david.barker@LIGO.ORG - posted 09:44, Friday 24 April 2015 (18044)
possible inconsistent filter loading on h1omc model

Jim, Jeff, Dave

The h1omc model GDS_TP screen was showing a "Modified file" warning for H1OMC.txt filter module file. I checked and found the chans/H1OMC.txt and chans/filter_archive/h1omc/H1OMC_1113901380.txt files are in fact identical. Since the modification time of H1OMC.txt and the time of load were within the same minute, we think perhaps the Load Coefficient button was pressed too quickly after the file change and the front end computer suffered NFS cache lag. To clear up any confusion, Jeff has reloaded the filter file on h1omc.

H1 SEI
hugh.radkins@LIGO.ORG - posted 09:24, Friday 24 April 2015 (18040)
STS2-B Temporary Seismometer moved into a Igloo

Want to make sure we are comparing peppers to peppers as we assess the quality of the repaired PEM STS2 and attemp to understand the problems of the original STS2.  I also moved it to the exact spot where the oriinal was located.  If things still look so-so by Monday, our net step is to place the STS2 on the concrete.  STS2-B has always been sitting on the floor vinyl wereas STS2s A & B are on the concrete.

H1 ISC (ISC, SEI)
sheila.dwyer@LIGO.ORG - posted 07:05, Friday 24 April 2015 - last comment - 13:59, Sunday 03 May 2015(18035)
Recycling gain

Evan, Sheila

We have been able to lock the IFO at 10 Watts with a recycling gain of 37.  We also think that we can probably improve our inital alingment scheme by adding a servo from POP A to PR3 durring the INput align step.  We've closed loops around ITMX from the TRX QPDs, these were stable for almost an hour before we dropped the lock for other reasons, and helped keep the X arm build up stable as we increased the power.  

Variation on Inital Alingment 

At the beginning of the evening, our alignment resulted in a rather low recycling gain (15 or something) which resulted in difficulty locking.  This was probably because the ITM camera references would have moved 18033.  We have now gone through an initial alignment with some extra steps which brought us back to a decent recycling gain (35 before any manual adjustment or full lock ASC).  

 

  PIT (urad) Yaw
PD1 169.2 -311.4
PD4 134.5 -278.9
mean 151.85 -295.15

 This resulted in a recycling gain of about 35, so it seems like this was a sucsesful approach at least once.  If there is time for some day time commissioning tomorrow, it would probably be helpful to add to the INPUT align state a loop which actuates on PR3 to center the beam on POP A.  Commissioning the dither Align script for the BS to ETMY baffle PDs might also be helpful, but this is a lower priority because we aren't sure that step is necessary.  

Since we have seen this week that many things (CARM offset reduction, violin and roll mode damping, and ASC error signals, possible radiation pressure instability on the ITMs) change when we go from a bad recycling gain to a good one, it seems like we will want to improve our initial alignment scheme enough to consistently bring us to a high enough recycling gain that we can use consistent settings for lock acquisition.  

Avoiding oscillations durring power up

We ran into the oscillation in ITM pitch which we think is due to mis centering and radiation pressure on the ITMs several times tonight.  It seems like we are more stable when the recycling gain is high, we have also slowed down the final CARM offset reduction and the power increase.  

Closing ITM loops

We were able to close loops around ITMX from the QPD error signals we found last night. Here are settings:

DSOFT P (ITMX P) error signal 1.71 TRX A -1 TRX B FM offset 0.08, FM2,3,4 gain -700,000, top mass offloading on

DSOFT Y (ITMX Y) error signal 1.84 TRX A -1 TRX B FM offset -0.1, FM2,3,4,6 gain 600,000, top mass offloading on

both of these loops respond in a 2-3 seconds.  

DARM OLG

Evan made a measurement of the DARM OLG, this was when we still on ETMX, DC readout with low frequency boost, and a recycling gain of 35.  11 Watts input power. 

Now a large earthquake has tripped most of the seismic platforms.  

Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 09:57, Friday 24 April 2015 (18048)

While in  full RF lock with a good recycling gain, turn off the green QPD servo and align the Y green beam to the arm manually (or using green WFS feeding back to PZT mirrors), then and set the QPD offsets.

Hopefully this will fix the ETMY green beam position, and makes Y arm initial alignment less convoluted.

evan.hall@LIGO.ORG - 13:59, Sunday 03 May 2015 (18195)

The BS alignment slider values for PD1 and PD4 are switched in this entry. I redid the BS→EY baffle pointing today and found

  P (µrad) Y (µrad)
PD1 134.3 −280.0
PD4 169.5 −314.0
Mean 151.9 −297.0

Also, PD4 has a large dark offset (19.7 µW) compared to PD1 (−0.5 µW). The net power reported by PD4 with the PSL beam pointing onto it is 4.2 µW, and the for PD1 it is 5.2 µW. The settings for both are 0 dB gain, 0.5 A/W responsivity, and 20 kΩ transimpedance.

H1 IOO (IOO, ISC, SYS)
sheila.dwyer@LIGO.ORG - posted 03:15, Friday 24 April 2015 - last comment - 11:23, Friday 24 April 2015(18036)
rotation stage moving the wrong direction when a command is issued

Evan, Sheila

We have been slowly stepping up the input power tonight, and we see the power drop when we request increased power.  Here is an example, from 4-24-15 9:35 UTC.  The top left panel shows the power which Evan requested, the bottom left panel shows the actual cmd position, which approriately goes in the same direction consistently when the requested power increases. The right two panels show the problem, that the readback of the actual rotation stage position goes in the wrong direction briefly when a new comand is sent.  This is a real decrease in power, the lower right panel shows that the power monitor PD sees these power decreases. 

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 09:35, Friday 24 April 2015 (18042)

If you zoom in, you can see many things.

1. At the very beginning of the rotation, the cmd position (left bottom) doesn't ramp for about 2 seconds, and suddenly it jumps up (red circle), which coincides with the reversing motion of the rotator. This behavior is repeated in every power step in Sheila's data.

(Updated after reading Daniel's comment:  2 sec delay might be a non-issue, but the jump seems to be an issue.)

2. At the end of the rotation, the cmd position looks good but the rotator jumps up, causing another power jump (blue circle). This also is repeated in every power step in Sheila's data.

3. There's one instance where the rotator reversed direction in the middle of ramping in Sheila's data (green circle).

4. There's one instance where the power increase was requested, nothing happened for 11 seconds, another power was requested, and the rotator started moving (second attachment).

(Updated after reading Daniel's comment: This might be a non-issue.)

Images attached to this comment
daniel.sigg@LIGO.ORG - 09:42, Friday 24 April 2015 (18043)

After the power request one also needs to press the go button to get it started. So, I guess the 2s delay is just that. For the request without moving, are we sure the button was pressed?

keita.kawabe@LIGO.ORG - 10:31, Friday 24 April 2015 (18049)

I requested a small power step  (from 2W to 2.1W) and immediately back to the original power, and the measured power dropped from 2.25W to 1.9W.

I repeated again, and the power went further down to 1.5W.

All in all, the calculated angle got back to the original number, of course, but the measured angle is down by about 0.4 degrees or so.

Images attached to this comment
keita.kawabe@LIGO.ORG - 11:23, Friday 24 April 2015 (18051)

Daniel hit the "Go To Power" button without changing the power request, and the driver still did its thing and the power dropped.

After repeating the routine 4 times, the encoder value happened to get back to the number before Daniel started, but the power is still down from 1.5-ish to 1.1-ish W.

Images attached to this comment
H1 ISC
koji.arai@LIGO.ORG - posted 22:23, Thursday 23 April 2015 (18034)
Noise coupling to the OMC length due to dither locking

OMC Length control loop was evaluated to estimate the out-of-loop stabilization displacement level.
The out-of-loop stability of the OMC is around 10-14~10-13m/rtHz level (Attachment 3 blue curve below 10Hz).
Between 10Hz to 300Hz, the contamination of the cavity length displacement is expected (Attachment 3 black curve).
This is due to the sensor noise injected to the cavity by the dither control loop itself.
 


The data was taken from the lock in the evening of Apr 15 at 15W lock.

Servo filter modeling

The transfer function from H1:OMC-LSC_I_OUT_DQ to H1:OMC-LSC_SERVO_OUT_DQ was measured and modelled
based on the ZPK model of the filter. (Attachment 1)

Openloop TF modeling

The OLTF model is based on a swept-sine loop TF measurement done on Apr 4 at DRMI with sideband locked OMC.
As the DCPD output is normalized with the DC value, the optical gain after the normalization is believed to be constant.

The actuator frequency response is indeed not simple, but we already evaluted it before (LHO ALOG 16089).

In the end, the openloop transfer function was successfully modelled. (Attachment 2)
Note that the actual open loop transfer function on Apr 15 was a factor of 3 lower than the one in this plot.
(The servo gain was 30 on Apr 4, and was 10 on Apr 15.)

This gives us the optical gain estimate of 6.0x108 1/m at H1:OMC-LSC_I_OUT_DQ.

...In fact this number is about 5 times smaller than the theoretical prediction from the dither amplitdue (0.87pm_pk@3300Hz)
and the cavity finesse of ~400. I still don't have good excuse for this discrepancy.

Free-running and stablized cavity length displacement

The free-running motion of the OMC cavity was estimated from the optical gain, actuator response, and openloop transfer functions.
It is shown as the red curve in Attachment 3. The blue curve is the calibrated in-loop displacement sensed by the dither length sensing.

The gray curve indicates the cavity length noise measured with PDH in January (LHO ALOG 16089).

Assuming the red curve is dominated by the sensor noise (and that is the guess), the black curve is the noise injection to the OMC cavity
due to the servo control. This means that the out-of-loop stability of the OMC is represented by the blue curve up to 10Hz,
the black curve up to 300Hz, and the gray curve above 300Hz.

The sky blue curve represents the shot noise level estimated from the shot noise level of the 33mA and optical gain 6.0x108 1/m.
(i.e. Sqrt(2 e / Idc) * 3000 / Sqrt(2) / 6.0x108 = 1.1 x 10-14 m/rtHz, 3000 is the LO amplitude for demodulation,
1/Sqrt(2) is the product of the demodulation (1/2) and double-sided to one-sided conversion (xSqrt(2)) )

The information we can obtain from this measurement is:

1) Below 4Hz, the dither error signal sees the cavity motion. (Compraison between red and gray)
2) At least above 10Hz, the sensing noise is dominating the error signal. (Comparison between red and gray)
3) The cavity noise have some mechanical peaks at 0.45Hz and 2.8Hz. (Comparison between red and gray)
    Where are they coming from? Is this due to OMC SUS actuation for OMC ASC?
4) The cavity motion is contaminated by the control above 10Hz upto 300Hz. (Comparison between black and gray).

You may wonder:
a) if the bump at 30~40Hz comes from the sensor noise, or coming from the servo bump or something else.
=> My guess is that this is the sensor noise. If you look at the DCPD spectrum (Attachment 4), the structure around the dither
frequency is asymmetric. This seems indicating that there is a bum ~3330Hz and a part of the bump is suppressed by the servo
while it is adding more noise to the lower side of the dither frequency.
=> I'd recomend to shift the dither frequency where there is no structure in the DCPD spectrum with in ~+/-100Hz of the dither freq.

b) what are the strong peaks above 100Hz. They are the down converted violin modes from ~3000 and ~3500Hz.
This is also visible in the DCPD spectrum (Attachment 4). Note that this strong harmonics of the violin modes are partly coming from
the saturation of the DCPD during this lock.
=> I'd recomend to use stronger roll-off or band-stop. Also the modulation frequency should probably be selected to push the violin
p
eaks in a small freq region in the dither error signal.

c) if it is ok to have the contamination if the cavity motion due to the dither locking.
=> We probably need to tune the servo filter to minimize the contamination to keep the requirement of 3x10-16 m/rtHz.
The design depends on how the noise bump at 35Hz is removed by shifting the modulaiton frequency.

Images attached to this report
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 17:12, Thursday 23 April 2015 (18033)
lexan plates removed on ITM digital cameras

Elli, Kiwamu, (under WP 5166)

In response to Evan's report from the last night (alog 18020) about the ITM cameras not reproducing good recycling gain, we took a close look at the ITM digital cameras. As a part of the activity, we removed the lexan plates from the following cameras in order to improve quality of the images:

This is going to be a permanent configuration. The removal of the lexan got rid of unwanted stripes that had been seen on the ITMX green camera. The attached files show the ITMX green camera before and after the lexan removal. Hopefully this will help the reproducability of the initial alignment. Note that the oval shape shown in the attached pictures are due to the software aperture masking. The ITMY camera did not have stripes from the beginning and therefore no drastic change between before and after. We did not check the quality of the infrared cameras yet as they had not been an issue. We are still in the middle of figuring out optimum combination of the analog gain and exposure time, but we handed the interferometer to the evening commissioners.

Prior to the removal, John came with us to the LVEA and we went through all four cameras in order to see if they are mounted properly such that they don't accidentally hit the viewport within the movable range of the mount. Partly because of this test, we had to readjust the camera angles afterwards which then required us to renew the ALS ASC camera reference positions. We started the alignment process from TMS on both arms using the baffle PDs and subsequently optimized the ITM and ETM angles by maximizing the green transmission. Then we updated the camera positions. 

Images attached to this report
Non-image files attached to this report
H1 PSL (PSL)
gabriele.vajente@LIGO.ORG - posted 15:59, Thursday 23 April 2015 (18031)
ISS array is misaligned

After Tuesday PZT mirror swap, the ISS photodiodes are misaligned, see attached trend (all ISS signal vertical scale is 0-2000). All diodes receive less than half the power they used to. Some even less than that.

Images attached to this report
H1 General
edmond.merilh@LIGO.ORG - posted 15:48, Thursday 23 April 2015 (18023)
Daily Ops Summary

07:00 Cris and Karen into LVEA

08:00 OIB set to UNDISTURBED

08:45 OIB set to Commissioning

08:46 begin alignment/locking

09:02 J Bartlett out to the LVEA to hang sensors for 3IFO

09:15 Bartlett out of LVEA

09:40 Fil and Andres out of LVEA

11:00 Operators meeting

12:00 Operators meeting over

14:02 Kyle to EX

15:15 Kyle back from EX

 

I did some initial alignment today. Locking happened up to the Resonance state. I never experienced the oscillation mentioned in Sheila's aLog (comments to 18020). IFO broke lock within 3 minutes of resonance 2 - 3 times. It never got past that then commissioners took over.

LHO VE
kyle.ryan@LIGO.ORG - posted 15:34, Thursday 23 April 2015 (18030)
~1410 -1420 hrs. local -> Entered/exited X-end VEA
Had "tinkered" with out-building IP controllers -> As found, Y-mid was 5000V and 7000V -> changed current at which point one of the channels stepped from 5000v to 3000V such that now IP9 is 3000V and 5000V
H1 TCS (AOS, TCS)
nutsinee.kijbunchoo@LIGO.ORG - posted 13:58, Thursday 23 April 2015 (18024)
CO2X Rotation Stage Busted?

Aidan, Elli, Nutsinee

 

Following up Elli's alog 17993

 

I took advantage of a ~9:30 lock loss this morning to rotate the CO2X rotation stage around (the operator was informed). It took longer than I expected so I accidentally worked through as the Guardian was building up IR power (if you see something weird during 9:30-9:50 that could have been me. Sorry...)

 

Procedure: I requested the rotation stage to search for home, then requested a power of 0.212 W (nominal). Then repeatedly go to minimum and request the same power again to see if the rotation stage accumulate some error in angles. Eventually, I searched for home again a couple times then brought the power back to nominal.

 

Result: I find the result quite puzzling and need some times to think about it, but it seems like after search for home the difference between the requested power and the output power grows significantly. However, after a few adjustment I managed to get the requested nominal power and the output power to agree within 1% and that's where it was left this morning.

 

Action Requested Power (W) Measured Angle (deg) Measured Power out (W) |Power out - Requested power| (W) Note

Search for home

  0 5.073    

Request power

0.212 43.92 0.245 0.035 (off by 16.5% of the requested power)  

Go to minimum

  37.98 -0.035    

Request power

0.212 43.95 0.248 0.037 (off by 17.4% of the requested power)  

Go to minimum

  38.07 -0.027   Didn't wait until the output power settle

Request power

0.212 44.04 0.259 0.047 (off by 22.2% of the requested power)  

Go to minimum

  38.09 -0.034    

Request Power

0.212 44.06 0.264 0.052 (off by 24.5% of the requested power)  

Go to minimum

  38.13 -0.037    

Request Power

0.212 43.87 0.246 0.034 (off by 16.0% of the requested power)  

Go to minimum

  38.01 -0.036    

Request Power

0.212 43.92 0.246 0.034 (off by 16.0% of the requested power)  

Search for home

  0 5.080    

Request Power

0.212 43.96 0.271 0.059 (off by 27.8% of the requested power)  

Search for home

  0 5.054    

Request Power

0.212 44.15 0.306 0.094 (off by 44 % of the requested power)  

Go to minimum

  38.24 -0.035    

Request Power

0.212 43.94 0.257 0.045 (off by 21.2% of the requested power)  

Request Power

0.198 44.17 0.288 0.09 (off by 45.5% of the requested power)  

Request Power

0.178 44.00 0.260 0.082 (off by 46% of the requested power)  

Request Power

0.119 43.64 0.236 0.117 (off by 98% of the requested power)  

Request Power

0.149 42.42 0.140 0.009 (off by 6% of the requested power)  

Request Power

0.159 43.26 0.198 0.039 (off by 24% of the requested power)  

Request Power

0.169 43.10 0.169 0 (off by 0% of the requested power)  

Request Power

0.179 43.66 0.207 0.028 (off by 15.6% of the requested power)  

Request Power

0.189 43.57 0.180 0.009 (off by 4.8% of the requested power)  

Request Power

0.210 43.97 0.212 0.002 (off by 0.9% of the requested power) Nominal
Images attached to this report
H1 ISC (ISC)
gabriele.vajente@LIGO.ORG - posted 12:29, Thursday 23 April 2015 (18026)
SCRL non stationary coupling

I had a look at the SRCL coupling to DARM during last night lock. Indeed it is non stationary, and the transfer function changes shape significantly. It appears, as already seen, that there is a low frequency component which is more or less constant, plus a high frequency component with a quickly varying gain. See the first plot for an animation of the TF from SRCL output to (calibrated) DARM.

I analyzed the coupling at 40 Hz and at 300 Hz. For the low frequency, the fluctuations are mainly in the transfer function gain, which is on average about 3e-11 (in some units) and fluctuates between 2 and 8e-11. For the high frequency, it seems that the phase as well as the amplitude changes. So I analyzed the real and imaginary parts of the TF separately.

The attached plots show that the coupling fluctuations are very well correlated with angular motions. In particular H1:ASC-AS_A_RF36_I_PIT_OUT_DQ is the winner. This signal has the same content as H1:ASC-AS_B_RF36_I_PIT_OUT_DQ.

So my conclusions is that the non stationarity is still dominated by angular motions in the SRC. Indeed, we didn't switch on any ASC boosts on SR1/SR2. We have to improve SRC angular stability. In particular SRC1_PITCH

Images 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 (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 CDS (CDS, DAQ, TCS)
andrew.lundgren@LIGO.ORG - posted 09:53, Tuesday 21 April 2015 - last comment - 09:24, Friday 24 April 2015(17971)
Minute trends, second trends, and raw data disagree on when HWS camera was off
Andy, Duncan

When looking for times when the HWS camera was on or off, I found that the minute trends indicated that it was off on Apr 18 6:30 UTC for ~27 minutes. But the second trends indicate that it was turned off 20 minutes later than that (and back on at the same time). The raw data (sampled at 16 Hz) indicates that the camera was never turned off.

This was originally found using data over NDS2, but Duncan has confirmed by using lalframe to read the frames directly. I've attached a plot below. The channels are H1:TCS-ITM{X,Y}_HWS_DALSACAMERASWITCH.
Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 14:39, Tuesday 21 April 2015 (17981)DAQ, DetChar

I was able to successfully run it in the Caltech (CIT) cluster using a matlab code i.e., the raw, minute and second trends agree. The matlab code uses ligo_data_find. But if I run the same code at Hanford cluster it produces the results Andy and Duncan saw i.e., the trends disagree. So there seems to difference between the frames at these two locations for the trend ones. I have attached the matlab codes here with incase some one wants to test it.

Non-image files attached to this comment
gregory.mendell@LIGO.ORG - 14:32, Thursday 23 April 2015 (18029)

This is because the trend data from the two CDS framewriters can disagree. This happens if a framewriter restarts during the period covered by the trend file, and the averages from each framewriter are computed using a different number of values. These differences only happens with the trend data. See below for the details.

Note that at LHO, LDAS is using the CDS fw1 framewriter as the primary source of the scratch trends (saved at LHO for the past month) and the CDS fw0 frameswriter as the primary source of the archive trends (copied to CIT and saved permenantly at LHO and CIT).

If a framewriter goes down, it will still write out the trend data based on what data it has since it restarted.

Thus you can get trend frames that contain data averages for only part of the time period covered by the file.

For the time given in this alog, the trend files under /archive (from framewriter-0) and /scratch (from
framewriter-1) differ is size:

$ ls -l /archive/frames/.../H-H1_M-1113372000-3600.gwf
-r--r--r--   1 ldas     ldas     322385896 Apr 18 00:27 /archive/frames/.../H-H1_M-1113372000-3600.gwf

$ ls -l /scratch/frames/.../H-H1_M-1113372000-3600.gwf
-r--r--r--   1 ldas     ldas     310156193 Apr 18 00:46 /scratch/frames/.../H-H1_M-1113372000-3600.gwf

Note that both files pass FrCheck (but have different checksum) and contain valid data according to framecpp_verify (e.g., run with the --verbose --data-valid options).

However, if I dump out the data for one of the channels in question, I get:

$ FrDump -i /archive/frames/.../H-H1_M-1113372000-3600.gwf -t H1:TCS-ITMX_HWS_DALSACAMERASWITCH.mean -d 5 | grep "0:"
     0:           1           1           1           1           1
      1           1           1           1           1
    10:           1           1           1           1           1
      1           1           1           1           1
    20:           1           1           1           1           1
      1           1           1           1           1
    30:           1           1           1           1           1
      1           1           1           1           1
    40:           1           1           1           1           1
      1           1           1           1           1
    50:           1           1           1           1           1
      1           1           1           1           1

$ FrDump -i /scratch/frames/.../H-H1_M-1113372000-3600.gwf -t H1:TCS-ITMX_HWS_DALSACAMERASWITCH.mean -d 5 | grep "0:"
     0:           0           0           0           0           0
      0           0           0           0           0
    10:           0           0           0           0           0
      0           0           0           0           0
    20:           0           0           0           0           0
      0           0           0           1           1
    30:           1           1           1           1           1
      1           1           1           1           1
    40:           1           1           1           1           1
      1           1           1           1           1
    50:           1           1           1           1           1
      1           1           1           1           1

These frames start at,

$ tconvert 1113372000 Apr 18 2015 05:59:44 UTC

and the 0's start about 28 minutes into the /scratch file (copied from framewriter-1), while the /archive version only contains 1's (copied from framewriter-0).

Thus, I predict framewriter-1 restarted at around Apr 18 2015 06:28:00 UTC. It seems that 0's get filled in for times before that.

If I check, H1:TCS-ITMX_HWS_DALSACAMERASWITCH.n, which gives the number of values used to get the averages, this is also 0 when then above numbers are 0, indicating the 0's came from times when framewriter-1 had no data.

Note that this behavior only occurs for second-trend and minute-trend data.

If data is missing in the raw or commissioning data, no file is written out. Thus, we never find a difference between the raw (H1_R) or commissioning (H1_C) frames between valid frames written by both framewriters. Note that the diffH1fb0vsfb1Frames process seen in the first row of green lights here,

http://ldas.ligo-wa.caltech.edu/ldas_outgoing/archiver/monitor/d2dMonitor.html

is continuously checking that the raw frames from the two framewriters is the same. (The same process runs at LLO too.)

If differences are found, it sends out an email alert.

I've never received an alert, expect when the RAID disk-arrays have either filled up (and 0 byte files were written by one framewriter) or
when the RAID disk-array hung in some way that caused corrupt files to be written. In both cases, the files on the problem array never pass FrCheck and are never copied into the LDAS system.

Thus, the above feature, is a feature of the second-trend and minute-frames only. To avoid this issue, code should check the .n channel to make sure the full number of samples were used to obtain the average. Otherwise, some of the trend data gets filled in with zeros.



david.barker@LIGO.ORG - 16:06, Thursday 23 April 2015 (18032)

Greg said:

 

Thus, I predict framewriter-1 restarted at around Apr 18 2015 06:28:00 UTC. It seems that 0's get filled in for times before that.

           

the restart log for 17th April says

2015_04_17 23:28 h1fw1

With local PDT time = UTC - 7, Greg gets a gold star.

 

daniel.sigg@LIGO.ORG - 09:24, Friday 24 April 2015 (18041)

There should also be a .n channel which tells you how many samples were included in the average.

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
Displaying reports 65501-65520 of 83069.Go to page Start 3272 3273 3274 3275 3276 3277 3278 3279 3280 End