Displaying reports 56101-56120 of 85824.Go to page Start 2802 2803 2804 2805 2806 2807 2808 2809 2810 End
Reports until 11:44, Saturday 15 October 2016
H1 ISC
evan.hall@LIGO.ORG - posted 11:44, Saturday 15 October 2016 - last comment - 10:56, Tuesday 18 October 2016(30558)
Sideband content of REFL LF does not make sense

Summary

Daniel points out that the behavior of REFL LF during the 9 MHz modulation depth reduction does not make sense:

One possible explanation is that the 9 MHz depth is a factor of 3 lower than we think it is. However, based on single-bounce OMC tests (described below), this seems to not be the case. So the discrepancy remains unexplained.

Details

For the OMC test, I first turned up the modulation depth by 3 dB (the slider value is normally 16.8 dB during lock acquisition, so I turned it to 19.8 dB).

Then I locked the OMC on the carrier, and then each of the 9 MHz sidebands, and recorded the following data:

Frequency

PSL power (W)

OMCR A sum (ct)

OMC trans sum(mA)

Carrier 9.8 600 <0.01
82 14.6
USB 9 47.2 2930 0.01
2860 1.07
LSB 9 47.7 2920 0.01
2880 1.07

I assign an uncertainty of 10% to the OMCR and OMC trans sum values. The OMC visibility is not perfect here, but we can nonetheless roughly infer the modulation index. If the carrier measurement had been done at 47 W, we would have seen 70.6 mA of sum photocurrent. Since Psb/Pc ≈ Γ2/4, this implies Γ = 0.25 rad during this measurement. This implies a value of Γ = 0.17 rad during normal lock acquisition. This is within 30% of the old value measured with the PSL OSA (0.22 rad). In other words, we are not missing a factor of 3 in the modulation depth, so the behavior of REFL LF during lock acquisition does not make sense.

Comments related to this report
evan.hall@LIGO.ORG - 14:00, Saturday 15 October 2016 (30560)

I am attaching more time series for what happens during 9 MHz modulation depth reduction.

The ~0.8% increase in the transmitted arm powers suggests a modulation depth during lock acquisition of about 0.13 rad. With this modulation depth, we'd expect a change of 2.0 mW on REFL LF during the reduction (instead we see 0.54 mW).

Images attached to this comment
evan.hall@LIGO.ORG - 21:18, Sunday 16 October 2016 (30577)

I made the following power measurements at 1.9 W:

RF9 RF45 REFL LF (mW) AS LF (mW)
16.8 23.2 0.315 69.7
13.8 23.2 0.271 68.5
13.8 20.2 0.236 49.1

I made the following measurements at 44 W, after reaching some kind of thermal equilibrium:

RF9 RF45 REFL LF (mW) AS LF (mW)
16.8 23.2 3.55 545
13.8 23.2 3.71 575
13.8 20.2 4.20 823

Note that (somewhat confusingly) REFL LF is calibrated into milliwatts on the diode itself, while AS LF appears to be calibrated into milliwatts exiting the AS port (i.e., before OM1).

We can use the REFL LF measurements to infer the carrier and sideband content both at 1.9 W and at 44 W. Here we assume the modulation depths have their nominal lock-acquisition values (16.8 dB for 9 MHz and 23.2 dB for 45 MHz, which based on old OSA measurements correspond to 0.22 rad and 0.28 rad of modulation depth). Additionally, we can scale the 1.9 W measurements to infer what we should see at 44 W, all other things being equal.

  9 MHz (mW) 45 MHz (mW) Carrier (mW) Total (mW)
1.9 W, from measurement 0.088 0.070 0.157 0.315
44 W, from measurement 0.64 0.84 2.55 4.02
44 W, scaled from 2 W 2.04 1.62 3.64

7.30

Note the large 9 MHz discrepancy from the power-up.

evan.hall@LIGO.ORG - 10:56, Tuesday 18 October 2016 (30620)

I copied the RF slider values for the 44 W measurement wrong out of my lab notebook, so here is the corrected table:

RF9 RF45 REFL LF AS LF
10.8 20.2 3.55 545
13.8 20.2 3.71 575
13.8 22.2 4.20 823

The algebra and resulting numerical values for the PD sideband content were done correctly, though.

H1 General (Lockloss)
thomas.shaffer@LIGO.ORG - posted 10:06, Saturday 15 October 2016 (30557)
Lockloss @ 17:03 UTC

ITMX roll was slowly ringing up since I got on shift, and the range has been driting down as well. I tried damping the roll mode but it only seemed to make things worse for not just ITMX. 

On the bright side, the wind is < 10mph and useism is on its way down.

H1 General
travis.sadecki@LIGO.ORG - posted 08:00, Saturday 15 October 2016 (30556)
Ops Owl Shift Summary

TITLE: 10/15 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  Struggled to get past DRMI locked for the first 5 hours of the shift due to various issues including wind, microseism, FSS issues that continue, Noise Eater resets, WFS running away, and ISC_LOCK going into error several times.  The good news is that microseism is slowly trending down and the winds have subsided some.
LOG:

13:13 Made it to NLN for the first time today, finally.  However, cannot go to Observing due to 3 excitations running (psliss, lsc, and ascimc) as reported by DIAG_EXC.  ODC-OBSERVATORY_MODE is set to Observing however.

Both of the locks during my shift have lost range since they started.  I'm not sure why this is the case.  There is also a lot of noise in the DARM spectrum below 30 Hz and between 200-600 Hz.
 

H1 PSL (OpsInfo, PSL)
sheila.dwyer@LIGO.ORG - posted 21:26, Friday 14 October 2016 (30553)
Request for DBB frequency noise measurement help

This afternoon Evan and I became suspicous that there is excess sensing noise in the IMC locking loop (alog with details coming in the next few days). After we realized that, I thought it would be a good idea to make some frequency noise measurements using the DBB in 4 configurations:

As Jeff B logged, we can't use the DBB tonight.  I've attached the screenshot of the DBB medm screen right now.  The problem could be the little counter in the operation mode box that (illegibly) says switching to standby mode in 177 minutes.  Every time we hit one of the buttons to request a mode, that counter gets reset to 240 minutes.  I'm not that patient.  I tried caputing 1 minute to that time, but that doesn't work.  Perhaps there is hope that the DBB could possibly be operable if people have the patience to wait four hours between button clicks.  Jeff B will try when the timer goes off to get some of the measurements.

Do any PSL experts have further insights into how to get this working?   

Jeff B is going to leave a print out of the DBB instructions at the operator station.  If any operator is able to make scans, in addition to saving the scans please log the times when you had the DBB PMC locked in different configurations. 

Thanks

H1 General
jeffrey.bartlett@LIGO.ORG - posted 20:29, Friday 14 October 2016 - last comment - 21:49, Friday 14 October 2016(30551)
Ops Evening Mid Shift Report
   Wind and microseism were dropping through out the first part of the shift. Took advantage of improving conditions to run an Initial Alignment and then try locking. Made it up to DRMI_LOCKED before Lockloss. The wind started to come back up (gusts back into the mid 30s), and 0.1-0.3Hz microseism is still elevated. Have not been able to get past locking green since. 

   The winds are forecast to drop later in the evening. Went back to Down for a bit to see if conditions improve.   
Comments related to this report
jeffrey.bartlett@LIGO.ORG - 21:49, Friday 14 October 2016 (30554)
   Tried relocking using the WINDY_USEISM state. Made it up as far as PREP_TR_CARM once. Mostly having trouble getting past LOCKING_ALS. Put the IFO back into down state for the time being.  
H1 PSL (PSL)
jeffrey.bartlett@LIGO.ORG - posted 20:20, Friday 14 October 2016 (30550)
DBB Will Not Switch Out of LOCAL
   Sheila wanted to run a couple of DBB scans of Frequency Noise. From the DBB MEDM found could not switch from LOCAL to LOCK (or any other state). Per Peter's instructions; (1). Checked the DBB toggle switch was in the RMT state. It was. Cycled the switch, but no change. Could not switch from LOCAL to any other state. (2). Then tried recycling the DBB AI chassis, but still no change. 

      
H1 CAL (DetChar)
jeffrey.kissel@LIGO.ORG - posted 17:27, Friday 14 October 2016 - last comment - 10:14, Tuesday 18 October 2016(30548)
PCALY OFS Glitching; Not Related to CAL Line Changes
J. Kissel, D. MacLeod

Duncan had noticed that Omicron triggers for the H1 PCAL Y RX PD (H1:CAL-PCALY_RX_PD_OUT_DQ) had failed on Oct 13 02:51 UTC (Oct 12 18:51 PDT) because it was receiving too many triggers. 

Worried that it might have been a result of the recent changes in calibration line amplitudes (LHO aLOG 30476) or the restoration of the 1083.7 kHz line (LHO aLOG 30499), I've trended the output of the optical follower servo, making sure that it has not saturated, and/or is not constantly glitching.

Attached is a 3 day and 30 day trend.

There is indeed a feature in the trend at Oct 13 02:51 UTC, but it is uncorrelated in time with the two changes mentioned above. Indeed, the longer trend shows that the OFS has been glitching semi-regularly for at least 30 days. I'll have Detchar investigate whether any of these correspond with heightened period of glitching in DARM, but as of yet, I'm not sure we can say that this glitching in a problem.
Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 09:38, Monday 17 October 2016 (30589)DetChar

The number of glitches seems to be definitely large and seeing them in OFS indicate it is real (and will be seen in DARM). Since Pcal interaction to DARM (at LHO) is oneway i.e, DARM is not expected to influence Pcal, it is probably originating in Pcal. At LLO we have seen glitches in Pcal when there were issues with power supplies (a-log LLO 21430), so it might be good to check those possibilities.

evan.goetz@LIGO.ORG - 10:14, Tuesday 18 October 2016 (30619)CAL, CDS, DetChar
Evan G., Darkhan T., Travis S.

We investigated these glitches in the y-end PCAL OFS PD more deeply and can fully explain all of the deviations. The excursions either due to DAQ restarts, line changes by users (including manual oscillator restarts, or by request to make transfer function measurements), shuttering the PCAL laser, or maintenance activities. See the attached 35 day trend of the excitation channel, shutter status, and OFS PD output (trends for both the 16 kHz and 16 Hz channels).

What sets the limits on Omicron triggers? Should Omicron be set to allow a higher number of triggers for Pcal?
Images attached to this comment
H1 SEI (OpsInfo)
jim.warner@LIGO.ORG - posted 16:56, Friday 14 October 2016 (30547)
Seismic configuration for high winds and microseism

Since LHO is getting walloped by the remanants of a Pacific storm, the winds are high and the microseism is high, preventing locking. A while ago RichM had suggested that we try lowering the St1 RX blends when the wind was high, and it seems like this might be a good idea, under the right conditions. I started by switching ETMY, first attachment is ETMY ground vs ETMY RX during high winds, refs are 250 mhz (nominal, high)  blends, live measurement is with the 90 mhz, lower blends . There is a large improvement from .1 to 1 hz. We don't normally run this way because ground tilt is usually below T240 noise, but not today. To check that this wasn't making things worse at ETMY, I also checked the Y motion and it was similarly improved, second attachment, again, refs are 250mhz (nominal, high)  blends, live measurement is with the 90 mhz, lower blends. Again, there is some improvement in the .1-1hz band, low frequency doesn't seem to be any worse. If we look at the CPS as a low frequency witness (below the blend frequency) going to a lower blend doesn't seem to do anything bad, under these very bad, no good conditions, third attachment. Yet again, refs are 250mhz (nominal, high)  blends, live measurement is with the 90 mhz, lower blends. The brown trace shows the Y cps is moving somewhat less than the blue Y cps, so there is at least enough real low frequency signal that we are not injecting T240 RX noise into the Y loop.

Sheila and Evan were doing modecleaner measurements, so I didn't try to get any arm cavity signals. It would be nice if commissioners would give this configuration a shot while the environment is terrible.

I have left the ITMY and ETMY RX loops in these lower blends because it sounds like commissioners are probably packing it in. While winds and microseism are this high (20-50mph(?) wind, 95th percentile(?) microseism) I think we should try this configuration. When winds settle down the ITMY and ETMY ST1 RX blends should be switched back to the Quite_250 blends. 

Images attached to this report
H1 General (OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 16:06, Friday 14 October 2016 (30545)
Ops Day Shift Summary

State of H1:  breifly locked PRMI but unstable, Commissioners doing other work, currently Sheila has IMC at 50W

Details:

H1 AOS (FMP)
betsy.weaver@LIGO.ORG - posted 13:36, Friday 14 October 2016 (30540)
Signs of wind at LHO

You know it's windy when...

Images attached to this report
H1 General (OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 11:23, Friday 14 October 2016 - last comment - 16:40, Friday 14 October 2016(30535)
Ops Morning Update: as of 18:18UTC, Winds have picked up, locking is questionalble

State of H1: in Initial Alignment, struggling to lock arms in green, have only had breif locks of X arm in IR

Details:

Site Activities:

Comments related to this report
krishna.venkateswara@LIGO.ORG - 12:04, Friday 14 October 2016 (30537)

Both BRS seem to be working fine to me, I don't see anything wrong with BRS-Y.

cheryl.vorvick@LIGO.ORG - 13:02, Friday 14 October 2016 (30538)

AS of 19:58UTC (12:58PT):

  • winds have come down from 15-45mph to a steady 0- 35mph, with gusts to 40mph
  • EY BRS is not in use, but damping, however the velocity is +/-1500 counts(?)
  • BRS set to WINDY_NOBRSY
  • cannot get through FIND_IR
cheryl.vorvick@LIGO.ORG - 13:03, Friday 14 October 2016 (30539)

BRSY is rung up - see attached

Images attached to this comment
krishna.venkateswara@LIGO.ORG - 13:35, Friday 14 October 2016 (30541)

Sorry, the terminology related to BRS is a little confusing, even to me. The large velocity signal is actually caused by the large ground motion and is not a fault of the sensor. The damping will turn ON occasionally but the sensor output should still be useable. I would suggest using the BRS under these conditions.

If you want to prevent the damping from turning ON in these very high winds, the ON/OFF VELOCITY  can be set higher temporarily. I think the commands are -   

CAPUT H1:ISI-GND_BRS_ETMY_HIGHTHRESHOLD 5000

CAPUT H1:ISI-GND_BRS_ETMY_LOWTHRESHOLD 2000

hugh.radkins@LIGO.ORG - 16:40, Friday 14 October 2016 (30546)

Or you can disable the damping with:

caput H1:ISI-GND_BRS_ETMY_USER Off
Old : H1:ISI-GND_BRS_ETMY_USER       On
New : H1:ISI-GND_BRS_ETMY_USER       Off
 

H1 TCS (AOS)
jason.oberling@LIGO.ORG - posted 10:30, Friday 14 October 2016 - last comment - 22:59, Friday 14 October 2016(30531)
TCSy Chiller Topped Off

J. Oberling, B. Weaver

I checked on the TCS chiller this morning and added 350mL of water to bring the level from 5.0 to 8.9.  I then noticed that the mesh filter seemed to by pushing up out of the reservoir by a good bit.  I reseated the filter and noticed the level had dropped to 6.3.  There was still 50mL of water in the cup, so I added that to the chiller and observed the mesh filter.  Sure enough, the filter puffed up.  There is a large air gap between the top of the water in the reservoir and the spot that the filter seats into.  What I think is happening is when we fill the chiller, that air between the water and the filter has no where to escape quickly (probably due to the amount of water moving through the filter).  This creates an air bubble between the water and the filter that then influences the fill reading on the front of the chiller (hence why the reading went down when I simply reseated the filter).  I have a suspicion that the chiller has not been losing water, we just haven't added enough since the system flush to completely fill it, and when we do top it off we're creating an air bubble that influences the fill level reading.  We then think we've topped the chiller off when in actuality we haven't; as that air bubble slowly works its way out the level reading "drops," thereby making us think we're losing water.

I ran this by Betsy and found she was starting to suspect something similar.  We went out and removed the mesh filter and then topped the chiller off, then replaced the filter.  It took 600mL of water to move the indicator from 6.3 to 8.3, which is much less than we've seen in the past; if you look at the log on top of the chiller it can be seen that there are instances where we fill w/ 250mL of water and move the indicator from 5.0 to ~9.0, which is much less than the 600mL is took to go from 6.3 to 8.3.  This suggests that what I wrote above is correct, we haven't been fully topping off the chiller but have been fooled into thinking we have by an air bubble of our own creation influencing the reading of the chiller fill level.  One of us will check the chiller at the end of the day to check the chiller water level and see if we still need to add water (water has been added every morning and evening for every day this week).

Total water added this morning was 1000mL, and this moved the indicator from 5.0 to 8.3.

Comments related to this report
jason.oberling@LIGO.ORG - 15:02, Friday 14 October 2016 (30543)

At 2:30pm PDT the water level in the TCSy CO2 chiller was reading between 7.9 and 8.0.  This is a much slower decline in water level then we have been seeing this week.

jeffrey.bartlett@LIGO.ORG - 22:59, Friday 14 October 2016 (30555)
   Checked water tonight. Level is still up; did not add any.
H1 General (AOS, SEI, SUS)
travis.sadecki@LIGO.ORG - posted 00:36, Friday 14 October 2016 - last comment - 13:40, Friday 14 October 2016(30520)
Optical Lever 7 Day Trends

See attached screenshots of OpLev trends. 

Images attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 13:40, Friday 14 October 2016 (30542)

Nothing looks out of the ordinary with these trends.  A re-centering should be done before the start of ER10.

Displaying reports 56101-56120 of 85824.Go to page Start 2802 2803 2804 2805 2806 2807 2808 2809 2810 End