Displaying reports 58161-58180 of 78430.Go to page Start 2905 2906 2907 2908 2909 2910 2911 2912 2913 End
Reports until 08:02, Monday 24 August 2015
H1 General
edmond.merilh@LIGO.ORG - posted 08:02, Monday 24 August 2015 (20816)
End of Shift Summary and Lock Log

ALL TIMES IN UTC

Science Mode Checklist: (beginning of shift)

Activity Log:

LOCK LOG:

Shift Summary:

H1 General
edmond.merilh@LIGO.ORG - posted 06:30, Monday 24 August 2015 (20815)
IFO set to Observing Mode

13:28UTC OIB and OOM set to Undisturbed/Observing

H1 General
edmond.merilh@LIGO.ORG - posted 05:11, Monday 24 August 2015 - last comment - 05:13, Monday 24 August 2015(20813)
Switching IFO to Observation Mode

ALL TIMES IN UTC

 

Science Mode Checklist:

Activity Log:


Comments related to this report
edmond.merilh@LIGO.ORG - 05:13, Monday 24 August 2015 (20814)

12:07 LockLoss. 

  1. 5.0113km E of Ust'-Kamchatsk Staryy, Russia2015-08-24 11:51:01 UTC31.7 km
H1 ISC (GRD)
evan.hall@LIGO.ORG - posted 04:49, Monday 24 August 2015 - last comment - 12:33, Monday 24 August 2015(20811)
Some cHard/PRC WFS investigation

Sheila, Evan

We looked again at the situation with the 45 MHz REFL WFSs, which are used as sensors for the PR3 ASC loop. In the end, we didn't implement any changes to the sensors or the associated loops.

We were motivated by the following:

  1. The current demod phases for these WFSs simply do not make sense; we expect that they should be similar (since the analog delays should be fairly well matched), but instead they are scattered by 100+ degrees.
  2. The cHard and PR3 loops are strongly cross-coupled. We would like to be able to turn up the gain of cHard without impressing extra motion from other optics into DARM. [20523, 20497]
  3. Any perturbation in the PR3 seems to couple into the SRC loops. We already know that the SRM loop is quite delicate, and we would like to get rid of this coupling if possible.

We tried the following:

After that, we couldn't get to full power because of an oscillation that showed up in dHard pitch when going to 20+ W. (We've seen this before, and it seems to be distinct from the angular instability mentioned above.) To get around this, we had to slightly beef up the resonant gain that gets turned on in dHard pitch when the power is increased.

Also, there were some small maintenance tasks that we did:

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 12:33, Monday 24 August 2015 (20825)

Two of the chaanges that we made last night we kept. 

With the new phasing for refl 45, it was no longer a good sensor to use in DRMI, so we changed PRC2 in this configuration to using the sum of refl A and B 9I.  This is in the DRMI guardian and works fine, so we've left it there. 

We left the DC coupled OpLev off, we think the cage servo will have less drift. 

H1 General
edmond.merilh@LIGO.ORG - posted 03:54, Monday 24 August 2015 (20812)
Mid-Shift Update: OWL

ALL TIMES IN UTC

On my arrival, Evan, Sheila and Dan on site (of course Jim also). Not really any wind to speak of (~10mph). Minor earthquake activity in the last couple of hours after about 5 hours of quiet. Everyone gone except for Evan.

 

Science Mode Checklist: (since beginning of shift)

Activity Log:

H1 General
jim.warner@LIGO.ORG - posted 23:59, Sunday 23 August 2015 (20809)
Shift Summary

Quiet night again.

IFO was locked when I arrived, but was knocked out by an earthquake.

Sheila and Evan have been working on ASC improvements since.

H1 General (DetChar, GRD, SUS)
cheryl.vorvick@LIGO.ORG - posted 16:03, Sunday 23 August 2015 - last comment - 00:11, Monday 24 August 2015(20808)
Ops Day Summary:

Lock loss where SRCL went first.

Guardian code issue stalled progress to Low Noise, now fixed.

ETMX PUM needed to be reset.

IFO has been locked for 2 hours and range is above 60MPC.

Currently in commissioning mode - Sudarshan, Sheila, and Evan are here.

Comments related to this report
sheila.dwyer@LIGO.ORG - 00:11, Monday 24 August 2015 (20810)

just to clarify, it was the UIM driver that needed to be reset

H1 DetChar
cheryl.vorvick@LIGO.ORG - posted 15:38, Sunday 23 August 2015 (20806)
Lock Loss at 17:46:26UTC - SRCL went first, then PRCL

Plot attached shows SRCL goes at -30 seconds, then PRCL goes at -12 seconds.

Images attached to this report
H1 GRD
cheryl.vorvick@LIGO.ORG - posted 13:46, Sunday 23 August 2015 - last comment - 15:39, Sunday 23 August 2015(20800)
H1 issues and relocking

Lock Loss right after PRM saturation - lock loss plot shows an issue in SRCL came first, then PRCL responded, then lock loss

- plot attached shows PRM _M3_LOCK_L_OUTPUT 

--- signal changes directions at 17:46:14UTC

--- exceeds it's normal range at 17:46:17UTC

--- abrupt change of the signal at 17:46:22UTC

--- signal exceeds it's normal range (negative) at 17:46:25UTC, Lock Loss

 

Relocked:

- didn't make it through RF_DARM

 

Relocked:

- didn't make it through RF_DARM, and I tried to diagnose it, but couldn't, so put the IFO Mode to "unknown,"

 

Guardian Code issue, corrected:

- Sheila arrived and she diagnosed the problem - Guardian code was waiting for OMC_LOCK to be in "ready to hand off" but OMC wasn't ready.

- Sheila corrected the code so now it only looks at the two arms to see if they are ready.

 

LSC_LOCK was waiting for OMC to be ready, but OMC wasn't ready, so we cleared that and tried to go on t DARM_WFS and the IFO made some progress but then lost lock.

 

 

Relocked

- lost lock at DARM_WFS again - reason unknown.

 

ETMX Coil issue, corrected:

- after lock loss, ETMX coils died, Sheila went to EX to fix.

 

Back in Observing/Undisturbed Mode:

- ETMX fixed, relocking went well, and as of 20:36UTC Obs/Und Mode bit set.

 

NOTE: on the observatory mode screen

I used the UNKNOWN mode for locking issues (since the cause was unknown to me) and for the ETMX fix (because Corrective Maintenance just didn't seem to fit what was an equipment failure).

Comments related to this report
cheryl.vorvick@LIGO.ORG - 15:32, Sunday 23 August 2015 (20805)

ETMX coils didn't actually die... it was the PUM driver, and it was reset... 

Repairs planned for Tuesday Maintenance.

H1 SUS
cheryl.vorvick@LIGO.ORG - posted 12:41, Sunday 23 August 2015 (20798)
ETMX coils die

Sheila is driving down to EX to fix.

ETMX SUS screen doesn't seem to have any indicator that something's not OK.

Guardian error message: SUS ETMX saturation.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:37, Sunday 23 August 2015 (20797)
CDS model and DAQ restart report, Saturday 22nd August 2015

ER8 Day 6. No restarts reported.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:36, Sunday 23 August 2015 (20796)
CDS model and DAQ restart report, Friday 21st August 2015

ER8 day 5. No restarts reported.

LHO General
corey.gray@LIGO.ORG - posted 08:20, Sunday 23 August 2015 (20795)
Ops 8/23 OWL Summary

8/23 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

Summary:

Handed an H1 in NOMINAL_LOW_NOISE, but it was marked for Commissioning, so Jim took it to Undisturbed (6:56utc).  But then after he mentioned the temporary fix for the hobbling PRM, decided to take it out of Undisturbed (7:10utc with 50Mpc range) to run Evan's python script.  This took us up 10Mpc, and went back to Undisturbed at (7:19utc) with a range of 60Mpc.

Shift Activities:

PRM NOTE:  If H1 drops out of lock, one will want to see if it acuires without PRM's LL.  If it does not, then one will want to revert the matrix for PRM (see Evan's aLog or python script for matrix elements).  The script is currently saved on the Desktop of the Ops Workstation and can be run in a terminal (it takes about 1 min to zero out the LL elements).

Since we had some empty space on the nuc wall monitors, I put up a few items:  (I assume once we can run DMT Viewer on these monitors we'll put seismic plots on them.)

H1 ISC
evan.hall@LIGO.ORG - posted 22:16, Saturday 22 August 2015 - last comment - 02:44, Tuesday 25 August 2015(20793)
PRM M3 LL ramp-off

Jim, Evan

We have grown tired of the glitching in the PRM M3 LL OSEM, so here is a script that ramps it off in full lock. It gets rid of the glitching and allows us to recover 60ish Mpc range.

Also included is a screenshot of the usual Euler/OSEM matrix for PRM.

Images attached to this report
Non-image files attached to this report
Comments related to this report
andrew.lundgren@LIGO.ORG - 14:29, Sunday 23 August 2015 (20801)DetChar, ISC, SUS
From detchar, here are some glitchgrams to show just how well this works. The PRM M3 LL OSEM was ramped off at 3:43 UTC, and again at 7:13 UTC in a different lock (times gotten by check EUL2OSEM matrix elements). Two glitchgrams are attached which shows that the excess glitchiness goes away as soon as the LL quadrant is disabled. This is fantastic because these are one of our top most worrisome glitch classes from ER7.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 20:36, Monday 24 August 2015 (20840)DetChar
Hey @DetChar, can you make a glitch-gram of the H1:SUS-PRM_M3_NOISEMON_LL_DQ? 

Evan's gunna make a spectragram to see if it contains the same frequency content as the glitch grams (of DARM and the one you'll make). This "on/off" test of PRM M3 LL, at least shows that the frequency content of the glitching is below 50 [Hz]; if the content is similar in spectragram, we can use that -- a spectragram is much easier to make on the floor and/or at least here on site while the channel is being investigated. 

At this point, the entire drive chain is suspect, and we're not really sure where to start. I worry that starting without a more pointed target, it means we'll be looking for hours, slamming a sledge hammer blindly everywhere, and only come up with more questions. For example, as you know, these NoiseMons can be tricky. This particular PRM M3 LL NoiseMon has passed what tests that have been done on it (see LHO aLOG 17890), but the test is only a "which one of these doesn't look like the other" kind of test, not anything concrete.
evan.hall@LIGO.ORG - 21:08, Monday 24 August 2015 (20842)

Jeff and I looked at a time series trend of the LL noisemon when the interferometer was not locked, in order to give a baseline for diagnostics.

During a quiet time, it seems the peak-peak of the noisemon is about 30 counts, which [accounting for the ADC gain (216 ct / 40 V)] is something like 20 mV pp.

During a noisy time, the peak-peak can go as high as 100 counts, which is something like 60 mV pp.

Non-image files attached to this comment
andrew.lundgren@LIGO.ORG - 02:44, Tuesday 25 August 2015 (20853)DetChar, ISC, SUS
@Jeff - A glitchgram would not be terribly enlightening. Normalized spectrograms actually show these glitches very clearly, and even standard spectrograms are fine. 

These glitches only show up in DARM to about 70 Hz, but they're in PRCL up to 150 Hz (first plot). They're getting fed back to PRM, among other things, so all four quadrants' drive signals look like PRCL. The second plot is the normalized spectrogram of LL MASTER, and it's the same as PRCL. There's also something near Nyquist in the plot, but I think it's just spectral leakage in the spectrogram.

The characteristic of the LL noisemon (third plot), in contrast to the other noisemon, is that the glitches go up to 1 kHz. They happen at the same time as the glitches in MASTER, so below 150 Hz this doesn't tell us anything. But the higher-frequency content indicates that something before the noisemon is creating excess noise. And since the excess noise goes away as soon as the LL drive is zeroed, it's not just a problem in the noisemon.

The noisemon stops showing any glitches once the drive is zeroed, which may be a useful clue. Is it possible to drive a single line in MASTER and see what the noisemon shows?

The first three plots were all normalized spectrograms. The last two are standard spectrograms to show that these glitches do show up there. I used 0.25 sec FFTs with overlap of 0.9.
Images attached to this comment
H1 General
travis.sadecki@LIGO.ORG - posted 10:56, Friday 21 August 2015 - last comment - 15:47, Sunday 23 August 2015(20744)
PCal line turned back on

Sudarshan reports that a PCal line was turned off sometime last night.  He is turning it back on at 17:53.

Comments related to this report
sudarshan.karki@LIGO.ORG - 11:30, Friday 21 August 2015 (20747)

Darkhan, Sudarshan

Pcal Lines got turned off last night during a pcal sweep measurements (LHO alog 20734 and  20732) because the optical follower servo got unlocked. We  turned two lines one at 36.7 Hz and the other one at 331.9 Hz back on. We ramped it slowly to avoid any lock loss but we still saw some drop in the range. We left the higher frequency line at 1083.7 Hz off for now. We will turn this back on during the comissioning period or next lockloss opportunity.

Attached is a trend of  Optical Follower Servo error signal showing when the lines got turned off.  (around 2015-08-21 07:20:00 UTC)

Images attached to this comment
laura.nuttall@LIGO.ORG - 13:54, Friday 21 August 2015 (20754)

Are we meant to be able to see the PCal lines in the normalised spectrogram of DARM? You can see them disappear and turn on again at about the times you mention, see the first plot (this is GDS strain). Also PCal End Y doesn't look so happy, see second plot. Plots were taken from the PCal part of the summary pages

Images attached to this comment
sudarshan.karki@LIGO.ORG - 14:47, Friday 21 August 2015 (20759)

Yes, Pcal line are supposed to appear in h(t).

Also, the third line at 1083.7 Hz is turned back on after the lockloss.

corey.gray@LIGO.ORG - 22:43, Friday 21 August 2015 (20773)

What's the best way for Operators to confirm whether PCal (and DARM) Cal Lines are present?  (seeing Excitation on CDS Overview?  looking for lines on DARM spectra?  Navigating to Calibration Line medms?)

Let us know and we can put this in checklists for operators to check.

sudarshan.karki@LIGO.ORG - 15:47, Sunday 23 August 2015 (20804)

I made  a DTT template which has all the calibration lines  on it. May be we can arrange to display this on the screen (A screenshot is attached.).  The template sits on the following location.

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/Templates/ Calibration_line_template.xml

The other way  is to head to PCAL medm screen and look at the OFSPD plot on the screen. If there is no excitation this plot should be flat.

Images attached to this comment
H1 DetChar (DetChar, PEM)
nutsinee.kijbunchoo@LIGO.ORG - posted 14:58, Thursday 20 August 2015 - last comment - 13:36, Sunday 23 August 2015(20717)
Site Anthropogenic Noise Injection Follow up

This is a follow up analysis of Robert's anthropogenic noise injections on August 12th. So far I don't see any convinving evidence that these activities were actually coupled into DARM. There were couple of injections ("human in optics lab" and "jumping in the change room") that seemed to coincide with DARM noise around 20-100Hz but it was unclear whether those injections were actually causing the noise. The noise *blobs* started prior to the injection and the PEM seismic sensor only coincided with one of them. Plus I would expect to see a coupling at much lower frequency if human jumping up and down the change room actually injects noise into DARM.

 

Note that the first injection time (15:05) is still unconfirmed. The time in the original table was wrong.

Images attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 09:55, Friday 21 August 2015 (20738)SEI, SUS
Adding SUS and SEI tags so I can locate entry.
Seems like good news for the isolation crowd. 
(I note that just because a coupling only happens > 10 Hz does note mean SUS and SEI are off the hook. Robert and Anamaria have shown that loud drive at > 100 Hz can couple into HAM6 optics. So I would say this knocks SEISUS off the top of the list, but not off the list completely.)
robert.schofield@LIGO.ORG - 12:34, Friday 21 August 2015 (20748)

Most injections lasted about 1s so the time series used for each tile should be about that long. These look like averages of time stretches almost an order of magnitude longer. I'll bet the signals will be more obvious if you zoom in in time on the individual injections instead of trying to see all 1s events in a singe 30 minute spectrogram.

nutsinee.kijbunchoo@LIGO.ORG - 13:36, Sunday 23 August 2015 (20799)SEI, SUS

I can see the injected signal clearly after I zoomed in. Below are the spectrograms for the truck horn injection. The signal can't be seen in the PEM-CS_MIC_LVEA_VERTEX channel. I'm working on the rest.

Images attached to this comment
H1 ISC (ISC)
hang.yu@LIGO.ORG - posted 11:37, Friday 24 July 2015 - last comment - 14:32, Sunday 23 August 2015(19904)
Estimation of beam position

Kiwamu, Hang

We did an estimation of the beam position on test masses based on the a2l gains that gave us best decoupling.

The result was shown in the first image attached. The blue line indicated the boundary of L3 and the red spot the position of the beam on the test mass. It seemed that the beams were <~1 cm off center.

  Trans. [mm] Vert. [mm]
ITMX 3.0 -7.3
ITMY -6.3 -3.5
ETMX 5.3 -4.7
ETMY -2.7 4.1

===================================================================================================================================

In case that you are interested in how we obtain the results:

The basic idea is to excite the pitch (yaw) motion of L2 stage, and let this excitation go through both

1): the L2->L3 P2P (Y2Y) path, and

2): L2->L2 P2L, and then L2->L3 L2L and L2P.

The ratio of L3's L over L3's P will then give us the vertical position of the beam on test masses. See the second picture for a graphic representation.

===================================================================================================================================

The code to re-run this analysis is available at:

/opt/rtcds/userapps/release/isc/h1/scripts/a2l

You can do the analysis by entering

./run_GrabBeamSpot.sh

in the command line

Images attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 14:32, Sunday 23 August 2015 (20802)SUS

But isn't there a static component of L2P -> L3L that we have to worry about? If there is something like that it seems like it would be static, but it might shift the absolute beam position by some amount.

Displaying reports 58161-58180 of 78430.Go to page Start 2905 2906 2907 2908 2909 2910 2911 2912 2913 End