Displaying reports 67641-67660 of 84498.Go to page Start 3379 3380 3381 3382 3383 3384 3385 3386 3387 End
Reports until 18:03, Tuesday 17 March 2015
H1 CDS (SEI)
david.barker@LIGO.ORG - posted 18:03, Tuesday 17 March 2015 (17319)
Crash of h1seib2

Richard, Jim, Dave:

at 12:05 the h1seib2 (BS) front end system went offline. We saw no green leds on the IO Chassis One Stop card, and saw red leds on the card itself. We power cycled h1seib2 and its IO Chassis (we prevented the models from running). The computer could not see any cards in the chassis.

We powered down both h1seib2 (BS) and h1seib3 (ITMX) systems, and switched the One Stop fibers at the IO Chassis (h1seib2 connected to h1seib3's chassis and vice versa). Confusingly now both FE computers can see all the cards in both chassis. We then powered everything back down and connected the fibers back correctly. At this point the problem has gone away,  h1seib2 sees its cards again. We started the user models, the only problem was with h1iopseib3 which had a run-away IRIG-B time with went up to 1500 and took an hour to come back down.

Richard says that the One Stop card in the h1seib2 IO Chassis showed a red led when the computer was not powered up, but the h1seib3 chassis did not do this. So we are still suspicious of the h1seib2's IO Chassis One Stop card, and if this problem re-appears we will consider replacing it.

An interesting aside, I looked at the IO Chassis One Stop cards in the CER and found that while most have 4 green leds on, some have 1 and one has 2.

H1 AOS (CDS, DAQ)
david.barker@LIGO.ORG - posted 17:53, Tuesday 17 March 2015 - last comment - 18:15, Tuesday 17 March 2015(17317)
CDS Maintenance Summary

NTP and Atomic Clock WP#5105

Dave,Jim, Vern:

The NTP server was moved in the timing rack to a lower slot. The lid to the Beckhoff chassis was reattached. The new Symmetricom Caesium Atomic Clock was racked in the location vacated by the NTP. The atomic clock was connected to UPS power and achieved sync up after 30 minutes of running.

Installation of MSR Timing Comparator

Dave, Jim:

We installed the MSR timing comparator chassis in the timing rack. We connected its timing slave fiber optics cable to the timing master (port 3) and then powered it up to +12V DC. It connected to the master with no problems

PEM CS model change WP5042

Dave, Robert:

I added the missing two narrow band radio channels to the h1pemcs model. To keep all the radio channels together on the 3rd ADC, I moved the temperature, lowfreq mic and mainsmon channels down by 2 channels in the model, and did the same with the BNC cables at the AA chassis. I checked that the low freq mic and mainsmon signals look the same in minute trends before and after the change.

OAF IPC receivers

Dave:

I removed the two IPC receivers in the h1oaf model which used to come from the LSC model but were removed. These are H1:LSC-CAL_IMC_[CTRL,F]. I grounded these channels in the h1oaf model.

DAQ restarts

Dave, Dan, Daniel, Sheila:

Several DAQ restarts were needed today: New PEM-CS model, new OAF model, new LSC model, new ASC, SUSHTTS models, new Beckhoff C1-PLC2 code, new guardian nodes.

Comments related to this report
daniel.hoak@LIGO.ORG - 18:15, Tuesday 17 March 2015 (17321)

For the ASC and HTTS models: we added IPC sender/receiver pairs to provide an ASC drive to OM3.

Also, we added the following ASC channels to the DAQ (but not to the science frames):

AS_C_PIT_OUT 2048
AS_C_SUM_OUT 2048
AS_C_YAW_OUT 2048
 
OMC_A_PIT_OUT 2048
OMC_A_SUM_OUT 2048
OMC_A_YAW_OUT 2048
 
OMC_B_PIT_OUT 2048
OMC_B_SUM_OUT 2048
OMC_B_YAW_OUT 2048
 
OMCR_A_PIT_OUT 2048
OMCR_A_SUM_OUT 2048
OMCR_A_YAW_OUT 2048
 
OMCR_B_PIT_OUT 2048
OMCR_B_SUM_OUT 2048
OMCR_B_YAW_OUT 2048
H1 ISC
daniel.sigg@LIGO.ORG - posted 17:44, Tuesday 17 March 2015 (17315)
IMC_F Offset

As outlined in alog 17077 we should shift the IMC frequency to the reference cavity AOM up by ~450 KHz after we are locked, the common tidal feedback path is engaged and after the green light is no longer needed. To this end an offset has been added after the IMC_F filter module. This way we can use kHz rather than counts. It also employs a ramping feature, so the offset can be turned on smoothly.

New channels are H1:IMC-F_OUT_OFFSET for the frequency offset in kHz, H1:IMC-F_OUT_OFFSET_SW for engaging the offset, H1:IMC-F_OUT_TRAMP for the ramp time in sec, H1:IMC-F_OUT_RAMPING for the status of the ramping process, and H1:IMC-F_OUT_MONITOR as the new error signal for the common tidal servo. H1:IMC-F_OFFSET_OUT is available as a new fast testpoint which includes the offset.

Images attached to this report
H1 TCS
daniel.sigg@LIGO.ORG - posted 17:09, Tuesday 17 March 2015 (17314)
TCS RF Distribution

(Fil, Mani, Daniel)

Adding the 10 MHz frequency reference to the RF synthesizer in the mechanical room turned out to be more involved than we planned. First, we noticed that some of the RF distribution cables were badly terminated and needed to be redone. We then found that no baluns were added—generating one big ground loop through the RF cabling.

This is the current setup:

We noticed that thin coax cables were used to route the RF signals from R1 to R2. We should replace those with the proper thick coax which is used everywhere else in the distribution system.

We still need to route a DB25 cable from the RF distribution amplifier to the RF amp concentrator in the CER. This way we have both frequency and RF power readbacks available. The EtherCAT system was udated with the new monitor channels for the TCS RF distribution amp. This will make it straight forward to diagnose a problem with this RF synthesizer.

A new medm screen was made for the TCS RF distribution (see attached).

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 16:53, Tuesday 17 March 2015 (17313)
Replaced HAM1 and HAM2 annulus ion pumps
Kyle, Gerardo

Legacy pumps long past their nominal life expectancy -> Damaged knife edge of 2 1/2" O-ring isolation valve at HAM2 ion pump attempting to align flanges which were kept sprung misaligned by rigid non-perpendicular piping -> Had to remove damaged valve and replaced it with an elbow (will repair valve in house and keep as spare) -> Leak tested new joints -> Will now need to pump with pump carts for a few more days before energizing new ion pumps.  

Note: HAM1/HAM2 annulus volume was fully vented for a period of time -> no pressure change in Corner Station
H1 CDS
patrick.thomas@LIGO.ORG - posted 16:42, Tuesday 17 March 2015 (17312)
Updated Conlog channel list
Added 326 channels. Removed 57 channels.

The following 10 channels are unmonitored:

H1:GRD-TCS_ITMY_LOGLEVEL
H1:GRD-TCS_ITMY_MODE
H1:GRD-TCS_ITMY_NOMINAL_S
H1:GRD-TCS_ITMY_REQUEST
H1:GRD-TCS_ITMY_REQUEST_S
H1:GRD-TCS_ITMY_STATE_S
H1:GRD-TCS_ITMY_STATUS
H1:GRD-TCS_ITMY_TARGET_S
H1:SUS-SR2_LKIN_P_OSC_SW2R
H1:SUS-SR2_LKIN_Y_OSC_SW2R
LHO VE
bubba.gateley@LIGO.ORG - posted 16:27, Tuesday 17 March 2015 (17311)
Beam Tube Washing
Scott L. Ed P. Chris S.

52 meters of tube cleaned today from single door towards X-1-6 double doors. 
Continuous motioning of beam tube pressures during cleaning operations.  
H1 General
edmond.merilh@LIGO.ORG - posted 16:02, Tuesday 17 March 2015 (17308)
Daily Ops Summary - afternoon

I'm sitting in for Jeff who left early to go on vacation.

15:55 Kiwamu going to close the LASER shutter to HAM1 to do some testing on the rotation stage.

H1 AOS (TCS)
matthew.heintze@LIGO.ORG - posted 15:41, Tuesday 17 March 2015 - last comment - 14:53, Tuesday 24 March 2015(17303)
TCS (CO2 laser) issues today

 

So what was supposed to be a simple favour for Aidan to turn the CO2y laser on turned out to be not so simple. Note: when I started this work I was unaware of the issues that Greg encountered last week (he has just put in an alog now for me alog 17302).

So at the moment the CO2y laser is still off.

Below is what observed/thought was the problem before hearing from Greg about the issues he saw previously (and is now alogging) , and also talking to Aidan about his recollections. Also will include what I think is going on for part of it and also recommendations.

 

Observation 1:

The rotation stage for CO2y is not working (I cant get it to do any rotation of any kind). I played with this before knowing that Greg had seen this last week also. I did not try playing with the CO2x. Based on past experience at LLO and LHO its going to be something with Beckhoff having to be reset (we really need to work out why these things just stop working). So until it is up and running I dont want to turn the laser on. And because I dont know how LHO like to proceed with doing procedures like this I took this no further. So what I need is for someone (maybe at start of next weeks maintenance period) to reset the HWP for me (probably just needs to be unplugged then replugged).   

 

Observation 2:

I went out to the mechanical room to check the status of the power supplies etc. I immediately saw two things that peaked my interest.
1. Only one of the Kepco power supplies is on and wired up?? and the one that was on was drawing no current (see pic Kepco power supply).  This I have seen before and indicates that one of the AOM drivers has faulted. But because things look to be hooked up weird (will discuss more later) looking on the tables I see that CO2y AOM driver is fine (indicated by the two green LEDs..see pic CO2yAOM driver), but the CO2x AOM driver has faulted (top LED red...see pic CO2xAOM driver). If you want to know what these fault lights mean please go to E1500133 and look at table 1 (someone should probably print this table out and stick it on or near the AOM driver for others for future reference). Now this has been seen before at LLO and the solution is to power cycle the power supply. However doing this will make the AOM start to work, and seeing as its not known when it faulted and what static diffraction setting the driver has been set to, once the reset occurs I could alter how much power is going to the interferometer (as CO2x laser looks like its being used). So again this is something should do during maintenance period (should note what power going to optic now and so when reset see how/if it changes and alter power accordingly). 

2. The CO2Y laser power supply seems to be drawing a funky amount of current. 2.5Amps actually (see pic TCSy power supply), even though the laser is off. Ive even turned the key on the controller off, so it shouldn't even be in standby mode where only draws 0.7Amps. Talking to Aidan he seems to think that maybe the AOM driver/AOM is drawing current from this supply (him telling me that made me recall we saw numbers like this back in the day when we were installing and the laser was off but we had the AOM driver on). He seemed to recall the AOM driver and CO2 laser are driven off the same supply still here at LHO (which was the original design), even though the plan was to change to having the CO2 laser and AOM driver driven off separate supplies (as has been implemented at LLO...the Kepco power supplies power the AOM drivers the other supplies power the CO2 laser only). But this doesnt seem to totally match with what Im seeing in the mechanical room. 

So looking at the wiring, here is what I think is the current setup at LHO. We are in some funky mid change between having one power supply do both laser and AOM driver and having separate supplies for all. In more detail......The two shelves showing the power supplies for TCS are shown in TCSracklowershelf and TCSrackuppershelf. How it should be as per the latest plan that I know of (and is at LLO) is that the on the lower shelf should hold the power supplies that power one table (ie say Y ) and for the upper shelf the power supplies for the other table (X) with seperate supplies for the lasers and the AOM drivers.  What seems to be the case is that:

       *on the lower shelf we have the Instek supply (I think thats the brand name....its the the one with the digital readout reading its drawing 2.5Amps that says TCSY on top of it) powering BOTH the CO2y laser and the CO2y AOM driver (I think this because the laser is OFF, as is the controller, but the AOM driver on the Y table has not faulted and is "running".The x table AOM driver has faulted and is not "running" and 2.5amps is an approximate number that the AOM driver could be drawing). 

       * The Kepco power supply on the lower shelf is wired up but not drawing any current at the moemnt and thus and looks to be powering the AOM driver for the X table (why... because the x table AOM driver has faulted its not drawing any current). It should be wired to be controlling the Y table if supply in the position at..or at the very least labeled clearly as to what it is powering. Mind you I could be wrong and its powering something else

      * The instek supply (the one showing the digital readout of 22.42 Amps) on the upper shelf is powering ONLY the CO2 x laser (its drawing this current as the laser is on). 

      *The Kepco power supply on this upper shelf is not even wired up and is thus off. 

 

What I suggest is at some stage when have some time (maybe during maintenance period next week), is to wire the system as per the new design (and as how is at LLO). One Kepco power supply is used for the AOM driver on one table and the other Kepco power supply be wired to the AOM driver on the other table. And then just have the other power supplies individually controlling the CO2 lasers. Should then also have the power supplies for one table on one shelf and the power supplies for the other table on the other shelf. 

 

Also when turn laser back on need to see if still only drawing half the current like Greg saw and if so investigate (probably cable connection is the problem like in the past). SO quite a few things would lile to do at next weeks maintenance period. 

 


			
			
Images attached to this report
Comments related to this report
greg.grabeel@LIGO.ORG - 14:53, Tuesday 24 March 2015 (17434)TCS
Adding a small correction to this. The AOM drivers are both plugged into their respective Instek power supplies, rather than both being powered by the Kepco supply. A Pheonix Contacts is being powered from the Kepco supply.
Images attached to this comment
H1 IOO (ISC)
kiwamu.izumi@LIGO.ORG - posted 15:34, Tuesday 17 March 2015 (17310)
IOT2L check out; no obvious clipping

10 days ago, Gabriele and Evan reported that there seemed to be a large offset in the IMC locking loop (alog 17131). In order to investigate this issue, I started from checking the health of the IOT2L optical table -- specifically we wanted to confirm that there is no stupid clipping or something crazy.

I did not find a clipping or anything crazy on the table.

 


(Health check of IOT2L)

I went to the IOT2L and checked the REFL path using a IR viewer and card, but I did not find an obvious clipping or any suspicious things. I found an iris which was letting the main beam go through but also scattering ghosts beams. The iris was in front of the BS which steers the beam to the REFL RFPD. I took out the iris and re-adjusted the razer blade beam dumps which have been meant to damp those ghosts. Also, I checked the centering of the beam on the REFL RFPD by steering the BS, but it was already centered.

 

(What happened to MC trans digital camera ?)

BTW, the IMC trans camera had been displaying nothing these days according to the hourly archives probably since some time in February. I realigned the camera as it seemed to be misaligned in YAW.  After adjusting the exposure, I realized that the beam shape completely changed from the image that I remembered -- see the attached pictures. The first attachment is the one from Feb-04-2015 and the second from today after my realignment. During the realignment process, I moved the camera position to see if this image is something bogus or real. I am concluding that this image is real. Something must have happened in the IMC trans path between early February and now. Sad.

Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 14:57, Tuesday 17 March 2015 - last comment - 11:03, Wednesday 18 March 2015(17309)
BRS restarted this afternoon

Hugh and Krishna had found the BRS software had crashed pretty much on schedule, so Sheila and I went to the end-station to restart it. Pretty straightforward. Alogs 13817 and 15005 will get you everything you need to do it. The BRS is rung up right now because we went out to check the mass damper positions, but it should settle down in 30 minutes or so.

Comments related to this report
krishna.venkateswara@LIGO.ORG - 17:43, Tuesday 17 March 2015 (17316)

K. Venkateswara

I took a look at the BRS_RY_IN channel and it looks like BRS started to get damped but then the damping failed (see attached pic). It is currently oscillating with 500 count ampitude. I'm not sure why this happened but it currently looks like the mean position of the damping turn-table has changed by 45 degrees causing it to neither damp nor drive BRS. A repositioning of the turn table might help. If not, I'd suggest turning off the damper temporarily.

Looks like Jim and Sheila did everything right, but the damper is a bit finicky.

Images attached to this comment
krishna.venkateswara@LIGO.ORG - 11:03, Wednesday 18 March 2015 (17338)

Looks like it did damp down eventually. I have no idea what happened, but it is possible that the damper turn-table got stuck, moved to a new mean location and then somehow got stuck again and returned to a reasonable location. In any case, looks like BRS is damped now and working well.

Images attached to this comment
H1 General
jeffrey.bartlett@LIGO.ORG - posted 14:45, Tuesday 17 March 2015 (17307)
Ops Day Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning   

07:00 Karen & Cris – Cleaning in the LVEA
08:22 Hugh – LVEA for HEPI maintenance work
08:36 Jodi – In the LVEA for 3IFO stuff
08:37 Christina – Forkliftng boxes from LSB to VPW
08:45 Jim B. – Starting work on the NTP server move
08:45 Matt – Turning on CO2-Y laser
08:50 Richard – Vacuum survey in the LVEA
08:51 HFD on site testing fire alarms
08:55 Kyle & Gerardo – Swapping out Ion pumps on HAM1 & HAM2
09:00 Peter, Jason & Ed – In the PSL for RefCav and FSS work
09:01 Corey – Working in the squeezer bay
09:34 Richard – Going to End-Y with HFD to test fire alarms
09:51 Hugh – Finished with HEPI in LVEA – Working on pump controller.
09:52 Jodi – Out of the LVEA
10:00 Praxair delivering N2 to Mid-X
10:03 Paradise Water on site
10:30 Filiberto – Working on TCS-X RF cabling
10:48 Richard – Back from End-Y
10:55 Kiwamu – Checking IOT2L for beam clipping
11:00 Doug – Looking for OpLev parts near HAM2
11:00 Peter, Jason, & Ed – Finished in the PSL 
11:05 Reset HEPI watchdog counters
11:38 Dave – Restarting new PEM corner station model & making cable changes in CER
11:42 Kyle & Gerardo – Out of the LVEA
11:50 Dave – DAQ restart
11:50 Kiwamu – Out of the LVEA
12:35 Karen – Going to End-Y
12:35 Cris – Going to End-X
12:43 HFD on site testing smoke alarms at End-X
13:10 Kyle & Gerardo – Leak checking at HAM1 & HAM2
13:51 Karen – Leaving End-Y
13:52 Filiberto – Connecting TSC RF cables
13:55 Kiwamu – Checking mirror pointing in IOT2L
14:22 Filiberto – Out of the LVEA
14:30 Kiwamu – Out of the LVEA
14:41 Jason – In LVEA getting parts from the OpLev cabinet
14:56 Jason - Out of the LVEA

LHO FMCS
john.worden@LIGO.ORG - posted 14:28, Tuesday 17 March 2015 (17306)
LVEA Heat

We have turned off 3 LVEA heaters today as the winter season departs. It appears that temperatures in the LVEA are now back to nominal after an excursion of ~0.5F.

12 hours shown on the plot.

We'll continue to monitor the response.

Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 13:29, Tuesday 17 March 2015 (17305)
Fixed version of BSC and HAM control performance spectra

I collected my performance data with the BSC in the right blend configuration this morning (sans modified blend filter, from my alog earlier today) and updated the HAM spectra from Friday, with slightly better color choices, I hope. See attached pdfs.

Non-image files attached to this report
H1 TCS (TCS)
greg.grabeel@LIGO.ORG - posted 11:59, Tuesday 17 March 2015 - last comment - 13:01, Tuesday 17 March 2015(17302)
CO2y Issues
This is an issue from last week. While doing chiller maintenance last week I noticed that the power supply for the TCSx laser was running at only half power. I checked the cables and didn't find any obviously loose connections, but this has been an issue in the past. Less likely, but still possible is the RF driver failing. While on the table I noticed the rotation stage has once again gone glitchy and won't respond to requests or return to home. Most likely requires a Beckhoff reset. 

There is and has been a beam block in the laser path. For now the TCSy laser is disabled by the MEDM gate.
Images attached to this report
Comments related to this report
matthew.heintze@LIGO.ORG - 13:01, Tuesday 17 March 2015 (17304)

Actually the TCSy is disabled by turning the key off also at the control box (I didnt know about these issues at the time when I started trying to turn the CO2y laser on today (alog to come)). 

 

Also like Greg mentions I would suspect the cable connection if is onlydrawing half current as this has been a known issue on this table before see alog 16495

H1 PSL (PSL)
jason.oberling@LIGO.ORG - posted 11:47, Tuesday 17 March 2015 - last comment - 11:48, Tuesday 17 March 2015(17300)
PSL FSS Maintenance Summary

P. King, J. Oberling, E. Merilh

Summary

FSS RefCav TPD started drifting again, went in to re-align.  Check mirrors M23, M22, and M21, all found loose.  M23 and M21 pitch adjustments recovered RefCav TPD, M22 had no effect; all pitch adjustment screws locked.  FSS RefCav TPD left at 1.56V.  Adjusted M36 to optimize power incident on PMC_TRANS PD, now reading 23.03 W (up from 22.99 W).  Measured FSS TF, UGF measured at 195 kHz.

Details

The FSS RefCav TPD had begun to drift down again, so we went in and checked the remaining 3 mirrors in the FSS beam path: M21, M22, and M23.  We first checked M23 and found the pitch adjustment screw to be loose.  Turning this screw CW (pitching the mirror down) caused the RefCav TPD to change from 1.23V to 1.53V; the adjustment screw was locked.  M22 was also found unlocked, but did not effect the RefCav Trans; this adjustment screw was also locked.  The final mirror in the FSS path that we had not inspected before was M21, and lo-and-behold, the pitch adjustment screw was unlocked.  Turning this screw CW (pitching the mirror down) took the RefCav TPD from 1.53V to 1.56V; this adjustment screw was then locked.  We will continue to monitor the FSS RefCav TPD.

Since the transmission through M23 is responsible for the PMC_TRANS reading, we slightly tweaked M36 to optimize the reading of the PMC_TRANS PD.  Before the adjustment the PMC_TRANS was reading 22.99W, it is now reading 23.03W.

Finally, we took a TF of the full FSS loop, and measured the UGF to be ~195 kHz.  Peter has the full TF data and will add it as a comment to this post.

Comments related to this report
peter.king@LIGO.ORG - 11:48, Tuesday 17 March 2015 (17301)
Attached plot.
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
H1 ISC (DetChar, PEM, SEI)
nutsinee.kijbunchoo@LIGO.ORG - posted 12:34, Monday 16 March 2015 - last comment - 16:02, Tuesday 17 March 2015(17278)
WIND ALS ISI Correlations

Sheila, Nutsinee

Attached below are the plots of PEM/ALS and PEM/ISI correlations. Using data from March 14 (we had high wind up to 45 MPH). The x-axes are wind speed in mph, the y-axes are either ALS-X(Y)_REFL_SCTRL_OUT_DQ (rms) or ISI-ETMY_ST1_FFB_BLRMS_(DOF)_(100M or 300M)_(300M or 1) (mean). The correlation (r) is calculated and printed in the parentheses. Since PEM-EX and ALS-Y seems to correlate the most (r=0.7783) I only plot the correlation between PEM-EX  and ISI-ETMY for the PEM/ISI correlation. PEM-EX and ISI-ETMY-RY (100-300 mHz) appears to have the highest correlation (r = 0.7469).

A Matlab script also attached.

Images attached to this report
Non-image files attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 16:02, Tuesday 17 March 2015 (17289)

My apology for the lack of axes labels earlier. I have attached better plots below....

Also, note that PEMEX, PEMEY, and PEMCS is in X, Y, Z direction (not locations). Also, the "ISI-ETMY_ST1_FFB_BLRMS_(DOF)_(100M or 300M)_(300M or 1) (mean)" are band-limited RMS of the T240s on stage1 ISI.

 

Images attached to this comment
Displaying reports 67641-67660 of 84498.Go to page Start 3379 3380 3381 3382 3383 3384 3385 3386 3387 End