Displaying reports 67521-67540 of 84476.Go to page Start 3373 3374 3375 3376 3377 3378 3379 3380 3381 End
Reports until 08:12, Tuesday 24 March 2015
H1 General
edmond.merilh@LIGO.ORG - posted 08:12, Tuesday 24 March 2015 - last comment - 16:47, Tuesday 24 March 2015(17417)
IFO RELOCK at LOWNOISE_ESD_ETMY

08:08 IFO fully locked @ ~ 18Mpc  (according to SensMon).

Comments related to this report
edmond.merilh@LIGO.ORG - 08:42, Tuesday 24 March 2015 (17418)

Broke lock @ 08:41 :( Not bad for a maintenance day!

sheila.dwyer@LIGO.ORG - 16:47, Tuesday 24 March 2015 (17440)

It seems as though after dropping lock the IFO came back twice (on its own or with some help from Ed?), with one locking attempt that failed in locking DRMI_1F.  

The attached plots show the guardian state from 13:20 UTC to 16:20, the longest steps in the relocking process are still finding IR and locking DRMI, the long DRMI lock was about 8 minutes, the total time to recover from the lock loss was about 40 minutes (inlcuding the failed attempt), and the second time it took 15 minutes.  

I think we can say that we now have some "one click" locks, unless Ed had to intervene in some way to lock this.    

Images attached to this comment
H1 ISC (DetChar, ISC)
lisa.barsotti@LIGO.ORG - posted 02:28, Tuesday 24 March 2015 - last comment - 22:19, Tuesday 24 March 2015(17411)
ETMY low noise ESD, MICH feed-forward, ASC cut-offs, low noise coil drivers (started), 28 Mpc
Evan, Sheila, Dan, Kiwamu, Lisa 

SUMMARY 

The wind dropped below 20 mph in the evening, and we started locking. After some roll, bounce and violin damping, we made it to DC readout @ 8W. We successfully transitioned DARM to ETMY with low noise ESD and got some MICH feed-forward cancellation going. We improved the noise between 30-200 Hz, and reached  28 Mpc  (according to SensMon). 

The noise was more stationary than  previously observed . 

However,  the OMC is still shaking , and it is not good. Dan has a resonant gain for DARM ready to be tested to reduce the noise around 3 Hz, but we didn't manage to get that done tonight. 

We leave the interferometer locked at 28 Mpc starting at March 24, 2015 9:17 UTC . 


DARM control on ETMY with low noise ESD  

We did the transition from ETMX to ETMY L2 for DARM, but the interferometer was very glitchy, and we decided to abandon L2 control and try the new  Den's strategy  to do the feed-forward to ITM(Y) L2. 
Evan got about a factor of 10 subtraction (FM9 has BS plant inversion in LSC-MICHFF filter bank, gain +0.048). 

ASC cut-off filters 

Since none of the ASC loops had cut-offs, we decided to add  some . They are now engaged by the Guardian. A more fine tuning will happen at some point. 

Started switching coil driver to low noise  

We started switching the coil driver to  low noise . Evan will post a table later with the successful switches we did after acquiring the DRMI lock. We need to do more work on this, some failed.
Comments related to this report
evan.hall@LIGO.ORG - 02:35, Tuesday 24 March 2015 (17412)

Spectra attached.

Images attached to this comment
daniel.hoak@LIGO.ORG - 02:38, Tuesday 24 March 2015 (17413)

Here is a plot of the lingering coherences with LSC DOFs.

Images attached to this comment
gabriela.gonzalez@LIGO.ORG - 05:15, Tuesday 24 March 2015 (17414)
Very nice progress! 
albert.lazzarini@LIGO.ORG - 05:53, Tuesday 24 March 2015 (17415)
Excellent news. Great progress. 
thomas.massinger@LIGO.ORG - 09:48, Tuesday 24 March 2015 (17420)DetChar

This is fantastic progress, congratulations!

For anyone that would like to look at the data quality or run any DetChar tools on this data, the following GPS times can be used:

1111223896 - 1111239923

Duration: 16027 seconds

nergis.mavalvala@LIGO.ORG - 11:52, Tuesday 24 March 2015 (17426)
This entry should make Lisa a contender for her "best log entry" prize. Nice going, everyone!
evan.hall@LIGO.ORG - 22:19, Tuesday 24 March 2015 (17449)

These are the coil driver states that we've been using so far:

OLD PRM PR2 SRM SR2 PR3 SR3 BS
M1   1 1 1 1 1 1
M2   2 2 2 1 1 1
M3 2 2 2 1 1 2

 

OLD IX IY EX EY
R0 1 1 1 1
M0 1 1 1 1
L1 3 3 2 2
L2 2 1 1 1

Now we've managed to switch to the following configuration for acquisition (following the tables in LLO#16565):

ACQ PRM PR2 SRM SR2 PR3 SR3 BS
M1 2 2 1 2 2 2 1
M2 2 3 2 3 3 3 2
M3 2 2 2 2 2 2

 

ACQ IX IY EX EY
R0 1 2 1 1
M0 1 2 1 1
L1 3 4 2 2
L2 2 1 1 1
 

Green indicates a low-noise state, and red any other state. So far we have encountered the following things:

  • If any stage of the SRM is switched to a low-noise state, it will start to saturate. We are trying to figure out whether this is a problem with the LSC (which feeds back to M2 and M3) or the ASC (which feeds back to M1).
  • ITMX M0 appears to be miswired; changing the state request appears to affect the test/coil bits instead, resulting in an error. Jeff and Richard are looking into this.
H1 ISC
daniel.hoak@LIGO.ORG - posted 22:08, Monday 23 March 2015 - last comment - 09:56, Tuesday 24 March 2015(17409)
history of OMC RIn around 1-5Hz

Lisa, Dan, Sheila, Evan, Kiwamu

We checked the evolution of the flickers in OMC TRANS over time.  It appears that the features between 1-5Hz have always been there, but the amplitude has grown by a factor of ~3-6 in the past two weeks.

In the attached plot, the ampltiude of the 3Hz peak on Mar 6 was about 0.004 / rt[Hz], and today it is 0.02 / rt[Hz].

We've added rolloffs to the ASC loops, turned on the 'resg1' filter in the ETMY_M0_DAMP_L filter bank (this adds a RG at 1Hz and an overall gain of +6dB), and looked accusingly at the OMC TRANS camera image.  No change so far.  Next idea is to try a boost in the DARM loop gain at low frequency.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 22:10, Monday 23 March 2015 (17410)SUS

The cut offs we added are elliptical low passes at about a factor of 10 above the ugf of several of our ASC loops (INP1, PRC1, PRC2, SRC1, SRC2 pitch and yaw). These are engaged in the gaurdian now.  We do not see anylarge changes in the noise, neither the low frequency noise that dominates the OMC DC PDs nor in the bucket.  With all of these loops and CHARD (cETM) off we saw that the noise bellow 10 Hz was a little better.  We attempted to add a ELP30 to MICH pitch, which broke the lock. 

Also, for SUS SDF, we have added notch filters for the Bounce and roll mode to the ITM L2 stages, as well as compensation for the new ESD low passes in ETMY L3 ESDOUTF

gabriele.vajente@LIGO.ORG - 09:56, Tuesday 24 March 2015 (17422)DetChar, ISC

The OMC transmitted power fluctuations at frequencies below 20 Hz is completely coherent with the power fluctuations before the OMC (see for example ASAIR_A_LF or ASAIR_B_LF), as shown by the attached plots taken from the brute force coherence report.

I believe this is telling us that the OMC flicker is due to power fluctuations inside the IFO, and not generated by the OMC control. Maybe improving the longitudinal and angular stability will help.

Images attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 19:36, Monday 23 March 2015 (17406)
high wind today, Y green PDH kept unlocking

Lisa, Evan, Sheila, Keita, Jim W, Kiwamu,

Today we had an issue in which the Y end PDH loop kept unlocking due to a high longitudinal motion (more than 12 um peak-to-peak at 50 mHz). The wind was high at 20 mph on average with 40 mph at highest most of the time today starting from 9 am local. In this report I attempt to summarize the issue associated with today's windy condition.

 


(Y arm motion was too high)

When we started fully locking the interferometer, we noticed that the ALS loops frequently dropped their locks in the middle of the locking sequence. It turned out that the Y arm motion was so high the end VCO saturated in every several minutes. The X PDH also had a similar amplitude but it was slightly smaller than that of the Y arm by ~ 20% which barely allowed the X arm to stay locked. The attached is a 5 minutes trend of relevant channels under a condition that:

As shown in the plots, the Y arm PDH control signal (ALS-Y_REFL_CTRL_OUT_DQ) went up and down at a frequency of 50 mHz. This channel is calibrated into the Y arm displacement in um. When it went below -7 um or above 7 um it unlocks essentially because the end VCO rails. The X arm showed a similar amplitude, but amplitude was not as big as that of the Y arm. The X arm dropped the lock less frequently than the Y arm.

 

(Some attempt with a high band width tidal)

We then started increasing the bandwidth of the local tidal feedback which picks up signals from the end PDH control and offload it to the L1 stage of ETMY. The idea is that we wanted to physically quiet down the ETMY motion so that the VCO can stay within the range. We increased the gain of both X and Y local tidal loops by a factor of 3. So their UGFs are now 0.1 Hz.  At the end the attempts, the wind incidentally came back down to 10-30 mph so we can not really say if this scheme helped.

Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 16:50, Monday 23 March 2015 (17405)
Added SYS_DIAG Guardian node to the overview screen

I added a new Guardian node to the overview screen today (screenshot attached). SYS_DIAG will run different tests to check for particular conditions. If a test finds a problem it will bring up a notification. Just like other Guardian nodes, opening the main screen will allow you to click on all notifications and see the entire list, otherwise it will cycle through them in the space provided on the mini.

I will still be tweeking little things here or there, but it is definitely usable/useful now.

The tests that it currently runs are :

When you select the requested state to INIT the log will list out the tests that it is currently running.

If there are other tests that you would like to see on here please let me know!

Images attached to this report
LHO VE
bubba.gateley@LIGO.ORG - posted 16:13, Monday 23 March 2015 (17404)
Beam Tube Washing
Scott L. Ed P. Chris S.

61 meters cleaned towards single door between X-1-6 and X-1-7.
Continuous monitoring of beam tube pressures by control room operator during cleaning operations.
LHO FMCS
bubba.gateley@LIGO.ORG - posted 16:07, Monday 23 March 2015 (17403)
Axial fan lubrication W. P. 5113
Bubba John W.

All of the axial fans are lubricated.
Corner station SF 4 has at least 1 bearing that needs to be replaced and is currently off line awaiting parts. We will monitor the LVEA temperatures very closely but this should not have any adverse affect on the temperatures. 
End X SF 2 also has a bearing that is suspect. This fan is off also. 
H1 General
edmond.merilh@LIGO.ORG - posted 16:02, Monday 23 March 2015 (17382)
Daily Ops Summary

07:00 Cris and Karen into the LVEA

08:25 RMS wathcdogs tripped on ETMs. ETMY reset from medm reset. ETMX still showing a trip on L2 UL.

08:53 RMS trip on L2 ETMX cleared by power cycle

09:35 ISS diff power was up to 10% +. I adjusted the refsignal to (-)2.07 for a net diffracte power of ~7%.

10:07 R McCarthy back from installin ESD filter at EY

10:16 Bubba to start greasing fans at mid stations. (MidX first)

10:45 Jim switched end stations from 45MHz ISI filter blendsto 90MHz filter blends due to the SSW winds exceeding 35-40 mph.

11:21 Jodi to MidY

11:34 Bubba movning to mid Y 

12:02 Very windy day today. Sustained winds at ~26mph with gusts exceeding 40 at times

12:15 D Barker and J Batch to EX (non VEA)

12:55 Bubba and John to EX to grease fans

13:27 D Barker and J Batch to EY (non VEA) to address TCT (timing) problem.

13:46 Bubba and John to EY to grease fans

14:30 Calum and Kate on site

14:35 Bubba and John back from Ends. 

16:00 Bubba done with fans.

H1 DetChar
duncan.macleod@LIGO.ORG - posted 14:28, Monday 23 March 2015 (17401)
New 'DetChar' task

This message tests the automagic emailling of the detchar@ligo.org list when the 'DetChar' task is used on a post.

H1 ISC (DetChar, ISC)
gabriele.vajente@LIGO.ORG - posted 12:41, Monday 23 March 2015 (17400)
Non stationary noise

Again following un on Kiwamu's report, I took a look at the non stationarity of the noise during the low noise lock.

In brief, the largest contribution to noise in the 50-200 Hz region comes from MICH/SRCL, and it'slargely modulated by angular motions, mainly ETMs and (maybe) PRM.

Some more details follow. The first plot shows a spectrogram, with a quite clear almost periodic fluctuation of the noise. As usual, I computed the BLRMS in the 100-200 Hz region, to obtain the second plot. In the same plot I show the reconstructed BLRMS using local witness sensors of all main mirrors. The reconstruction is resonably good, and the channel ranking (figure 3) seems to indicate that PRM and ETMY are the most important contributors to the noise non stationarity.

A much better reconstruction of the BLRMS time variation can be obtained using the WFS and QPD angular signals, as shown in figure 4 and 5. The BLRMS is almost perfectly reconstructed. The channel ranking shows that AS_B_RF45_Q is the largest contribution, which seems to confirm that DHARD is important. The strange thing is that I can't see any signal here to indicate that PRM is important.

The last three figures show a "coherogram" (not sure if this word really exists) of DARM with auxiliary d.o.f.s output. Those plots show the coherence as a function of both frequency and time, similarly to what a spectrogram does. Clearly, the fluctuating noise is due mainly to SRCL noise, with a coupling coefficient strongly modulated by the angular fluctuations.

Images attached to this report
H1 ISC (DetChar, ISC)
gabriele.vajente@LIGO.ORG - posted 11:55, Monday 23 March 2015 - last comment - 20:34, Monday 23 March 2015(17397)
Brute force coherence

Following up on Kiwamu's report, here is the summary page for the coherences during the low noise lock:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1110961816/

As usual, here is my digest.

In brief: we need MICH/SRCL subtraction, check SRC angular controls, they might be injecting noise, better tune the IMC longitudinal offset if possible

More details:

P.S. Why are you sending DARM signal into the CARM filter bank?

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 12:03, Monday 23 March 2015 (17399)

Ahh you caught on to our hacky audio setup, Gabriele.  The OMC-DCPD --> CARM matrix element is enabled so that we can filter OMC-DCPD in the CARM bank before sending it to speakers in the control room.  (Actually I'm not sure anyone is using this anymore, we can probably discontinue it.)

daniel.hoak@LIGO.ORG - 20:34, Monday 23 March 2015 (17407)

Also I have modified the ITMX violin mode damping so that there is 50x less gain at 450Hz.  (There is an 8th order butterworth bandpass now, instead of a 4th-order.)  This might make the noise a little worse between 480-510Hz, but I think that band is a lost cause anyway.

H1 SEI
jim.warner@LIGO.ORG - posted 10:59, Monday 23 March 2015 - last comment - 21:48, Monday 23 March 2015(17395)
Blends changed on EX/EY ISI's due to wind

Commissioners were complaining of excess arm motion, so I've changed the blends on the beamline directions on St1, from the nominal 45mhz blends to 90mhz. To review for those not in the seismic know, this is done by opening the St1 Blend screen from the BSC ISI overview and clicking on the 90mhz blend in the appropriate direction (i.e. X for ETMX, Y for ETMY). Attached screens show overview with circled blend screen, St1 Blend overview, close up the blend X bank. It's not perfectly clear that we need to be using the 45mhz blend or if the 90mhz blend is good enough, but I've been talking to some of the commissioner about maybe doing an assessment when it's convenient.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 21:48, Monday 23 March 2015 (17408)

They are switched back since the wind died down

H1 SEI
jim.warner@LIGO.ORG - posted 08:44, Monday 23 March 2015 - last comment - 16:31, Monday 23 March 2015(17386)
BRS appears to be broken

TJ asked me about the BRS this morning, as it was tripping an alarm he had set. When I opened the overview, the numbers were rather large and swinging rapidly (over a minute it was going from -40000 cts to +40000 cts, the transition was a couple seconds. The attached dataviewer trend shows it has bee doing this since the 21st, starting about 15:00 UTC. No clue what happened.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:38, Monday 23 March 2015 (17388)DetChar
A little bit more supporting data: I attach a time series of the drift monitor (the DC comparison between the autocollimator's fringe patterns for the balance mirror and reference mirror; in military green; H1:ISI-GND_BRS_ETMX_DRIFTMON) and control signal for the gravitational damping motor (in dark red; H1:ISI-GND_BRS_ETMX_DAMPCTRLMON).

I suspect the suspension has drifted enough that fringe patterns have crossed causing the output of the sensor to go non-linear. This then rung up the suspension after the damper turned on thinking that the SUS had rung up. Then we get into a nasty feedback loop.

Looks like the temperature in the XVEA has remained stable over the weekend (and for several days prior), so I doubt we can blame the temperature swings for the cause of the drift.

For now, Jim and TJ have turned off the control software to let the suspension cool off. We'll do a more invasive investigation tomorrow morning.
Images attached to this comment
krishna.venkateswara@LIGO.ORG - 16:31, Monday 23 March 2015 (17402)

I've attached a couple of plots showing the BRS_DRIFTMON channels. First one shows the 1-hr period when the BRS data started to grow large. It looks like some 'disturbance' set it off and then the damper took it away with a positive feedback loop because it was in the incorrect position.

The next plot shows the same channel over 3 days, starting from 2 days before the disturbance. It looks like the mean position was quite stable ( except for the odd missing dataset). Once the positive feedback loop got started, it drove the turn table harder and harder, generating heat and causing the mean position to shift slowly. Once things settle down, the mean position should return to ~ -2.9k counts. This is well within the linear range of BRS.

Due to the large amplitudes BRS reached before the software could be turned off, I'm not sure it will be sufficiently damped so it could be restarted tomorrow.

Images attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 09:49, Tuesday 17 March 2015 - last comment - 12:10, Monday 23 March 2015(17293)
Roll mode damping on ITMX and ETMY with AS WFS

Dan, Kiwamu,

At one point last night, we noticed that a roll mode rang up at ~14 Hz. The peak height in the DARM spectrum (ffted with a 0.1 Hz BW) exhibited a anomalously high value of more than 10-12 m/sqrt Hz.

So we worked on damping the peak, this time with the AS_WFS_A_45Q signal (alog 16864) which is a state-of-the-art Livingston technique. We were successfully able to damp the mode to an ordinary height of about 10-14 m/sqrt Hz level in the DARM spectrum.

 


(Identification process)

First of all, see how terrible the roll mode was:

The red curve is from Mar-17-2015 8:51:00 UTC and we were intentionally stayed on the rf DARM rather than the DC readout to combat the roll mode. Even though there was some confusion in identifying which suspension had been rang up, eventually we confirmed that the roll mode was from ITMX by taking coherence between AS_WFS_A_45Q and the OPLEV_PIT signal of each test mass. In fact, the ITMX oplev was able to see the roll mode in its spectrum with a peak ~ 10 times higher than the noise floor while the rest of the oplevs did not see a visible peak.

In addition, after the successful damping on ITMX, the AS_WFS_A still showed a bit high peak but with a slightly lower frequency (~ 200 mHz ) than that of ITMX. We then identified that this was in turn from ETMY by looking at the coherence again. This lead us to another damping work on ETMY which we were also able to damp.

 

(Damping setup)

The AS WFS_A signal was routed from the ASC model with a gain of +1 (in ASC_OUTMATRIX_TESTMASS_DAMP). I found that both were damped well with a positive gain in SUS-E(I)TMX(Y)_M0_DAMP_R.

As for ITMX, I ended up with FM3 (-100 dB), FM4 (bp13.9) and a gain of +40. Although I had to start from a gain of +1 in order not to saturate the DAC due ot the high amplitude in the roll mode. Then I gradually increased the gain as the DAC counts reduced. Once I went to a gain of more than 10, the mode was damped relatively quickly probably on a time scale of about a couple of minutes.

As for ETMY, I ended up with FM4 (bp13.9) and a gain of +0.0008. At one point I went to a gain of +0.005, but this actually started increasing the peak height. So I had to set the gain back to + 0.0008. This loop could damp out the mode on a time scale of a couple minutes as well.

 

(Why they rang up ?)

We don't know.  One observation is that before the modes rang up, Sheila was trying to increase the recycling gain by manually touching the ITMs.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 18:01, Tuesday 17 March 2015 (17318)DetChar, SUS
What's the exact frequency (or at least to ~0.01 [Hz] precision)?

Remember, I was able to distinguish two mode frequencies in LHO aLOG 16868: a 13.18 [Hz] mode or the 13.81 [Hz] mode, which I'd narrowed down to an ITM and an ETM mode respectively. It would be good to catalog is the ITMX mode you say rung up.

@DetChar -- you're more than welcome to answer this, if Dan or Kiwmau can't get back to it quickly. The time you should use is listed in the bottom corner of the DTT screen capture.
rana.adhikari@LIGO.ORG - 23:01, Tuesday 17 March 2015 (17323)

since the color of the Time text is the same as the reference, I guess that's not the right time. Better to use the time of the RED live trace.

andrew.lundgren@LIGO.ORG - 12:10, Monday 23 March 2015 (17398)
Looks like about 13.98 Hz, accurate to 0.01 Hz. I used 5 mins of data, 120 sec FFT, overlap of 0.9. I used the time mentioned in the log entry (8:45 UTC Mar 17) since the data didn't look right around the time in the DTT screen.

We don't have a nice tool for quickly marking the peaks in spectra. I'll look into making one.
Images attached to this comment
Displaying reports 67521-67540 of 84476.Go to page Start 3373 3374 3375 3376 3377 3378 3379 3380 3381 End