Displaying reports 55941-55960 of 83528.Go to page Start 2794 2795 2796 2797 2798 2799 2800 2801 2802 End
Reports until 16:49, Tuesday 12 July 2016
H1 TCS
nutsinee.kijbunchoo@LIGO.ORG - posted 16:49, Tuesday 12 July 2016 (28358)
HWSX SLED replaced

Y sled has been replaced recently and now that X sled is getting very dim, I decided to replace X sled as well. This way it's easier to keep track of when the sleds got replaced (this time both were replaced within one week). The old sled number is 12.05.21 replaced with 07.14.256.

H1 ISC
stefan.ballmer@LIGO.ORG - posted 16:33, Tuesday 12 July 2016 (28357)
ITM Red cameras set up

Kiwamu, Stefan

Yesterday Kiwamu realigned the red IR cameras. I reset the centroid setting today. The configuration files are:

ITMX:

[Camera Settings]
Camera Name = H1 ITMX (h1cam21)
maxX = 659
maxY = 494
Exposure = 100000
Analog Gain = 1023
Auto Exposure Minimum = 150
Name Overlay = True
Time Overlay = True
Calculation Overlay = True
Do Calculations = True
Calculation Mask = Circle
Circle Mask X = 373
Circle Mask Y = 150
Circle Mask Radius = 250
Calculation Subtraction File = None
Auto Exposure = False
Calculation Noise Floor = 25
Snapshot Directory Path = /ligo/data/camera
Frame Type = Mono12
Number of Snapshots = 1
Archive Image Minute Interval = 0
Archive Image Directory = /ligo/data/camera/archive/

[No Reload Camera Settings]
Base Channel Name = H1:VID-CAM21
Camera IP = 10.106.0.41
Multicast Group = 239.192.106.41
Multicast Port = 5004
Height = 480
Width = 640
X = 0
Y = 0
 

ITMY:

[Camera Settings]
Camera Name = H1 ITMY (h1cam23)
maxX = 659
maxY = 494
Exposure = 100000
Analog Gain = 1023
Auto Exposure Minimum = 150
Name Overlay = True
Time Overlay = True
Calculation Overlay = True
Do Calculations = True
Calculation Mask = Circle
Circle Mask X = 295
Circle Mask Y = 220
Circle Mask Radius = 250
Calculation Subtraction File = None
Auto Exposure = False
Calculation Noise Floor = 25
Snapshot Directory Path = /ligo/data/camera
Frame Type = Mono12
Number of Snapshots = 1
Archive Image Minute Interval = 0
Archive Image Directory = /ligo/data/camera/archive/

[No Reload Camera Settings]
Base Channel Name = H1:VID-CAM23
Camera IP = 10.106.0.43
Multicast Group = 239.192.106.43
Multicast Port = 5004
Height = 480
Width = 640
X = 0
Y = 0
 

H1 General
edmond.merilh@LIGO.ORG - posted 16:12, Tuesday 12 July 2016 (28356)
Shift Summary _ Evening Transition
TITLE: 07/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    Wind: 25mph Gusts, 14mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.09 μm/s 
QUICK SUMMARY:
H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:04, Tuesday 12 July 2016 (28355)
Ops Day Shift Summary
Title:  07/12/2016, Day Shift 15:00 – 23:00 (08:00 – 16:00) All times in UTC (PT)
State of H1: IFO unlocked. Maintenance day 
Commissioning: 
Outgoing Operator:  None
 
Activity Log: All Times in UTC (PT)

13:00 (06:00) Peter – Looking for missing equipment in laser enclosures. 
13:15 (06:15) Peter – Transitioned LVEA to Laser safe
14:00 (07:00) Peter – Finished looking for equipment
15:00 (08:00) Start of shift
15:15 (08:15) Soda vendor on site for deliveries
15:36 (08:36) Ryan – Going into LVEA to recover computer equipment
15:55 (08:55) Joe – Going into LVEA to check eye wash stations
15:58 (08:58) Robert – Going into LVEA to work on PEM stuff
16:03 (09:03) Ryan – Out of the LVEA
16:04 (09:04) Paul – Going to End-Y to work on PEM stuff
16:09 (09:09) Narco - Deliver of N2 to CP2 (LX)
16:46 (09:46) Joe – Out of LVEA – Still has two forklifts on battery charger
16:50 (09:50) Cintas – On site to change out matts
16:55 (09:55) Kyle – RGA work at End-Y (WP #5992)
17:42 (10:41) Filiberto – Going into LVEA to check PSL and HAM6 racks  
17:52 (10:52) Joe – Going into LVEA to check on battery charging
17:53 (10:53) Paul – Back from End-Y
18:06 (11:06) Joe – Back from LVEA – Battery chargers are off
18:24 (11:24) Paul – Going to End-Y to check PEM stuff
18:25 (11:25) Jeff K. – Running charge measurements on ETM-X
18:29 (11:29) Filiberto – Back from LVEA
18:31 (11:31) Filiberto – Going to Mid-Y
18:45 (11:45) Hugh – Going to End-Y to center STSs
19:06 (12:06) Filiberto – Leaving Mid-Y
19:08 (12:08) Hugh – Back from End-Y
19:10 (12:10) Kyle – Back from End-Y
19:11 (12:11) Jeff K. – Running charge measurements on ETM-Y
19:25 (12:25) Jeff K. – Finished with charge measurements at End-X
19:30 (12:30) Kiwamu – Transition LVEA to Laser Hazard
19:40 (12:40) Narco – Delivery of N2 to CP5 (Mid-X)
19:50 (12:50) Kiwamu & Nutsinee – Working on HWS Table (WP# 5990)
20:01 (13:01) Dick – Going into LVEA to check electronics racks
20:10 (13:10) Dick – Out of LVEA
20:55 (13:55) Twin Cities Metals on site to make delivery for Bubba
23:00 (16:00) Turn over to Ed
 
End of Shift Summary:

Title: 07/12/2016, Day Shift 15:00 – 23:00 (08:00 – 16:00) All times in UTC (PT)
Support: Sheila, Jenne, Jeff K., 
Incoming Operator: Ed

Shift Detail Summary: Maintenance day – All hands search of site for missing equipment. Equipment hunt has completed. 
Jeff K. ran charge measurements on ETM-X and ETM-Y.
Did initial alignment and locked the IFO to DC_READOUT
Commissioners requested high power – Lock broke just before reaching 40W. 
Relocking.


H1 SEI
hugh.radkins@LIGO.ORG - posted 16:00, Tuesday 12 July 2016 (28354)
EndY STS2 Masses Centered

As Patrick noted in 28181, the EndY had one STS2 leg out of range.  This Seismo's BIO does not work remotely so we'd been waiting til today to center it.  Attached is the 1 hour trend of the mass positions.  Note it did take two centerings to get the U and W masses much closer to zero so don't expect one to be enough.  They should settle down pretty quickly though so it still should not take too long to do a good centering.  I guess the V mass is happy where it is and doesn't plan to change its position. 

Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 14:40, Tuesday 12 July 2016 (28350)
Representative performance of ETMY BSC-ISI during ER9

There was a request for a representative example of BSC-ISI performance during ER9. My attached plot shows the ETMY L(ength) suspoint motion of the ST2 GS13s versus the ground motion. The red curve is the ISI's longitudinal motion (using the calibrated SUS_POINT channel), blue is the ETMY BRS/STS Y super sensor (showing the tilt subtracted low frequency ground motion) and green is the calibrated STS Y ground motion. Somethings to note:

1. Below .1hz the height of the green trace above the blue gives you an idea of how windy it was. In this frequency range the L motion is mostly ISI Y, so much of the height of the red trace above blue is due to tilt. The bump between 30 & 100mhz is from the gain peaking of the sensor correction filter. As Conor said on Friday, this should be mostly common mode between all of the tables.

2. Between .1 and 1 hz the blend filters are rolling off from the CPSs to the inertial instruments. It doesn't look like we are getting much at the microseism, but this is probably limited by performance of the sensor correction. We should do "better" here when the microseism comes up, during O2.

3. Above 1 hz the St2 L motion is limited by St2 RX/RY motion, because we can't turn on those loops on St2. GS13 noise is too high below 1 hz so it's hard to make a blend filter that improves  >1 hz motion that doesn't spoil lower frequency motion.

4. Above 10hz we are limited by GS13 noise and loop gain.

Images attached to this report
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 14:30, Tuesday 12 July 2016 (28353)
Coil drivers state re-written

Something that we've noticed a lot lately is that if the interferometer drops lock during the CoilDrivers state, guardian doesn't notice the lockloss for a long time. 

This was because all of the coil switching was happening in the "main" part of the state, which included many sleep commands.  Since we were switching 5 optics' coils, and each optic was about 90 seconds long, we had a solid 7+ minutes between lockloss checks.

Yesterday I re-wrote the Coil Drivers state so that the switching happens in the "run" part of the state, and I use a series of guardian timers rather than sleep commands.  So, the state still takes many minutes, but now it's constantly checking for lockloss as guardian is intended to do.

The switching has worked at least once so far with the new code, although since we didn't drop lock, the lockloss catching hasn't been tested yet.

Future work is to test whether we can do all 5 optics in parallel rather than in series, and then change the guardian to do so.

LHO VE
kyle.ryan@LIGO.ORG - posted 14:05, Tuesday 12 July 2016 (28352)
~1030 hrs. local -> Isolated RGA from Y-end
RGA had been valved-in but not running.  Need to finish commissioning this unit via baking "hot" at next available opportunity.
H1 SEI
hugh.radkins@LIGO.ORG - posted 13:59, Tuesday 12 July 2016 (28351)
EndY BRS Drift--We are okay til latish July

Here is a 60 day trend of the the EndY Drift Monitor channel.  This DC reading of the Beam Mirror Reflection obviously is still 'drifting' down but does continue to slow.  A quick and dirty extrapolation gives a need to recenter date of around July 25.

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 12:02, Tuesday 12 July 2016 (28346)
All Hands Equipment Hunt
   All teams have completed search of assigned areas. Two already known TDS3034s locations were confirmed and one was returned to the EE shop. No other items were found.  
Non-image files attached to this report
H1 General
peter.king@LIGO.ORG - posted 07:07, Tuesday 12 July 2016 (28344)
EX and EY transitioned to LASER SAFE
EX was transitioned to LASER SAFE.

EY was already LASER SAFE when I got there.  Temporarily transitioned it to LASER HAZARD to enable my
opening of the table enclosure.  Transitioned back to LASER SAFE.

No untoward items of test equipment were found in the table enclosures.
H1 General
peter.king@LIGO.ORG - posted 06:06, Tuesday 12 July 2016 (28343)
LVEA has transitioned to LASER SAFE
The LVEA has transitioned to LASER SAFE.

No untoward items of test equipment were found in the table enclosures.
H1 General
edmond.merilh@LIGO.ORG - posted 00:05, Tuesday 12 July 2016 (28341)
Shift Summary - Evening
TITLE: 07/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: None
SHIFT SUMMARY: 
Locking was the usual (as it has been) tweaking SRM because it won't follow the loops currently. Ross mde a valiant effort to show me how to damp PI. Unfortunately the screens he left open for me went into "lock" mode after he left. Jenne left about 05:00 which was right about the time that the PI started acting up. The rest is in the log.
LOG:

05:10 Parametric Instability ETMY_PI_OMC_DAMP_MODE1 started to ring up. Nothing I did seemed to improve it

6:43 ITMX joined the dance. i changed the phase to -60deg and this seems to have turned that one back around. And then, not.

6:54 It's abundantly evident that I(we)could use some training on how to deal with this PI monster. I'm feeling a bit distraught at not being able to mitigate it.

06:57 Watching he lock deteriorate. OMC DCPD saturations have begun....

06:58 LockLoss due to PI.

H1 ISC
jenne.driggers@LIGO.ORG - posted 21:31, Monday 11 July 2016 (28340)
SRM dither seen in POP90

[Jenne, AmandaC]

With Sheila and Haocun's work earlier today (alog 28324) putting in the beam splitter on the POPAIR table, we are now able to see a dither drive in POP90.  We shake SRM in pitch at 4Hz with 100 counts, and see a clear peak in POP90.  See snapshot.  We haven't yet put this into a new ASC loop, but we will.

Images attached to this report
H1 ISC (OpsInfo)
ross.kennedy@LIGO.ORG - posted 20:16, Monday 11 July 2016 - last comment - 21:19, Monday 11 July 2016(28333)
PI damping filters

During the lock today I had to change some of the damping filter settings as different modes rang up. Similarly to what Nutsinee was seeing on Saturday the 18040Hz and the 15009Hz ETMY modes were the ones causing the most trouble. From the strip tool you can see where I have changed the damping filter settings.

The current phase and gain states for these filters are:

Also when I was trying to damp the 18040Hz mode earlier there was a difference in thet rends of the OMC and QPD rms monitors. From the OMC rms it seemed theat the damping was effective but it's clear from the QPD rms that the mode was still ringing up and broke lock. 

Images attached to this report
Comments related to this report
ross.kennedy@LIGO.ORG - 21:19, Monday 11 July 2016 (28338)

The lock after this had several PI ringing up and again the damping filter settings needed changed.

The purple line here refers to the 14980Hz ITMY mode which needed to change phase 3 times in order to damp it. At the start of the lock it was set at -60 degrees. After the first increase it was changed to 0 degrees and it went down. After 5 minutes it started ringing up again and so I changed the phase to 60 degrees. This damped it for ~13 minutes and then rang up again so I changed the phase to 30 degrees which damped it again. The yellow line and the red line refer to the QPD and OMC rms for the 18040Hz ETMY mode respectively. After seeing the difference between the rms of the OMC and QPD signal earlier it becomes more apparent that at larger mode amplitude the QPD signal becomes more reliable. After this mode became unstable I changed the phase to -30 degrees which damped the mode. This mode is currently being damped using the QPD signal. The dark green is the 15009Hz mode which rings up a bit more slowly than the rest. I changed the phase from 0 degrees to 60 degrees which damped it. The light blue line is the 15520Hz ITMX mode. I had iwave tracking on this one but I had to change to just a bandpass filter after the rms started clipping. I changed the phase from -30 degrees to 30 degrees which damped the mode.

Images attached to this comment
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 18:55, Monday 11 July 2016 - last comment - 13:23, Tuesday 12 July 2016(28334)
Moving BS ISI ST1 and HEPI doesn't affect power recycling gain

[Jenne, Robert]

As a result of Keita's alog 28196 regarding the beam position on the BS, we wanted to move the beam splitter around in relation to the beamline, to see if that would change any clipping that we may have on the baffles.  Short answer: nope.

First, we moved ST1 by putting offsets in the isolation loops.  JeffK tells us that these are calibrated in nm, so our 5,000 count offsets correspond to about 0.5mm of motion.  We moved ST1 up and down, as well as laterally along the plane of the beam splitter (+x+y and -x-y).  No effect seen in the power recycling gain. 

Next, we moved HEPI in a similar fashion.  The thought here is that the ITM elliptical baffles are suspended from this ST0, so we weren't moving them earlier.  (By moving both ST1 and ST0 we had hoped to differentiate which set of baffles was causing us trouble.)  We moved up and down, as well as in RZ, rotation about the z-axis.  RZ is calibrated into nrad, and the baffles are order 1m away from the center of the ISI, so they were each moved on the order of 0.5mm also.  Again no effect seen in power recycling gain.

Attached is a snapshot of our striptool, with the first offsets starting at about 0:06:00 UTC, and the last ones ending around 1:00:00 UTC.  Teal is the power recycling gain.  The POP18 seems to be still relaxing from the power up to 40W for the first few minutes of our tests, but doesn't seem to be correlated with our movements.  Red trace is the vertical CPS measure of BS ST1 ISI position, and orange is superimposed with brick red measuring our lateral motion.  Light purple is vertical HEPI motion and light green is RZ HEPI motion.

We felt that if we were really dominated by clipping losses around the beam splitter, moving by 0.5mm in some direction should show us some change in recycling gain.  Since it doesn't, we conclude that the power loss must be somewhere else.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 12:49, Tuesday 12 July 2016 (28347)
For the record -- indeed the calibration of the offsets are 1 [nm / ct] or 1 [nrad / ct], but that would mean at 5,000 [ct] offset in translation (X, Y, or Z) is 5 [um] = 0.005 [mm] (not 500 [um] = 0.5 [mm] as stated above). Similarly the RZ offset of 5,000 [ct] = 5 [urad] = 0.005 [mrad].
jenne.driggers@LIGO.ORG - 13:23, Tuesday 12 July 2016 (28349)

Yeah, Mittleman just pointed that out to me.  Apparently math is hard in the evenings.  We'll give this another try with a bit more actual displacement.

H1 DetChar (DetChar, GRD)
joshua.smith@LIGO.ORG - posted 16:37, Monday 11 July 2016 - last comment - 12:55, Tuesday 12 July 2016(28329)
Glitches every 2 seconds in ER9 caused by not shuttered ALS X and state change

Andy, Duncan, Laura, Ryan, Josh, 

In alog 28299 Andy reported that we were seeing the ER9 range deteriorate due to glitches every 2 seconds. Figure 1 shows the glitches turning on in DARM at 2016-07-09 05:49:34 UTC. 

We think the ALS system not being shuttered and changing state in lock is to blame. Here's why. 

Excavator pointed us to a strong coupling between DARM and the ALS channels. Raw data confirmed a correlation, Figure 2 shows the ALS glitches tuning on at that same time and figure 3 shows that both DARM and ALS are glitching at the same times. 

When we investigated the Guardian ALS state for this time (figure 4), it was not in a nominal configuration to start with and that got worse around the time the glitches started. The shutter was not "Active" and at 05:49:34 UTC the ALS X state changed from "-15 locked transition" to "-19 locking WFS" and at that same time the glitches started in DARM. So at some point, ALS X decided it needed to lock the arm (looks like Y followed an hour or so later). We did not track down exactly how the glitches originated or made it into DARM because this seems non-standard enough that a configuration fix should make it go away. 

Figure 5 shows a summary page plot for nominal ALS X Guardian behavior from O1. So the shutter should be active and we don't expect to see "locking WFS" come on during an analysis ready state. 

Images attached to this report
Comments related to this report
andrew.lundgren@LIGO.ORG - 02:29, Tuesday 12 July 2016 (28342)DetChar, GRD, ISC
It seems like the ALS didn't think that the IFO was locked on IR anymore. The ALS-X state suddenly drops from 'Locked on IR' to 'PLL locked' (state 6 to state 2), then the requested state changes from 'Locked on IR' to 'Lock Arm' (state 6 to state 3). It seems like something went wrong in the communication and the ALS started to try to lock the arm. I don't think it would have helped if it were shuttered, because it would have unshuttered when trying to 'relock'. The attachment is just a plot of the two EPICS channels. As Josh said, the change corresponds to the time the glitching started.
Images attached to this comment
ryan.fisher@LIGO.ORG - 09:00, Tuesday 12 July 2016 (28345)
Two additional notes:

Here are the full Excavator results for the time period:  https://ldas-jobs.ligo-wa.caltech.edu/~rfisher/Excavator_Results/Jul11_Tests/1152079217/
(Note:  Excavator was run over unsafe channels as we were running a test of the code and then we started to follow up why something in ALS ODC popped up.)

We were pointed to the source of the problems by the ALS-X ODC channel indicating ADC overflows on a 2 second interval with precise timing.  The ADC overflows reported by the EPICs system at this time had timing fluctuations relative to the actual overflows of +/- .6 seconds in just the 5 minutes we looked at by hand. 

sheila.dwyer@LIGO.ORG - 12:55, Tuesday 12 July 2016 (28348)

We have been leaving the green light into the arms because sometimes it is usefull to see the power build ups and green WFS signals as we are trying to understand alignment problems. As people pointed out we would normally have these shuttered if things were really nominal, and in the shuttered state we don't check if the green arm is still ocked or not so it would not try to relock causing the glitches.  

Displaying reports 55941-55960 of 83528.Go to page Start 2794 2795 2796 2797 2798 2799 2800 2801 2802 End