Displaying reports 58541-58560 of 83394.Go to page Start 2924 2925 2926 2927 2928 2929 2930 2931 2932 End
Reports until 19:30, Friday 12 February 2016
H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:30, Friday 12 February 2016 (25523)
re-occurence of ALS glitches

We had another incident of ALS glitches today, this time in the X arm. We sat for a while just with the green arms locked, and the glitches became more frequent and worse and then things got better.  The glitches were bad for about an hour and a half, but you can see that something is still noisier than it was this morning. 

We have had this problem several times before: 22184

Images attached to this report
H1 ISC
jenne.driggers@LIGO.ORG - posted 19:12, Friday 12 February 2016 (25522)
ISS causing lockloss

[Jenne, Kiwamu, Sheila, Nutsinee]

We were trying to lock the IFO at lower power, so that we can see how / if that changes the DARM spectrum at low frequencies, but we have (re-)discovered the fact that the ISS loop is unstable at powers other than 20W.  So, shortly after engaging the ISS second loop we lost lock twice (once at 2W and once at 10W). 

For now, we're going to skip over the engage ISS second loop state, since we need to think more before we decide to make a change. 

H1 SUS (ISC, SUS)
jenne.driggers@LIGO.ORG - posted 18:45, Friday 12 February 2016 (25520)
SR3 cage servo setpoint modified

[Jenne, Sheila, Nutsinee, TJ]

We struggled for much of the afternoon trying to get the DRMI ASC to behave.  In the end, it seems that the SR3 OSEM values have changed now that we have a new satellite amplifier installed (see alog 25516 by Fil).  Sheila pointed out that we should trend both the WIT channels and the oplev channels for SR3, and then trust the oplev since nothing about it was changed today. 

In the attached plot, you can see that since we didn't move SR3 in yaw, the oplev value is constant but the WIT value is different.  Since the cage servo forces the WIT_P value to go to a constant pre-set value, it is the oplev that appears to move in pitch.  I have reset the SR3 cage servo setpoint to be 927, which is where it needs to be if we move SR3 so that we're back to the old oplev value.  This seems to have fixed things, and we were able to move on.

The OSEM inputs changed by about 20 counts each.

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 16:37, Friday 12 February 2016 - last comment - 10:56, Saturday 13 February 2016(25519)
Used garbage bag to measure exhaust flow of CP3
Kyle, Gerardo 

We want to know if we can use the measured exhaust flow of CP3 to distinguish between relatively low LN2 pump levels versus relatively high LN2 levels and then exploit this as part of a makeshift control loop and/or justify increasing the time interval between manual over-fills.  CP3 was last manually over-filled this past Wednesday afternoon.  So this morning, at the ~42 hour mark, we used a plastic garbage bag to capture the exhaust until the bag was taught full (see image).  We did this twice and got the following results: 

220L/90sec = 145L/min, 220L/100sec = 130L/min.  

6 hours later we manually over-filled CP3 at its normal 48 hour scheduled interval and then let the system settle down for 10 minutes or so before repeating the "bag" experiment.  This time we got the following results:  

220L/115 sec = 115 L/min.  

CONCLUSION:  

This result is surprising and not as expected.  We may instead need to have Dave B. setup the exhaust PRESSURE signal (the not-blocked sensing line) so that we can trend it (I don't think we can currently for some reason).  We already know that the exhaust pressure does vary >50% with slow over-filling so we might make a course control loop that fills CP3 based upon a preset time interval and then shuts off based upon when an exhaust pressure threshold is exceeded. 
Non-image files attached to this report
Comments related to this report
david.barker@LIGO.ORG - 10:56, Saturday 13 February 2016 (25529)

The discharge line pressure EPICS channel is HVE-MY:CP3_PT201 and it is indeed not in the DAQ at the moment, we'll add it during Tuesday maintenance.

In the mean time it is recorded every hour by the hourly autoburt backup system. Here are the commands to grep for this channel from yesterday for example (the space after the name is important)

david.barker@sysadmin0: cd /ligo/cds/lho/h0/burt/2016/02/12

david.barker@sysadmin0: grep "HVE-MY:CP3_PT201 " */h0vemy.snap

00:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

01:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

02:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

03:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 8.241758241758241e-01

04:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 7.020757020757020e-01

05:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

06:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 7.020757020757020e-01

07:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 6.715506715506715e-01

08:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 6.715506715506715e-01

09:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 7.936507936507936e-01

10:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 6.715506715506715e-01

11:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 6.715506715506715e-01

12:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.494505494505494e-01

13:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.494505494505494e-01

14:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.494505494505494e-01

15:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.494505494505494e-01

16:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 7.020757020757020e-01

17:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

18:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

19:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

20:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

21:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

22:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01

23:00/h0vemy.snap:RO HVE-MY:CP3_PT201 1 5.799755799755799e-01


 
I wrote a quick python script to plot out this channel for the month of Feb up to midnight this morning, plot is attached. I'll extend this script to plot any channel from the hourly autoburts.
Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 16:00, Friday 12 February 2016 (25512)
Ops Day Shift Summary
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:27, Friday 12 February 2016 (25518)
Attempt to center ETMY X=+30 (outside) STS2 Masses--not yet

Two of the three channels still seem to be stuck on the rail.  I did two centering pushes today.  I'll continue next week, hopefully it will stabilize by then.

H1 SUS
filiberto.clara@LIGO.ORG - posted 13:37, Friday 12 February 2016 - last comment - 19:47, Friday 12 February 2016(25516)
OMC and SR3 Sat Amp Units Modified
While investigating the high frequency oscillations seen on SR3, we decided to modified the satellite amp units for OMC and SR3 (Bottom). Two decoupling capacitors were placed on the input of the negative regulator (U503), as implemented at LLO. 

C602 0.1uf
C601 10uf

The OMC units modified are S1100129 and S1100127. For the SR3 unit, we removed unit S1000287 and replaced with a modified unit S1100074. High frequency oscillations 1.7KHz and 1.9KHz seem to have cleared. Work to continue next week, as some channels still show some noise on the spectrum.
Comments related to this report
keita.kawabe@LIGO.ORG - 19:30, Friday 12 February 2016 (25521)

SR3 should be back (but we cannot prove that until we see that the cage servo doesn't act up with pre-disaster gain.)

In the first attachment, we can see that the SR3 M3 WIT_PMON and YMON seem to have gone back to the old peak-to-peak.

In the second attachment, top right shows the comparison of now (red) and before (blue, green) of SR3 M3 LL OSEM.  After the modification (red), 1.7kHz and 1.9kHz lines obvious in blue and green are gone. I'm sure that the SR3 is fully back..

Top left shows the four SR3 M3 OSEMs as of now. None of them show kHz oscillation lines. LL is the noisiest, LR is the most quiet. There are some ugly 60Hz harmonics, and there are also a bunch of peaks that are not the power line harmonics (e.g. 142Hz). I cannot prove it but I suspect that these peaks were there before.

The bottom left shows OSEM outputs of OMC, PR3 and SRM. SRM and OMC don't have ugly power line and whatnot peaks, but PR3 look similar to SR3.

Images attached to this comment
keita.kawabe@LIGO.ORG - 19:47, Friday 12 February 2016 (25524)

Even though SR3 seems to be back to its old self,  fast OSEM is still copied to EPICS without decimation and pollutes cage servo when the oscillation comes back (and the OSEM RMS is anyway dominated by high frequency junk even when it's not oscillating).

Since these are only used for cage servo and as slow references, I put 60Hz 3rd order Butterworth LPF to all of the SR3 M3 OSEMINF (attached). This is a mild one and should not interfere with the cage servo, but reduces the high frequency junk leaking into WIT_PMON that is used by the cage servo.

Images attached to this comment
H1 PSL
kiwamu.izumi@LIGO.ORG - posted 12:09, Friday 12 February 2016 (25515)
ISS 2nd loop fully automated

The automation of the 2nd loop engagement has been updated to use the front end funcionts (alog 25473) and confirmed to be functional.

We do not have to do the manual engagement any more. Yay.

 

[some more words]

I have tested the automation once as part of the full locking sequence in this Wednesday. The test in full lock exposed some minor issues with my implementation (e.g. some settings were not properly initialized and etc). Today I fixed the IMC_LOCK code so that the automation startd from the proper initial settings. I tested the new implementation with the input mode cleaner multiple times and confirmed that it was functional as intended. The automation is fully implemented.

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:20, Friday 12 February 2016 (25514)
STS2-C moved from HAM5 area to near STS2-B in Bier Garten for Huddle testing

WP--5683; ECR-- E1500455

I've center the masses now and they seem pretty good after 4 or 5 attempts.  We'll see how things have thermally stabilized after the weekend.

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:13, Friday 12 February 2016 (25513)
See SEI Log 928 for why payload medm does not work for HAMs 4 or 5

Also II 1203.  Otherwise:

It looks like the Block Properties specifying the parameters for HAMs4 & 5 are still just duplicates of HAM3.  See attached.  There may be more to it but at the moment I'll say, I need to correct these parameters and recompile the models to get the correct medm generated.  I'll file an integration issue as I see this as just an oversite correction.

Images attached to this report
X1 DTS
david.barker@LIGO.ORG - posted 09:33, Friday 12 February 2016 (25511)
Hardware Watchdog Test System operational again

Yesterday Jim and I resurrected the hardware watchdog (HWWD) system on the DTS. It did not take too much work as the system had been pretty much left intact. We hooked up the ADC and DAC lines to the x1susey chassis and reconfigured x1boot to PXE boot the new faster computer which is running as x1susey. This front end is running the x1iopsuseywdt  and the x1susetmywdt models. We did a quick test of setting the countdown timer to 2 minutes and then disabling the OSEM LEDS (via relay unit). After 2 minutes the HWWD zeroed the SEI enable signals. Restoring the LEDs and pressing the RESET button restored the SEI drives.

I went through the wiring and  have made a new as-built drawing as sheet 2 of https://dcc.ligo.org/D1300475

H1 ISC
eleanor.king@LIGO.ORG - posted 18:03, Thursday 11 February 2016 (25510)
Gouy phase measurement stuff

Dave, Elli

We are using two cameras on ISCT6, AS_AIR plus CAM_17, sert up at different gouy phases, which we are using to measure the SRC gouy phase.  Today we shifted the positions of these two cameras, and took some images with them as we moved PR2 and BS and tracked the spot locations across the cameras.  Attached is a photo with the changes to the table. Analysis to follow.

Images attached to this report
H1 GRD
thomas.shaffer@LIGO.ORG - posted 15:25, Thursday 11 February 2016 (25507)
Small updates to DIAG_MAIN and TCS Guardians

DIAG_MAIN - Temporarily removed the HW inj test until the CW inj are running again.

TCS_CO2 - Made the nominal state LASER_UP and added them to the GUARD_OVERVIEW medm.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 14:41, Thursday 11 February 2016 - last comment - 16:39, Thursday 11 February 2016(25502)
Detection Announcement DAY Ops Summary (from morning until 2pm)

(And as if on cue, H1 had a fabulous 14hr lock stretch last night with a range near 80Mpc and it was very clean/not many glitches.  See attached image.)

The local Press Conference event occuped much of the morning and went swimmingly.  After the hub bub, here are a few of the Day's Activities:

Nutsinee has kindly offered to cover the last couple hours of the DAY.

May The Gravitational Force Be With You.

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 16:39, Thursday 11 February 2016 (25509)

22:13 Evan to LVEA wokring on 9 MHz stuff.

22:17 Elli and Dave out of the LVEA

23:06 Joe done with the Xarm beam tube filling

23:08 TJ reloading TCS guardian

23:15 Elli to HAM6 adjusting AS camera

 

Happy Announcement Day! Well done keeping GW150914 a secret until this morning =)

H1 General
kiwamu.izumi@LIGO.ORG - posted 05:49, Thursday 11 February 2016 - last comment - 14:03, Thursday 11 February 2016(25501)
Left the interferometer in observing

Evan and I left the interferometer in the observing mode at around 20:00 pm local last night. The ISS 2nd loop now keeps correcting the diffraction power all the time via a feedack loop and maintains it at 8%.

Comments related to this report
kiwamu.izumi@LIGO.ORG - 14:03, Thursday 11 February 2016 (25506)

By the way, we had a difficulty in engaging the ASC soft loops yesterday. Those loops kept dragging the optics to a point where the recycling gain is low enough to unlock the interferometer.

This issue is not resolved yet although we were able to manually engage the loops through a very careful and slow process.

I suspect some part of the interferometer has misaligned in a very subtle way.

 


[The symptoms]

The recycling gain could reach as high as roughly 38 which is more than enough to stably achieve full lock. However, as soon as the guardian came across the ASC_PART3 state, the interferometer unlocked. This happened multiple times yesterday. The error signals for all four soft loops had signals were as big as 0.2 before engaging the loops. Since the error signals are derived from the TRX and Y QPDs, this roughly means that the beam spots on TRX and TRY were off from the optimal by 20% of the QPD range. With these big offsets, once we closed the loops, the interferometer started drifting slowly away from the optimal alignment on a time scale of probably a few minutes which was then followed by rapid decrease in the sideband power in the recycling cavity and the carrier power every where on a time scale of about 10 seconds and then unlocked.

[ I don't think TMSs are culprit]

Then I looked for suspicious drift or jump in the angles of the TMSs in trend because this is very similar to the case we had during O1 (alog 22575). I did not find obvious misalignment with the TMSs in the past few days. In addition, the digital offsets in the TR QPDs seem to have unchanged at least in the past week.

For the record, in the past we had a trouble when the input optics were not well aligned (alog 23538). Looking at trends of those optics, I did not find obvious misalignment in the past few days either. The IM4 TRANS and POP B QPDs seem to have almost the same values as they should be. Performing a full initial alignment sequence did not help this issue either.

[Manual engagement]

Later, we tried engaging the loop manually and succeeded in it. This is just a test and not a permanent solution. We added an intentional digital offset to each loop so as to cancel the large signals at the error points. Then we engaged all the loops with the nominal gains. Since the error signals are already close to zero by the digital offsets, the servo did not really do on the soft degrees of freedom as expected. We then gradually reduced the digital offsets to zero very slowly so that the soft loops come back to the intended operating points. Since we did not want to lose the lock we went very slowly and took about 20 minutes or so to complete the process. Lame.

A good thing is that as we reduced the offsets, TRX, TRY and POP signal kept increasing. This indicates that the QPD signals from TRX and TRY are still good reference point. I conclude that the interferometer is the one which has been misaligned rather than the TMSs. Since the recycling gain can be still as high as 38, the misalignment we are chasing here may be something subtle.

H1 CDS
keita.kawabe@LIGO.ORG - posted 17:59, Wednesday 10 February 2016 - last comment - 12:06, Thursday 11 February 2016(25500)
SR3 cage servo problem comes from high frequency oscillation of the satellite amp (Evan, Keita)

This is yet another followup of Kiwamu's cage servo followup: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25416

In the attached left panel is a 12-days trend of SR3 signals. Left column is the EPICS version of M3 witness sensors, and PMON is used for the cage servo. Middle column is a DQ-version of the same signal.

At first YMON and PMON were going happy together with DQ version, but at around Feb 02/03 midnight UTC, PMON and YMON got huge at the same time the cage servo went crazy, but WIT_Y_DQ didn't feel it. Later when Kiwamu turned down the cage servo gain, WIT_P_DQ (middle bottom) went back to normal-ish but PMON and YMON didn't.

It turns out that when you look at non-DQ version of these signals (attached middle panel), there are huge lines in all four M3 OSEMs of SR3 at 1.7kHz and its harmonics, totally dominating the RMS (top). Bottom plot shows the comparison between SR3 (green) and PR3 (red), and PR3 doesn't show any of these huge lines.

DQ version is decimated by the frontend, but it seems like PMON (as well as YMON and LMON) are just sparsely sampled version of the fast signals, no filter modules therefore no decimation, thus the high frequency junk directly goes into low frequency (right panel).

In the past, the solution for oscillating satellite amps was to power-cycle them repeatedly until the oscillation stops.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 12:06, Thursday 11 February 2016 (25505)

(Keita, Kiwamu)

Satellite amp power cycled several times, 1.7kHz don't go away, new 1.9kHz oscillation shows up, and it won't go away either. It seems like the entire group of satellite amps are now with 1.7Hz and 1.9kHz lines (e.g attached bottom).

Attached, top blue is before power cycling, red and brown are after several rounds of power cycling, green is when the amp was powered down.

Maybe another round of pwer cycling fest, and if that doesn't do it the satellite amp swap, but not today.

Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 23:40, Monday 08 February 2016 - last comment - 16:58, Friday 12 February 2016(25451)
Oscillator amplitude noise coupling TFs into DARM

Related: 20559, 19911

Summary

I remeasured the RFAM-to-DARM TFs for the 9 MHz and 45 MHz sidebands.

The 45 MHz measurement agrees with the previous result of ~0.1 mA/RAN. However, the 9 MHz measurement is also ~0.1 mA/RAN, which is a factor of 10 higher than what was measured previously. Note that the previous "9 MHz" RFAM measurement was really a simultaneous measurement of 9 MHz and 45 MHz RFAM, since we had no 45 MHz RFAM stabilization in place.

Details

For the 45 MHz measurement, I injected into the error point of the 45 MHz RFAM stabilization servo and measured the TF from the OOL RFAM stabilization detector (which is already calibrated into RAN) to the DCPD sum.

For the 9 MHz measurement, I temporarily replaced the OXCO with an IFR running at 9.1 MHz and +10 dBm. Then I used the spare DAC channel to inject into the IFR modulation port, which was set to 10 % deviation, dc-coupled (which means a RAN of 0.071 for 1 V of input, though I did not measure this directly). The signal from the spare DAC is buffered by an SR560 and sent back into one of the spare ADC channels. Then I measured the TF from the spare ADC channel to the DCPD sum. This measurement relies on the 45 MHz RFAM servo suppressing the resulting fluctuations in the 45 MHz sidebands before they are applied to the EOM; looking at the OOL readback, this seems to be satisfied below 1 kHz. Above 1 kHz, there is a RAN increase of <2 compared to no 9 MHz injection.

Templates live in my folder under Public/Templates/Osc/(45|9)_RFAM_2016-02-08.xml.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 16:58, Friday 12 February 2016 (25517)

In addition, I took noise measurements of the 9 and 45 MHz RFAM spectra.

The 45 MHz measurement is straightforward, since we already have a calibrated, dequeued RFAM monitoring channel. (Actually I used the faster, undequeued IOP channel, calibrated it, and undid the AA filter.) the noise between 50 Hz and 1 kHz is a few parts in 109 / Hz1/2.

We don't have a similar readback channel for the 9 MHz RFAM close to the EOM, so I made a mixer-based measurement by taking an output from the ISC 9 MHz distribution amp, splitting it, and driving both sides of a level-7 mixer. I had 9 dBm into the LO and −3 dBm into the RF, so the LO was being driven hard and the RF was below the mixer's compression point. The mixer IF was terminated and then bandpassed with a 1.9 MHz filter. The IF dc was −135 mV or so.

To read out the noise, I took one of Rai's low-noise preamps (measured to have <2 nV/Hz1/2 input-referred noise) and ac-coupled the input with a 20 µF capacitor (giving a high-pass pole at <0.1 Hz). Then I read out the noise with an SR785. I have not yet verified that the signal is above the noise floor of the mixer measurement.

Finally, I also include the RFAM-to-DARM coupling TFs with the DARM loop undone.

Images attached to this comment
Non-image files attached to this comment
Displaying reports 58541-58560 of 83394.Go to page Start 2924 2925 2926 2927 2928 2929 2930 2931 2932 End