Displaying reports 68081-68100 of 85875.Go to page Start 3401 3402 3403 3404 3405 3406 3407 3408 3409 End
Reports until 12:03, Wednesday 06 May 2015
H1 CDS
hugh.radkins@LIGO.ORG - posted 12:03, Wednesday 06 May 2015 - last comment - 12:51, Wednesday 06 May 2015(18275)
Keeping SDF Green--CHANS NOT FOUND list

SDF Cleanup

If channels are removed from your model/code whatever, unless you take your system down to the safe state and makeSafeBackup to generate from scratch a new safe.snap (and most of us know the problem doing that causes,) the SDF system will go yellow for CHANS NOT FOUND.  Okay, maybe no big deal but green is better than yellow when scanning our configuration control tools and we should green these up at earliest opportunity.

There is a way to clear these out with having to take the system down to a 'safe' state for the new snap.

You can just go to the SDF TABLE and while there you might as well look at the CHANS NOT FOUND list and make sure they make sense (yes, we did remove those channels from the model, e.g.)

Then from that medm, open the SDF SAVE SCREEN

Insure the SAVE TABLE selection is TABLE TO FILE and the FILE OPTIONS SELECTION is OVERWRITE

Press SAVE FILE

This step overwrites the safe.snap file removing the not found channel records.  Little wierd though, on the SDF_RESTORE screen (available from the TABLE screen as well,) it does not show a Modified file detected message, but, it has updated the time, as if it had 'Restored' to that time.  But you will notice that your list of Not Found Channels have not cleared.  Maybe this is explicitly intentional or is maybe a trivial bug.

Now on the SDF_RESTORE screen, press LOAD TABLE, and, all the NOT FOUND channels should clear.

However, there may be remaining NOT FOUNDs that will crop back up:

If the NOT FOUND CHANNELs list contains fields as opposed to just records, that is H1:HPI-ETMX_GUARD_CADENCE.HIGH (field) versus H1:HPI-ETMX_GUARD_CADENCE (record), this process will not remove the field lines from the safe.snap.

Still need to test this (Barker is on it) but, maybe the next time the front end starts, these fields will again become a CHANS NOT FOUND and our green lite will revert to yellow.

This happens because the FE code reads the safe.snap and strips out the field lines and saves them in a safe_alarms.snap file in the target area.  Then when it saves the safe.snap, this field list is just tacked onto the end of the safe.snap record list.  So your safe.snap will always contain these non existent channel field lines.

The fix to this problem is the following, before doing the steps above, (you could did it after but you'd be saving & loading twice) go to the target area and remove the appropriate field lines from the safe_alarm.snap file (currently writable only by controls.)  Once these are gone, proceed as above in the SDF SAVE SCREEN.

Comments related to this report
jameson.rollins@LIGO.ORG - 12:13, Wednesday 06 May 2015 (18276)

For what it's worth, all of those old "...GUARD_CADENCE" channels should be completely purged from all models.  That is old deprecated guardian infrastructure.  I think it has all been purged at LLO, so maybe LHO just needs to update the affected models.

jeffrey.kissel@LIGO.ORG - 12:51, Wednesday 06 May 2015 (18278)GRD
@Jamie -- indeed -- we've updated the hepitemplate.mdl which has these old GUARD channels remove and compiled / installed the BSC HEPI models this past Tuesday (LHO aLOG 18223). So, Hugh is just documenting how to get rid of them the last known hold out -- the safe.snaps.

The integration issues that tracks the removal of these vestigial organs are here:
SEI II 922
SUS II 921

They've been marked closed for some reason -- I think it's because again and again we've thought we'd gotten rid of them all, but continue to find them lurking about.
H1 PSL (DetChar, PSL)
edmond.merilh@LIGO.ORG - posted 11:32, Wednesday 06 May 2015 (18274)
PSL DBB scans
Non-image files attached to this report
H1 PSL
edmond.merilh@LIGO.ORG - posted 10:21, Wednesday 06 May 2015 (18272)
PSL Weekly Report - Past 10 day Trends
Images attached to this report
H1 GRD
thomas.shaffer@LIGO.ORG - posted 09:23, Wednesday 06 May 2015 (18271)
IMC_LOCK guardian modification

After adding the OFFLINE state, alog 18081 , it was found that the offsets will cause drift in this state as well like in alog 17929 . So, after talking to Kiwamu, I changed it to disable the offsets in the OFFLINE state as well as in the FAULT state and removed it from the DOWN state. The offsets are still enabled in the LOCKED state as before.

LHO VE
bubba.gateley@LIGO.ORG - posted 07:48, Wednesday 06 May 2015 (18270)
Beam Tube Washing
Scott L. Ed P. Chris S.(Cris M.1/2 day)

5/4/15
Cleaned 21.3 meters ending at HNW-4-028. Removed lights and relocated all equipment to next section. Began vacuuming and spraying bleach/water solution.

5/5/15
Cleaned 73 meters ending 14.5 meters north of HNW-4-031.
Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 06:36, Wednesday 06 May 2015 - last comment - 10:52, Wednesday 06 May 2015(18264)
SRCL noise injection, back to a good range

Evan, Sheila

Tonight we have some evidence that the work on recylcing gain has helped us, Evan will attach the DARM spectrum. 

Restoring the green camera offsets to the ones used during the mini run means that we can again lock with a recycling gain of ~37.  These wrong references and the bad alignment that went with it has probably caused some of the frequent lock losses of the last two days, and headaches in turning on ASC in full lock. Hopefully we can leave all green references alone for at least a week and see that they really do bring us back to a good recycling gain consistently.   My comments from yesterday about trying to figure out what drifts in green should be ignored.

We did some injections of noise into SRCL with all of our boosts on (MICH L, SRCL, DHARD P+Y), and the AS_C to SRM+SR2 loop at a 4 Hz bandwidth.  38 W/W recycling gain.  UTC May 6 11:48-11:53 UTC, no SRCL FF but MICH FF was on.   The goal was to see how stationary the coupling is now.  

We also restored some of the ASC cut offs that were deleted during the recycling gain work, CHARD PIT +YAW, DHARD P+ Y (for DAHRD P we are only using one of the two cutoffs we had, a pair of complex poles at 12 Hz, we don't have enough phase to use the 8 Hz cut off anymore so we wil need to redesign it if we need it)

Other business

We think that some usefull next steps on the list are

Comments related to this report
evan.hall@LIGO.ORG - 06:51, Wednesday 06 May 2015 (18269)

Spectrum attached. We are touching the 10 W GWINC curve from 200 Hz to 4 kHz. We have been able to do this a few times before by maxing out the gain of the CARM loop, but that was not necessary tonight.

Also I'm attaching a trend of POP90 and REFL_A_LF during the lock. There is some slow (perhaps thermal) drift. I looked at the PR3 and SR3 oplevs in pitch. PR3 seems to have a faster transient, while SR3 has a similarly slow drift. I tried touching SR3 to compensate for this (around 12:05:00Z), but it seemed to make no difference.

Also attaching a DARM OLTF.

Images attached to this comment
Non-image files attached to this comment
gabriele.vajente@LIGO.ORG - 10:52, Wednesday 06 May 2015 (18273)DetChar, ISC

The SRCL coupling is much more stationary now. During the noise injection, the coherence between DARM and SRCL was good. The first plot shows the measured TF between SRCL_OUT and the calibrated CAL-DELTAL signal. 

I analyzed the data using the same technique explained in previous entries (17912, 17928, 18026). The second attachment shows that the coherence is stationary over time and the third attachment is an animation of the TF between SRCL_OUT and DARM over time. It's remarkably more stationary than before.

Finally, the last two attachments (4th and 5th) shows the time evolution of the transfer function at 30 Hz and 100 Hz. The residual variation of the TF is about 5%, which may very well be within the error of my estimaton.

Images attached to this comment
H1 CDS
sheila.dwyer@LIGO.ORG - posted 21:13, Tuesday 05 May 2015 - last comment - 22:33, Tuesday 05 May 2015(18265)
lockloss tool error

We don't seem to be ablke to use the lockloss tool tonight, I get this message.  I'm not sure if this is realted to  bug  834, or to some maintence activity today. 

 sheila.dwyer@opsws4:~/Desktop/Locklosses$ lockloss select

Traceback (most recent call last):
  File "/ligo/cds/userscripts/lockloss", line 288, in <module>
    args.func(args)
  File "/ligo/cds/userscripts/lockloss", line 199, in cmd_select
    selected = select_lockloss_time(index=args.index)
  File "/ligo/cds/userscripts/lockloss", line 106, in select_lockloss_time
    times = list(get_guard_lockloss_events())[::-1]
  File "/ligo/cds/userscripts/lockloss", line 93, in get_guard_lockloss_events
    time = parse_guard_timestring(line[0])
  File "/ligo/cds/userscripts/lockloss", line 76, in parse_guard_timestring
    return gpstime.strptime(string, format)
  File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
    (data_string, format))
ValueError: time data '2015-05-06T02:27:30.12109' does not match format '%Y-%m-%dT%H:%M:%S.%fZ'
Comments related to this report
jameson.rollins@LIGO.ORG - 22:17, Tuesday 05 May 2015 (18266)

This was the result of the guardian log time stamp change, which slightly changed the format of the time stamps in the logs.

It should be fixed now.

sheila.dwyer@LIGO.ORG - 22:33, Tuesday 05 May 2015 (18267)

thanks

H1 ISC
eleanor.king@LIGO.ORG - posted 21:10, Tuesday 05 May 2015 (18263)
src length

Kiwamu, Keita, Elli

Today locked aux laser to swept frequency offset to carrier laser using PLL.  A network analyser provides a swept LO signal (7dBm into ZFM-4+ frequency mixer, or 10dBm if using a splitter.)  The RF signal is the beatnote of carrier and aux laser frequencies, which is demodulated against the LO using a ZFM-4+ mixer and 1.9MHz low-pass filter.  This error signal is sent to an LG1005 servo controller, P-I corner 10kHz, gain 4.1, LFGL 50dB.  We amplified the RF sigal (1611 pd on IOT2R) using 17dB ZFL-1000+ RF amplifier, as the error signal of the PLL was very weak; this made locking the PLL easier.  The PSL pwer was 2.3W, the aux laser power set to 500mW.

We noticed changing IM4 alignment during initial alignment changes alignment of beams onto the 1611 photodiodes enough that a quick realignment may be necessary.  This is a little painful as this alignment is done on IOT2R, where the aux laser is.  The aux laser frequency takes some time to settle after opening the table.  Again today we used the 1611 pd on ISCT1.  I unplugged the power to the bbpd-refl photodiode (the 3f refl pd) in order to power the 1611, and then changed this back again after I was done.

To take the measurement we locked DRMI 1f with ASC.  To engage PRC1, we adjusted the centering offset on Refl-DC WFS.  We looked at the signal reflected from DRMI using a 1611pd on ISCT1 on the reflair path, and measured the transfer function of this reflected light intensity over the LO frequency.  Could see transmission dips every ~2.6MHz, which correspond to the auxiliary laser resonance in PRC.  Also some other peak which may be higher order mode.  Currently producing a model to make sense of this, and to decide what frequencies will be useful to measure at.

Images attached to this report
Non-image files attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 18:16, Tuesday 05 May 2015 (18262)
End Y QPD transimpedance amp was also swapped.

After the whitening chassis was swapped, the worst problem went away, i.e.  QPDA seg2 looked healthy.  However, smaller problem, i.e. the dark noise level of QPDA seg4 being about a factor of 2 or 3 higher than everybody else (attached top), persisted.

Disconnecting QPD cable from the transimpedance box did not change the behavior, but disconnecting the cable between the transimpedance box and the whitening chassis did.

Anyway, QPD transimpedance amps was also swapped and everything looks good (bottom).

Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 16:49, Tuesday 05 May 2015 (18261)
BSC1 Annulus Ion Pump

Removed and replaced the annulus Ion Pump, aux pump cart will remain pumping on annulus system for some time.

As of this entry the current for this pump is at 3.02 mA.

H1 SEI
patrick.thomas@LIGO.ORG - posted 16:36, Tuesday 05 May 2015 (18260)
OPS: reset of HEPI L4C Accumulated WD Counters Tuesday 5th May 2015
Reset HAM5 and ITMY.
H1 PSL
patrick.thomas@LIGO.ORG - posted 16:32, Tuesday 05 May 2015 (18259)
added 200 mL of H2O to the H1 PSL chiller


			
			
H1 CDS
patrick.thomas@LIGO.ORG - posted 16:25, Tuesday 05 May 2015 (18258)
Updated Conlog channel list
Added 15 channels. Removed 50 channels.
2 channels remain unmonitored:
H1:SUS-SR2_LKIN_P_OSC_SW2R
H1:SUS-SR2_LKIN_Y_OSC_SW2R
H1 AOS
patrick.thomas@LIGO.ORG - posted 16:20, Tuesday 05 May 2015 (18225)
Ops Summary
07:54 Elli to IOT2R
08:08 Jeff B. to LVEA to pull data out of humidity/temperature monitor in desiccant cabinet
08:14 Filiberto to end Y to swap whitening board for ISC
08:14 Karen to end Y to clean
08:36 Jeff B. back
08:56 Gerardo to LVEA to move pump cart in preparation for replacing annulus ion pump on BSC1
09:06 Karen and Filiberto leaving end Y
09:12 Jim B. finished updating GDS tools
09:30 Nutsinee to LVEA to find Elli
09:32 Kiwamu starting calibration of ETMX and ETMY optical levers
09:39 Keita checking swap of whitening board, misaligned ETMY
09:41 Nutsinee to LVEA to work on HWS table by HAM4
09:44 Gerardo out of LVEA
09:47 Dave restarted the guardian machine
09:49 Kyle to end Y to start bakeout of BSC6 RGA
09:55 Keita done on ETMY, to LVEA to talk to Elli
09:56 DAQ restart
10:00 Robert to LVEA to setup for PEM injections
10:01 Jim B. finished update of command line nds tool
10:23 Cris to end X
10:34 Kiwamu done optical lever calibration
10:40 Gerardo beginning replacement of BSC1 annulus ion pump
10:41 Nutsinee misaligned TMSY
10:58 Guardian restarted
11:18 Jim W. installing new ISI filters on ETMY
11:37 DAQ restart
11:47 Kiwamu calibrating PR3 optical lever
11:59 Kiwamu and Jason to LVEA to check whitening settings on PR3 optical lever
12:10 Cris back
12:23 Robert to end Y to set up for PEM injections
12:25 Kyle back from end Y
12:28 Kiwamu and Jason back
12:31 Kyle to LVEA to help Gerardo
12:49 TJ to end X to turn BRS damper on
12:59 Robert back
13:30 TJ back
13:37 Keita to end Y to look at transimpedence amplifier for QPDs
13:41 John to LVEA to look at platform Gerardo is using
14:02 Jeff K. to CDS electronics high bay
14:04 John and Kyle to end X mechanical room to change voltage on ion pump controller
14:05 Gerardo to LVEA
14:22 Gerardo back
14:42 John and Kyle back
15:08 Keita back from end Y
16:14 Elli, Keita and Kiwamu have locked DRMI and are taking a measurement by HAM1

H1 AOS
jason.oberling@LIGO.ORG - posted 17:18, Wednesday 08 April 2015 - last comment - 05:16, Wednesday 06 May 2015(17760)
SR3 Optical Lever Laser Replacement

J. Oberling, S. Doravari

With the HAM6 activity closing out, we took advantage of the window and tweaked another laser and swapped it into SR3.  The SN of the new laser is 199.  This was installed in the SR3 optical lever so we will have data for a direct comparison between the stabilized diode laser here at LHO and the fiber-coupled HeNe in use as the LLO SR3 optical lever.  We will begin monitoring this laser tomorrow after it thermally stabilizes overnight so we can perform, if necessary, final tweaks to the laser power to finally stabilize the laser.

Comments related to this report
suresh.doravari@LIGO.ORG - 18:06, Wednesday 08 April 2015 (17762)

Just attaching images associated with this work.

1) SR3 Oplev laser currently installed is Sl. No. 199

2) The binary switch state for setting gain and whitening.  Currently there is just 3dB of gain and no whitening

3) power spectra of adc noise floor and sum signal to show that the signal is atleast ten times larger than the noise floor at all frequencies of interest

Images attached to this comment
evan.hall@LIGO.ORG - 05:16, Wednesday 06 May 2015 (18268)

It seems there is a discrepancy between the SR3 pitch slider and the SR3 oplev motion. I move the pitch slider by what I think is 0.5 µrad, and the oplev reports that SR3 moves by 0.2 µrad. Not sure about yaw.

Images attached to this comment
Displaying reports 68081-68100 of 85875.Go to page Start 3401 3402 3403 3404 3405 3406 3407 3408 3409 End