Displaying reports 65941-65960 of 83026.Go to page Start 3294 3295 3296 3297 3298 3299 3300 3301 3302 End
Reports until 18:50, Friday 27 March 2015
H1 ISC (ISC)
lisa.barsotti@LIGO.ORG - posted 18:50, Friday 27 March 2015 - last comment - 10:47, Saturday 28 March 2015(17543)
Quick note about current status (36 Mpc)

Commissioning Team

We will write a more meaningful entry later, but here is a list of things we did/tried this afternoon, so we don't forget:

We collected a ~ 2h lock with range around 36 Mpc (not clean data).

 

 

Comments related to this report
sheila.dwyer@LIGO.ORG - 19:13, Friday 27 March 2015 (17545)GRD

We now have a problem we haven't encoutnered before. The ISC_LOCK guardian has SPM DIFFs errors, because of dead channels.  There are ten channels related to the ALS_COMM guardian listed as the SPM diffs, I don't know if these are all of them or just the first ten.  Attached screen shot shows the list, and also that we can caget these channels.  Kiwamu and I restarted the guardians, which made no difference, then we tried destroying them as well, with the same result.  

Images attached to this comment
sheila.dwyer@LIGO.ORG - 19:39, Friday 27 March 2015 (17547)CDS, ISC

This morning Elli and I retuned the dark offsets for the transmon QPDs, after doing this we were able to do the entire CARM offset reduction without using the in air transmission PDs.  After this succeeded we closed the beam diverters, redid the initial alignment, and attempted to lock.  We failed at the TR_CARM step three times in a row, so we opened the beam diverters and re did the initial alignment.  After that we were able to lock without using the In air PDs, which is what we have been doing all day.  

The current situation is that the End X beam diverter is closed, and End Y is open.  Kiwamu re did the initial alignment in this situation, and when we have ALS locked we can see that the spots are well centered on X end transmission QPDs.  We were hopping to try locking like this, but ran into difficulties with the mich lock acquisiton attempts breaking the lock of ALS DIFF.  We saw that the beat note power has slowly drifted down over the last few weeks, (from 0.5 dBm to -0.5 dBm), so we though it could be that a small alignment kick to the BS is enough to loose the beat note completely.  Its hard to verify this theory since we don't trust the timing between the Beckhoff and the RCG.(alog 17455)  I went to the table and touched up the beat note alingment, now it is about 0 dBm.

jameson.rollins@LIGO.ORG - 20:21, Friday 27 March 2015 (17548)

I tracked down the guardian communication problem to the following code in the /opt/rtcds/userapps/release/isc/h1/guardian/bs_m2_switch.py module:

import ezca
ezca = Ezca()

This is NOT OK to put in any module being imported by guardian code.  This creates a second, separate instance of the EPICS interaction object, that interferes with the one created and supplied by guardian itself.  It effectively breaks all EPICS interaction in the guardian node, which is what happened here.

If you think you need to do something like this please contact me and we'll figure out a better way.

Presumably this module was newly added to the ISC_LOCK node before the problem arose, and the reported breakage happened after it was reloaded.  After removing those lines from bs_m2_switch.py everything now appears to be working normally.

 

As an aside, please always provide FULL DISCLOSURE when reporting problems like this.  Usually things don't break spontaneously on their own.  Whatever was being done right before you saw the problem is probably what caused it.  (Kiwamu: if you didn't know about this change when we spoke on the phone then you're off the hook).

daniel.hoak@LIGO.ORG - 00:20, Saturday 28 March 2015 (17552)ISC

Evan, Dan

The Guardian issue was fixed when we returned from dinner, but then the winds came.  We switched the end station ISI's to the 90mHz blends and increased the tidal gains; the common UGFs are now 0.1Hz (were 0.05Hz) and the X-arm tidal UGF is 0.1Hz (was 0.06Hz).

Initially we observed the same problem that Sheila reported, the ALS would lose lock as soon as the DRMI started to drive the mirrors.  But after mucking with the DRMI alignment for a little while (not at all sure that this helped), I have been able to acquire lock with DRMI a couple of times.  A test of applying a large DC offset into the BS longitudinal drive does not break the ALS_DIFF lock, so maybe that problem is no longer a problem.

There is now a new problem, the DRMI Guardian isn't happy with the state DRMI_LOCKED_1F_ASC (which is the requested state from the ISC_LOCK Guardian).  Upon finishing this state is recalculates the path and jumps back to LOCK_DRMI_1F, see the attached log, and the attached graph.  This has happened three times now.

Also attached is a plot of our progress since Monday night.  I am leaving the IFO set to CHECK_IR to acquire ALS data during the windy conditions.

Images attached to this comment
evan.hall@LIGO.ORG - 22:56, Friday 27 March 2015 (17550)

For MICH FF, the filters used are FM6 and FM7 (which are stopbands for the violin modes and harmonics), and FM9 (which inverts the BS M2→M3 plant). The gain is 0.040 ct/ct.

For SRCL FF, the filters used are FM6 and FM7 (as above). The gain is −2.5 ct/ct.

Both feed back only to ITMY L2.

Also attached is a text file and noise budget of a good spectrum from today. I would like to remark that

  1. the GWINC model used here does not take into account the low recycling gain that we see in our current locks, and hence may underestimate the true shot noise; and
  2. the actuation coefficient for the ESD in this budget is a canned value, and we have seen previously that it may be an overestimate.
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 21:46, Friday 27 March 2015 (17551)

Thank you so much Jamie.

I think bs_m2_switch.py is a code that TJ, Sheila and I have been preparing today. I was aware of the active coding effort that TJ has been putting today, but I simply did not know that bs_m2_switch had been already loaded in the ISC_LOCK guardian. My apologies that I did not collect and did not provide all information about the coding activities on ISC_LOCK at around the time.

jameson.rollins@LIGO.ORG - 10:17, Saturday 28 March 2015 (17557)

Dan: the ISC_DRMI assert_drmi_locked GuardStateDecorator (defined in ISC_library.py) is wrapping the methods in DRMI_LOCKED_1F_ASC, and it returns 'LOCK_DRMI_1F' if DRMI_locked() returns False.  The obvious explanation for the behavior you saw is just that DRMI_locked() was False.  Here's what's currently defined in that function (at least from what's currently committed to the USERAPPS):

def DRMI_locked():
    #log('checking DRMI lock')
    return ezca['LSC-MICH_TRIG_MON'] and ezca['LSC-PRCL_TRIG_MON'] and ezca['LSC-SRCL_TRIG_MON']

sheila.dwyer@LIGO.ORG - 10:47, Saturday 28 March 2015 (17558)

The epics problem was my bad.  I imported bs_m2_switch but didn't think of it when I called Jamie since we weren't calling it I assumed it couldn't be doing much.  Apologies.  

H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 18:15, Friday 27 March 2015 (17541)
Pcal lines running at 33.1 Hz and 534.7 Hz at LHO ENDX

SudarshanK. RickS

After doing some alignment work and calibrating the ENDX photon calibrator yesterady, we are running the pcal lines now at 33.1 Hz (38 cts excitation amplitude) and 534.7 Hz (28570 cts excitation amplitude) both producing an SNR of about 20. These frequencies are in line with the agreed upon frequencies as reported in LLO alog #15870. The calibration coefficient for these pcal lines can be found in LHO alog #17525.

H1 SUS (DetChar, ISC)
nutsinee.kijbunchoo@LIGO.ORG - posted 17:05, Friday 27 March 2015 (17529)
ITMs, ETMs Violin mode frequencies pair up

Because of Dan's effort in damping the violin modes (alog17502 and alog17365) I was able to come up with a modes pair-up scenario. A total of 33 lines were found but not all of them are identified (we don't know which test mass some of them belong to) so I had to make a decision and cast one of the unidentified lines aside (501.486) as it may not have come from the violin modes and not seen in the most recent lock stretch. According to Agnus the line saperations anywhere from 0 to 0.15 is reasonable. The tables below contains the frequencies of the lines we found, the averages of the pairs, the width of saperations, and the test masses they belong to. Dan was able to identify most lines unless note otherwise (as "unidentified"). The original Excel file also attached. The next step would be identifying which fibers these lines belong to!

 

ITM pair Average |width| test mass
500.0535 500.13275 0.08 ITMX
500.212     ITMX
501.092 501.15 0.06 ITMX
501.208     unidentified
501.254 501.352 0.1 ITMX
501.45     ITMX
502.621 502.6825 0.06 ITMX
502.744     ITMX
503.007 503.063 0.06 ITMY
503.119     ITMY
504.803 504.83725 0.03 unidentified
504.8715     ITMY
501.606 501.6775 0.07 unidentified
501.749     ITMY
501.682 501.7465 0.06 ITMY
501.811     unidentified

 

ETM pair Average |width| test mass
507.992 508.069 0.08 unidentified
508.146     ETMY
508.0095 508.10775 0.1 ETMY
508.206     ETMY
508.22 508.25425 0.03 ETMY
508.2885     ETMY
508.585 508.623 0.04 ETMY
508.661     unidentified
505.587 505.647 0.06 ETMX
505.707     ETMX
505.71 505.7575 0.05 unidentified, sometimes distinguishable from 505.707
505.805     ETMX
506.922 507.0405 0.12 ETMX
507.159     ETMX
507.194 507.2925 0.1 unidentified
507.391     ETMX
Non-image files attached to this report
H1 DetChar (DetChar, ISC)
daniel.hoak@LIGO.ORG - posted 16:47, Friday 27 March 2015 - last comment - 19:01, Friday 27 March 2015(17537)
mHz resolution spectrum, with known features

Using the latest BRUCO results, I've annotated a hi-res spectrum from last night's lock.  Peaks, bumps, and so on are labeled with the largest coherent channels.

There are a few peaks, at 46, 166, 420, and 689Hz, that are coherent with PRCL/SRCL, and they have changed since the blue reference (Mar 19th at 18:00).  This might be due to the POP --> POPAIR switch.

The source of the 300Hz lines has been identified, it's the BS violin modes.  The frequency is given in Mark Barton's table of predicted violin resonances (thanks Jeff!).

We turned off all the ring heater power supplies yesterday; this got rid of a line at ~74Hz but didn't change the 55Hz line and its harmonics.  These lines are certainly due to some electronics in the EX racks.

Features coherent with the IMC WFS and the PSL persicope are probably the same thing (input beam jitter), hopefully from the same source (PSL PZT mount).

Images attached to this report
Comments related to this report
rich.abbott@LIGO.ORG - 16:52, Friday 27 March 2015 (17538)ISC
As I think is known, there is a filter solution for the ring heater driver to eliminate the fan noise.  It is the same basic design as was used in the Seismic Coil Driver fans.  We just need to make these available for installation soon.  Added this to my to-do list.
gabriele.vajente@LIGO.ORG - 16:52, Friday 27 March 2015 (17539)

The 160 and 420 Hz peaks are moving in frequency with a timescale of some minutes. The moves in a coherent way, in the sense that the frequencies seem pretty much to maintain a ratio of 2.5

See my previous log entry for an analysis of the line wandering.

daniel.hoak@LIGO.ORG - 19:01, Friday 27 March 2015 (17544)ISC, TCS

It turns out the 55Hz line is actually a 57Hz line, and it's the Hartmann camera.   This was explored in detail at LLO a long time ago, I should have remembered.

I have turned off the HWS box in the EX electronics rack.  This eliminated the 57Hz line and harmonics from the rack magnetometer, but for some reason the overall noise floor has increased, see attached.  Probably turning off the camera is a better solution, as Aidan recommends in the LLO log.  We'll see if this affects the noise.

Images attached to this comment
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:26, Friday 27 March 2015 (17536)
Daily Ops Summary

== Activities ==

7:40 Cris to LVEA

8:00 Cris out of LVEA

9:00 Lock Loss

        Kiwamu to EY to reset ETMY ESD

9:22 Kiwamu back

11:14 Jodi to Mid X and Mid Y

14:50 Kyle back from mid stations (No notes of when he went out... Kyle and Jodi together?)

 

Best lock range at LHO ever. Happy Friday.

LHO VE
kyle.ryan@LIGO.ORG - posted 15:03, Friday 27 March 2015 (17534)
Shortened (tube cutter, solder caps) chilled water 1/2" copper lines in X-mid VEA
Kyle, Gerardo 

Pressurized lines -> no leaks.  

Attempting to clear a path for under tube pallet jack traffic and ease 3IFO storage and also to eliminate need for overhead crane.  

Instrument air and copper grounding cable still need to be re-routed off of the floor
LHO VE
bubba.gateley@LIGO.ORG - posted 13:57, Friday 27 March 2015 (17533)
Beam Tube Washing
Scott L. Ed P. Chris S.

The crew was able to complete tube cleaning to the X-1-7 double doors. 
Results are posted here.
The afternoon will be spent doing P Ms on the equipment and relocating to the next section to be cleaned.
  

Non-image files attached to this report
H1 ISC (CAL, CDS, DetChar, GRD, INS, IOO, ISC, SEI, SUS, SYS)
jeffrey.kissel@LIGO.ORG - posted 08:58, Friday 27 March 2015 - last comment - 07:47, Saturday 28 March 2015(17515)
Great sensitivity all night long!
J. Kissel, J. Warner, J. Romie, H. Radkins, N. Kijbunchoo, K. Izumi, G. Moreno

SUMMARY: We just finished ~7 HOUR lock stretch at our best sensitivity ever, between 32 and 34 [Mpc]!

We've all been pleasantly surprised this morning to see that the lock stretch that Sheila Evan, Dan and Lisa started last night lasted the entire night. Unfortunately, as of ~10 minutes ago (~8:40a PDT, ~15:40 UTC), there are GIANT glitches and non-stationarity that keep popping up, spoiling the sensitivity. There's no one in the LVEA, so we're not at all sure what's caused the sudden change in behaviour. Wind seems fine at ~5 [mph], ground motion is still pretty low, the 1-3 [Hz] hasn't even come up yet.

Anxious to explore things, Jim installed some low-pass filters in the HAM5 and HAM6 ISIs at around 8:45 to try to reduce scattering / acoustic coupling to the ISI, and Kiwamu began exploring MICH coupling to DARM. 

But, as I write this log, we lost lock. However, for DetChar purposes, one can assume the detector was undisturbed from March 27 9:00 UTC to March 27 ~15:00 UTC.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:17, Friday 27 March 2015 (17516)
K. Izumi, J. Kissel

For the record: Kiwamu drove down to the EY end station to check: *this* lock loss did *not* cause the EY ESD Driver to trip. Huh.
gabriele.vajente@LIGO.ORG - 11:21, Friday 27 March 2015 (17526)DetChar, ISC

Looking at spectrograms of DARM during the first hour of lock (first plot) and the last hour (second plot), it seems to me that the noise is more or less stationary, but there are huge glitches. They are so big that you can even see them easily in time domain (third plot). A zoom in is visible in the fourth plot. They look like bursts of oscillations at about 5.5 kHz.

Images attached to this comment
kiwamu.izumi@LIGO.ORG - 13:44, Friday 27 March 2015 (17532)

We now believe that the glitches we had in the lock stretch from this morning was due to the ISS which repeatedly unlocked. This is a typical behavior of the ISS when the diffraction power is too low. Indeed the diffracted power had been 4% on average during the time when the interferometer was locked. There was clear correlation between arm cavities' power and the ISS diffracted power. See the attached trend of some relevant channels. Elli adjusted the diffracted power in this after noon so that the diffracted power is now at 8% with only the inner loop closed.

Images attached to this comment
thomas.massinger@LIGO.ORG - 18:24, Friday 27 March 2015 (17540)DetChar

Looking at glitch-to-glitch coupling between auxiliary channels and DARM shows a large number of glitches in the > 1kHz range that are coincident with glitches in CARM, REFL 9 PIT/YAW, and REFL 45 PIT. Interestingly, CARM is highly correlated with high frequency glitches until about 12:00:00 UTC, at which point REFL 45 PIT becomes the stronger veto.

It looks like REFL 45 Q PIT was offset by about 2500 counts during the lock, is it possible that intensity fluctuations on an uncentered WFS are showing up as alignment glitches? I've attached a time series covering 2 hours of the lock from 11 UTC to 13 UTC.

We're currently running code to see if the lower frequency (50-200 Hz) glitches are caused by zero-crossings in the 18-bit DACs.

I've attached an Omicron glitchgram for the whole day, it seems as if the higher frequency glitches and the glitches populating the 50-200 Hz region are the two dominant populations right now. There are also a few high SNR glitches scattered around in the 100-400 Hz region that we'll follow up individually.

Images attached to this comment
joshua.smith@LIGO.ORG - 07:47, Saturday 28 March 2015 (17555)DetChar

-2^16 Crossings in ETMY L3 ESD causing many of the glitches in this lock:

In addition to the arches reported in 17452 and 17506 we found DAC glitches in this lock when ETMY L3 ESD DAC outputs were crossing -2^16 counts. Attached is a PDF with a few examples that were lined up by hand. We will follow up more closely to see if other suspensions and penultimate stages also add glitches. Note: At Livingston, SUS MC2 M3 DACs were also a problem. 

If you'd like to see the primary culprits from this long lock, here is a tar file of omega scans (thanks to Joe Areeda) of the loudest 100 glitches between 30 and 200Hz. The vertical lines that repeat are DAC glitches, the crazy wandering features are the arches described in the pages linked above, those two mechanisms account for most of the glitches we see.   

Non-image files attached to this comment
H1 PEM (DetChar, ISC, PEM)
sheila.dwyer@LIGO.ORG - posted 21:54, Thursday 26 March 2015 - last comment - 18:49, Friday 27 March 2015(17499)
Coherence with PEM accelerometers

Here is a plot of coherences with some PEM accelerometers.  We have been thinking that the noise around 200-250 Hz was due to the PSL periscope PZT, based on coherences like the one in the lower left plot.  However, there is suscpicously similar coherence between the ISCT6 accelerometer and DARM.  Indeed, the coherence between these two accelerometers is high in this frequency range, suggesting that some cross talk could be the dominant signal in these accelerometers.

The right two panels show that the accelerometers which have coherence with DARM around 13 Hz and 16 Hz are also coherent with each other, but not nearly as much.  

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 18:49, Friday 27 March 2015 (17542)

There is some cabling work that needed to be completed on this particular channel (ISCT6_ACC). Hope to bring it online on Monday.

H1 ISC
filiberto.clara@LIGO.ORG - posted 09:53, Thursday 26 March 2015 - last comment - 16:04, Friday 27 March 2015(17484)
Shutter Controller EY
Replaced Shutter Controller S1203610 with S1203612. Daniel reported CH1 on S1203610 is not functioning, thus we were controlling the shutter with CH2. I reconnected the shutter to CH1 of the new unit and changed the jumper settings to VS35 on both channels.
Comments related to this report
daniel.sigg@LIGO.ORG - 16:04, Friday 27 March 2015 (17535)

Same story. Channel 1 opens and closes immediately. Next thing to check are cabling and slow controls.

H1 ISC
daniel.hoak@LIGO.ORG - posted 20:19, Wednesday 25 March 2015 - last comment - 19:30, Friday 27 March 2015(17473)
DARM boost on, OMC flickering reduced, OMC length upconversion, bounce mode damping, line at 300Hz

Dan, Evan, Kiwamu, Lisa, Sheila (and earlier advice from Keita)

Today we turned on the DARM boost filter described here, to increase the suppression in the 1-6Hz band.  The boost itself was no problem, but we realized that changing the phase of the open-loop gain around 10Hz changes the sign of the ETMY and ITMX bounce modes in the DARM error signal, which means the sign of the damping loops need to change as well.  This led to a few hours of bounce mode excitement, but the new signs and phases are now in the Guardian.

The first plot is a comparison of the OMC TRANS intensity noise before and after the boost filter was engaged.  The RMS before the boost was 2e-2 /rt[Hz], now it is 3e-3 /rt[Hz].  The OMC TRANS camera is much calmer.

The boost filter also reduced the coherence between the OMC length error signal and DARM.  Yesterday, Keita pointed out that the OMC length loop was far, far too coherent with DARM between 1-6 Hz, and this noise was being upconverted around the dither line at 3.3kHz.  The upconversion mechanism is not clear; if the OMC length is properly servoed the dither should not generate any RIN (or, very little) and should not upconvert any low-frequency RIN noise to sidebands around the dither frequency.  But, that's what's happening.  The new boost filter reduces the coherence at low frequency (second plot) and reduces the sidebands at 3.3kHz (third plot), but the coherence at low frequency and at 3.3kHz is not zero (second, fourth plots).

As a precaution against OMC LSC --> DARM coupling, we have reduced the gain of the OMC length loop even further: the OMC LSC boost is now off, and there is a 30Hz rolloff filter (FM3) in the OMC length loop.  The UGF is a little more than 10Hz, as described by the green trace from the first figure in this entry.

Keita also recommended changing the dither frequency and changing the dither amplitude and OMC LSC loop gain.  We haven't had a chance to do these things tonight.  We need to investigate why this noise is being upconverted - note that the amplitude of the 3.3kHz dither line in the OMC RIN increased after the OMC LSC boost was turned off (third plot).

The good ETMY and ITMX bounce mode damping settings with the DARM boost ON are (in M0_DARM_DAMP_V):

ETMY: +60deg, gain=500
ITMX: 0deg, gain=-100

The good settings with the boost OFF are:

ETMY: -60deg, gain=-2000
ITMX: 0deg, gain=200

This switching is handled by the Guardian.

 

By the way, an ongoing mystery is the source of a 300Hz line in DARM that is very large at the beginning of a lock but steadily decays to the level of the noise floor over a timescale of ~10-20min.  The rate of decay is somewhat matched to the BS butterfly mode and the earlier twin peaks noise, but the line is present when we're locked on RF readout, so it doesn't seem to be coming from the OMC.  We've checked the IOP inputs that are sampled at 65k and we don't see a line at 16384+/-300Hz that could be aliased, but we should check again at the very start of a lock when the 300Hz line is very prominent.

Images attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 22:12, Wednesday 25 March 2015 (17475)

why use the error signal for bounce mode damping, when the DARM control signal is available?

the phase of G/(1+G) changes very little as the loop gain changes in the case that G>>1 (which should be the case with the Bounce/Roll RG filters on)

kiwamu.izumi@LIGO.ORG - 19:30, Friday 27 March 2015 (17546)

Rana,

This is a good point. We are planning to change the pick off point so that it takes the DARM signal from its output as you suggested.

H1 CDS
sheila.dwyer@LIGO.ORG - posted 19:16, Tuesday 24 March 2015 - last comment - 21:05, Friday 27 March 2015(17445)
timing difference between beckhoff and RCG channels?

Dan, Sheila

The attached screenshot shows a one second trend of the beckhoff channel that is the fast shutter trigger readback, along with two RCG channels, the first is AS_C sum, this PD should be the source for the fast shutter trigger, and ASAIR_LF,  which should see similar power fluctuations.  

The beckhoff channel seems to be 0.2 seconds ahead of the RCG channels.  This timing difference sometimes makes it appear as though the fastshutter shut first, causing the lockloss, as in the second attached screenshot. 

We would like to prove definteively that the shutter is only shutting when it should, but we don't have a readback that we trust.  

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 21:05, Friday 27 March 2015 (17549)

Dave and I looked into this somewhat and we don't think that the timestamps of the EtherCAT systems are used at all by the frame builder. As a matter of fact the internal clock of these machines was about 3 seconds off. Since it is hard to believe that the EtherCAT systems violate causality, the most likely candidates are frame builder, data concentrator or maybe the EPICS gateway. This would also mean that all data transported through EPICS to the frame builder could be affected. More investigations are pending.

Displaying reports 65941-65960 of 83026.Go to page Start 3294 3295 3296 3297 3298 3299 3300 3301 3302 End