Displaying reports 66881-66900 of 84440.Go to page Start 3341 3342 3343 3344 3345 3346 3347 3348 3349 End
Reports until 22:23, Thursday 23 April 2015
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
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 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 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.

Displaying reports 66881-66900 of 84440.Go to page Start 3341 3342 3343 3344 3345 3346 3347 3348 3349 End