Displaying reports 63641-63660 of 83294.Go to page Start 3179 3180 3181 3182 3183 3184 3185 3186 3187 End
Reports until 16:38, Monday 03 August 2015
H1 General
betsy.weaver@LIGO.ORG - posted 16:38, Monday 03 August 2015 - last comment - 22:18, Monday 03 August 2015(20173)
TUESDAY MAINTENANCE PLAN

Attached is the whiteboard list of tomorrow's scheduled tuesday maintenance activites.  We'll start withnumerous model restarts and move into some hardware work.

Here are the list of tomorrow's maintenance day tasks organized as we intend to execute them chronologically, and prioritized such that the tasks with the most global impact on the IFO are done first (such that we have the most time to recover from them). As with previous Tuesday, all tasks, associated estimated times for completion, and responsible persons will be added to the reservation system when they are *actually happening*, and removed after the task manager has checked in with the operator and confirmed completion. PLEASE PAY ATTENTION TO THE RESERVATION SYSTEM

As always, please keep the operators informed of your activities as accurately as possible / reasonable throughout the maintenance day so the reservation list can be adjusted accordingly and remain accurate. We appreciate your cooperation!

1st Round:

Cabling of EOM Driver - will involve climbing on HAM1 and HAM2 chamber areas

Restart all ISI Models

Restart all SUS Models

Restart ASC and LSC modelsInstall TCSy CO2y temperature sensor on viewport

Revert Ey fast FE to slower machine to reduce glitching

Revert Ey BIOS

VE EX NEG Regeneration

PEM injection hardware setup

 

2nd Round:

DAQ Restart

TCS Ring Heater Filter Install

PSL PMC/ISS checkout

IO (in PSL) Documentation

Guardian Upgrade/restart

 

3rd Round:

ETMy UIM rocker switch fix

EX/EY PCAL Tune up and Calibration

 

Comments related to this report
betsy.weaver@LIGO.ORG - 16:39, Monday 03 August 2015 (20174)

Attached is the hand-Gant chart of the plan for tomorrow.

Images attached to this comment
daniel.sigg@LIGO.ORG - 22:18, Monday 03 August 2015 (20183)

The ASC model will not be changed tomorrow due to lack of time.

The EOM driver code in the EtherCAT system will be updated.

A PPS monitor code will be added to the timing system.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:12, Monday 03 August 2015 (20172)
Ops Day Shift Summary
LVEA: Laser Hazard
IFO: Unlocked
Observation Bit: Commissioning  

Times in UTC
15:00 IFO unlocked for Ops locking training
18:20 Hugh – Going to end stations to check HEPI fluid reservoir levels
18:28 Ed – Going to Mid-X to reinstall repaired AA chassis 
18:52 Ed – Back from mid station
20:45 Filiberto – Cabling work at Mid-Y
21:31 Daniel – Going into CER
22:08 Stefan – Going to ISC rack
22:10 Kyle – Going into End-X VEA to connect and start RGA bakeout 
22:25 Stefan – Out of the LVEA
LHO VE
kyle.ryan@LIGO.ORG - posted 16:02, Monday 03 August 2015 (20171)
~1515 - 1525 hrs. local -> In and out of X-end VEA
Valved-in Nitrogen cal-gas into RGA volume (pumped by aux. cart) -> Energized RGA filament
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:12, Monday 03 August 2015 (20170)
Update to SUS IOP Glitching Tripping the ETMY BSC ISI

Here is an update to 19908 and Dave's 19808.  See attached 21 days of trends: the SUS glitches are not tripping the ISI with the new model code.

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 14:18, Monday 03 August 2015 (20169)
All LHO ISI models recompiled for WD Reset/countdown upgrade

WP 5396

ECR E1500325

II 1086

All the local ISI models have been successfully recompliled to svn rev 11156.  This update allows clearing of the saturation count separately from the WD reset.  Also, every minute, saturations older than one hour are dropped from the count total.  If there are no saturations for the past hour, there will be no saturations totaled.

These models will be installed and then restarted tomorrow.

H1 SUS
jenne.driggers@LIGO.ORG - posted 13:58, Monday 03 August 2015 - last comment - 21:49, Wednesday 05 August 2015(20099)
Post-lock drift of PR3, SR3 in pitch

Rana pointed out to me that the PR3 and SR3 suspensions may still have some shift due to wire heating during locks (which we won't see until a lockloss, since we control the angles of mirrors during lock).

Attached are the oplev signals for PR3 and SR3 at the end of a few different lock stretches, labeled by the time of the end of the lock. The lock ending 3 Aug was 14+ hours.  The lock ending 31 July was 10+ hours.  The lock ending 23 July was 5+ hours.  The lock ending 20 July was 6+ hours.

The PR3 shift is more significant than the SR3 shift, but that shouldn't be too surprising, since there is more power in the PRC than the SRC so there is going to be more scattered light around PR3. Also, PR3 has some ASC feedback to keep the pointing.  SR3 does not have ASC feedback, but it does have a DC-coupled optical lever.  SR3 shifts usually a few tenths of a microradian, but PR3 is often one or more microradians.  Interestingly, the PR3 shift is larger for medium length locks (1 or 1.5 urad) than for very long locks (0.3 urad).  I'm not at all sure why this is.

This is not the end of the world for us right now, since we won't be increasing the laser power for O1, however we expect that this drift will increase as we increase the laser power, so we may need to consider adding even more baffling to the recycling cavity folding mirrors during some future vent.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 10:05, Wednesday 05 August 2015 (20258)

Note - The PR3 and SR3 have 2 different baffles in front of them which do different things.  The PR3 HAS a baffle which specifically shields the wires from the beam.  The SR3 does not have this particular baffle, however I believe we ave a spare which we could mount at some point if deemed necessary.

Attached is a picture of the PR3 "wire shielding baffle D1300957, showing how it shields the suspension wires at th PR3 optic stage.  In fact, a picture of this baffle was taken from the controlroom and is in alog 8941.

The second attachment is a repost of the SR3 baffle picture from alog 16512.

Images attached to this comment
rana.adhikari@LIGO.ORG - 21:49, Wednesday 05 August 2015 (20279)AOS

from the pictures, it seems like we could get most of the rest of the baffling we need if the wire going under neath the barrel of PR3 were to be covered. Perhaps that's what accounts for the residual heating. Also, if it became a problem perhaps we can get an SR3 baffle with a slightly smaller hole to cover its wires.

H1 PSL
jeffrey.bartlett@LIGO.ORG - posted 13:51, Monday 03 August 2015 (20168)
PSL Status
PSL Status: 
SysStat: All Green, except VB program offline & LRA out of range 
Output power: 32.4w  
Frontend Watch: Green
HPO Watch: Red

PMC:
Locked: 5 days, 2 hours, 3 minutes
Reflected power:    2.1w
Transmitted power: 22.8w 
Total Power:       24.9w 

ISS:
Diffracted power: 9.2%
Last saturation event: 0 days, 0 hours, 24 minutes 

FSS:
Locked: 0 days, 0 hours, 24 minutes
Trans PD: 1.384v
 
H1 CAL (CAL)
richard.savage@LIGO.ORG - posted 13:38, Monday 03 August 2015 (20167)
Calibration line amplitudes

DarkhanT, RickS

We found that the DARM_CTRL excitation line reverted to old values on 7/31 (last Friday) at about 11:13 PDT, 18:13 UTC.  Perhaps this was the result of an errant BURT restore, but we didn't find a record of one in a quick survey of the aLog.

When we set the lines last week (see this link), we didn't update the SDF (our bad!).

Today, we reset the frequency of the DARM_CTRL line and adjusted the amplitude to give us SNR ~100.  We also adjusted the amplitude of the Pcal lines to adjust their SNRs to be near the design values.

The updated settings are:

Excitation point Freq.(Hz) Amp.(cts.) Target SNR
(10-sec. FFT)
Range
used.(%)
DARM_CTRL 37.3 0.085 100 ??
PcalY 36.7 125 100 0.3
PcalY 331.9 2900 100 6.9
PcalY 1083.7 15000 13 36
H1 SEI
hugh.radkins@LIGO.ORG - posted 13:07, Monday 03 August 2015 (20166)
LHO HEPI Fluid Reservoirs Checked--Good

Wanted to know before Tuesday whether there were any reservoir level=>accumulator problems.  All reservoir levels are unchanged.  No HEPI maintenance tomorrow.

H1 CDS (SUS)
david.barker@LIGO.ORG - posted 12:52, Monday 03 August 2015 (20165)
18bit DAC autocal results from last Tuesday's restarts

Late entry from last Tuesday's SUS front end restarts, here are the results of the 18bit DAC AUTOCALs performed by the IOP model. One card fails autocal, two take an addtional 1.2S to complete.

h1susb123

[6026421.925705] h1iopsusb123: DAC AUTOCAL FAILED in 5344 milliseconds 
[6026427.286059] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[6026433.073912] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[6026438.434332] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[6026445.457686] h1iopsusb123: DAC AUTOCAL SUCCESS in 6576 milliseconds 
[6026450.818041] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[6026456.178303] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[6026461.537803] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds 
 
h1sush2a
 
[5885314.201965] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5885319.562309] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5885326.585739] h1iopsush2a: DAC AUTOCAL SUCCESS in 6572 milliseconds 
[5885331.946076] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5885337.733940] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5885343.094372] h1iopsush2a: DAC AUTOCAL SUCCESS in 5341 milliseconds 
[5885348.454724] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds 
 
h1sush2b
 
[2422259.598387] h1iopsush2b: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[2422264.958836] h1iopsush2b: DAC AUTOCAL SUCCESS in 5345 milliseconds 
 
h1sush34
 
[5962934.903750] h1iopsush34: DAC AUTOCAL SUCCESS in 5341 milliseconds 
[5962940.264027] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5962946.051914] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5962951.412329] h1iopsush34: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[5962957.200212] h1iopsush34: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[5962962.559720] h1iopsush34: DAC AUTOCAL SUCCESS in 5340 milliseconds 
 
h1sush56
 
[2418700.148743] h1iopsush56: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[2418705.509074] h1iopsush56: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[2418711.296963] h1iopsush56: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[2418716.657324] h1iopsush56: DAC AUTOCAL SUCCESS in 5344 milliseconds 
[2418722.445270] h1iopsush56: DAC AUTOCAL SUCCESS in 5344 milliseconds 
 
h1susex
 
[613223.518484] h1iopsusex: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[613228.876736] h1iopsusex: DAC AUTOCAL SUCCESS in 5383 milliseconds 
[613234.662541] h1iopsusex: DAC AUTOCAL SUCCESS in 5345 milliseconds 
[613240.020587] h1iopsusex: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[613245.378585] h1iopsusex: DAC AUTOCAL SUCCESS in 5318 milliseconds 
 
h1susey
 
[  130.787835] h1iopsusey: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[  136.148897] h1iopsusey: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[  141.941127] h1iopsusey: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[  147.302189] h1iopsusey: DAC AUTOCAL SUCCESS in 5346 milliseconds 
[  152.663846] h1iopsusey: DAC AUTOCAL SUCCESS in 5346 milliseconds 
 
 
 
 
 
H1 General
thomas.shaffer@LIGO.ORG - posted 12:21, Monday 03 August 2015 (20163)
Morning Locking Summery

H1 was locked when I got in, so I brought ISC_LOCK to DOWN to get some locking practice.

It went up to CARM_ON_TR before stopping and notifying  of "No IR in arms".

Sheila mentioned in a log a few weeks back to go to manual and then go back to the state PREP_TR_CARM, but that did not solve the issue and broke lock when I went back to CARM_ON_TR.

Brought it back up and got the same notification, and then I did exactly what I did last time.

While it was going up and down the last few times I was investigating some of the work the commissioners did last night, and I ended up using SDF to switch back some of the changes from alog20146

At this point I got Jenne involved and she worked hard trying to figure it out while I went to a training.

When Evan came in he admitted that he had forgotten to turn back on the Input to the H1ALS-C_REFL_DC_BIAS filter module.

This seemed to have solved the issue.

This filter module is not being monitored, so I added it to the SDF monitor and Jenne added it to the Guardian.

All seems to be good now, made it to COIL_DRIVERS before a commissioner accidentally lost lock.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 11:24, Monday 03 August 2015 (20162)
08:30 Meeting Minutes
Log Times – The time stamp on the headers of aLOG entries are in Local Time. After much discussion, the times in body of the log entries should be entered in UTC time, with a note to that effect. Example: “restarted XYZ at 15:45 UTC”.

Betsy is giving operator training on the SDF system at 10:00 in the control room.

The New LIGO Web page has launched.
 
Prep work for the Tuesday maintenance window: 
   Sub Systems are coordinating planned updates
   CDS: will swap a switch on the End-Y UIM Coil Driver
   VAC: will be regenerating the NEG pump at End-X
   FAC: will be moving several crates to Mid-X    
LHO VE
kyle.ryan@LIGO.ORG - posted 11:17, Monday 03 August 2015 (20161)
1050 - 1100 hrs. local -> In and out of X-end VEA (stopped RGA heating)


			
			
H1 ISC
peter.fritschel@LIGO.ORG - posted 11:08, Monday 03 August 2015 - last comment - 12:30, Monday 03 August 2015(20160)
Suggestions for high frequency 'mystery' noise

Matt E and I were talking about the broadband noise that is showing up coherently in the OMC DC readout, increasing the noise by 15% or something above shot noise, at frequencies above ~80 Hz. The observation is that this noise increases as the input power is increased (i.e., the watts/rtHz on the OMC DC PDs goes up with higher input power). Amplitude noise on one or more RF sidebands is a plausible source of this noise (not a new idea), and we wanted to suggest specific tests be done to look for RF sideband noise. For example:

Comments related to this report
evan.hall@LIGO.ORG - 12:30, Monday 03 August 2015 (20164)

The OMC refl shutter is normally kept closed, but I have just opened it.

H1 TCS
eleanor.king@LIGO.ORG - posted 10:02, Monday 03 August 2015 - last comment - 15:36, Tuesday 04 August 2015(20158)
Using the corner station HWS

There have been some questions about how to run the HWS code.

The HWS code runs on one of three HWS computers, we have one at each end station and one at the corner station.  I have set up a tmux session to run the HWS code constantly at the corner station.  If the code is running, the heartbeat will flash on the TCS HWS ITMX/Y medm screens, and the seidel aberrations will update once a second on the HWS ITMX/Y CODE screen.  To take a measurement using the HWS, in addition to having thr HWS code running, you also need to turn on the RCX link framegrabber power, the Dalsa 1M60 Camera power, and the Superluminescent diode (SLED) power switched on the HWS medm screen.  To increase the lifetime of the SLED and to avoid injecting 1Hz noise into the PEM channels (we are working on filters on the camera power supply to fix this one), we are leaving the HWS hardware off if we are not using it.

 

If you want to stop or restart the corner station code for some reason, you can ssh into the cornerstation hws computer:

>>    ssh -X controls@h1hwsmsr

and attach to the tmux session

>>    tmux attach

This webpage (http://www.dayid.org/os/notes/tm.html) has a list of tmux commands.  We are running two sessions, one for ITMX and one for ITMY.  Go to the relevant session, go to the folder ~/temp, and run the HWS code with the command

>>    Run_HWS_H1ITMX  (or ITMY....)

Comments related to this report
eleanor.king@LIGO.ORG - 15:36, Tuesday 04 August 2015 (20216)

Jim and Dave have installed tmux on the end station HWS computers (thanks guys), so the code is running at these computers now too. It is intialized with the command  >> Run_HWS_H1ETMX  or  >>Run_HWS_H1ETMY in ~/temp, after you log into controls@h1hwsey (or h1hwsex).

H1 CDS (ISC)
jameson.rollins@LIGO.ORG - posted 09:58, Monday 03 August 2015 - last comment - 16:48, Monday 03 August 2015(20157)
h1lsc test points cleared to clear up errant excitation in

There was a persistent excitation in:

H1:ALS-C_REFL_DC_BIAS_EXC

on h1lsc.  This was presumably from an awg process left running by Evan on operator1 workstation.

I killed ALL testpoints on h1lsc (dcuid 10):

jameson.rollins@operator1:~ 0$ diag -l -z
supported capabilities: testing  testpoints  awg 
diag> tp clear 10 *
test point cleared
diag>

Comments related to this report
james.batch@LIGO.ORG - 16:48, Monday 03 August 2015 (20175)
Actually, you should clear the awg, then clear the test point. As it is now, there is still an awg slot with a sine excitation, but no test point.
H1 TCS (ISC)
evan.hall@LIGO.ORG - posted 18:37, Sunday 02 August 2015 - last comment - 10:09, Monday 03 August 2015(20146)
TCS test in progress

Kiwamu, Stefan, Evan

We are trying to minimize the coupling of frequency and intensity noise into DARM by tuning the central heating on the IX CP.

The following excitations have been set up:

The amplitudes were chosen so that each line has an SNR of 50 or so in OMC DCPD sum with a 10 s FFT. Each demodulator demodulates OMC DCPD sum at the appropriate frequency, and then lowpasses I and Q with a 100 mHz, 4th-order butterworth.

At 2015-08-03 01:19:45 Z we changed the IX CP heating power from 0.23 W to 0.36 W.

At 2015-08-03 02:57:25 Z we changed the IX CP heating power from 0.36 W to 0.53 W.

At 2015-08-03 04:26:20 Z we changed the IX CP heating power from 0.53 W to 0.41 W.


Additionally:

Comments related to this report
evan.hall@LIGO.ORG - 21:59, Sunday 02 August 2015 (20154)

Stefan has reverted the rewiring on the CARM board.

We are leaving the injected frequency line on so we can watch it as the interferometer settles into its new thermal state.

stefan.ballmer@LIGO.ORG - 22:42, Sunday 02 August 2015 (20155)
Also, we further increased the ISS gains: the first loop went up by 10dB, the second loop by 6dB. No immediate noise improvement was visible in DARM.
lisa.barsotti@LIGO.ORG - 10:09, Monday 03 August 2015 (20159)ISC
I looked at OMC SUM/NULL during the long lock last night, after the frequency noise injection was turned off.
There is no significant difference between the beginning and the end of the lock. The excess of noise was of the order of 10% shot noise level, similarly to the night before. The highest excess of noise I have seen is ~15%, corresponding to  a few days ago , July 31st.
Images attached to this comment
Displaying reports 63641-63660 of 83294.Go to page Start 3179 3180 3181 3182 3183 3184 3185 3186 3187 End