ALL TIMES IN UTC
Science Mode Checklist: (beginning of shift)
Guardian: NOMINAL_LOW_NOISE
Inspiral Range: 62Mpc
LVEA Sweep: N/A
Ops Overview: Clean and Green (except for the beam diverter caveat)
CDS Overview: Green except for Cal injections
SDF Overview: All Diffs cleared except for SUSPRM, OMC and CALCS.
SYS DIAG: the usual BRS message
Calibration Lines: Calibrations are running.
ODC Master Observation Ready Bit: GREEN
Observation Intent Bit: UNDISTURBED
Ops Observatory Mode: Observing
Activity Log:
12:10 EY .3µ Dust Alarm Major
12:21 EY .3µ Dust Alarm Major
12:22 Set the Observation mode to ‘Environment’ while the earthquake settles down
12:26 Christina on site
12:26 Muted annoying EY dust monitor alarm
12:45 Took ISC_LOCK to down while Z-axis settles. Incessant OMC DCPD saturation Verbal Alarm after Lockloss and OMC still flashing. I called Evan and he instructed me to slide the ‘OFFSET’ slider in the OMC CONTROL Screen to the left a bit until the flashing stops. Guardian will touch this again when it’s time for locking. Verbal Alarm for this should be addressed as it was sounding excessively for an innocuous event according to Evan.
LOCK LOG:
11:42 IFO Locked at NLN. Range ~62Mpc.
11:59 Observation Intent Bit and Observatory Mode set
12:07 Lockloss. There appears to be a mag 5 earthquake in the North Pacific off the coast of Russia
12:08 Begin locking sequence
DRMI - may take a while. mag 5 quake N Pacific/Russia
DRMI 1F locked after 15 minutes but came unlocked. I’m pretty sure it was the earthquake now
12:32 DRMI LOCKED
12:32 Attempt to proceed failed
12:57 Begin sequence (EQ calming) we’ll shoot for DRMI for starters.
DRMI Locked 1F in about 2 minutes
13:02 Lockloss. Never made it to 3F.
13:03 Begin sequence
DRMI Locked 1 min
13:19 Locked at NOMINAL_LOW_NOISE. 62Mpc
13:28 Set OIB and OOM to Undisturbed/Observing
Shift Summary:
Most of the night was spent commissioning to resolve a problem with stability at “high” power.
locking resumed at 11:42UTC and went well until an earthquake off the coast of Russia shook things up for about 1.5 hours.
13:28UTC OIB and OOM set to Undisturbed/Observing
ALL TIMES IN UTC
Science Mode Checklist:
Guardian: NOMINAL_LOW_NOISE
Inspiral Range: 62Mpc
LVEA Sweep: N/A
Ops Overview: Clean and Green (except for the beam diverter caveat)
CDS Overview: Green except for Cal injections
SDF Overview: All Diffs cleared except for SUSPRM, OMC and CALCS.
SYS DIAG: the usual BRS message
Calibration Lines: Calibrations are running.
ODC Master Observation Ready Bit: GREEN
Observation Intent Bit: UNDISTURBED
Ops Observatory Mode: Observing
Activity Log:
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:
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:
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.
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)
Guardian: actively running lock sequence while commissioners are troubleshooting
Inspiral Range: N/A
LVEA Sweep: N/A
Ops Overview: In flux due to commissioning work
CDS Overview: mostly green except for the typical OVF errors and the Calibration Line Excitation
SDF Overview: Diffs showing on: SUSPRM, SUSSR3, LSC, ASC, OMC, ISCEX & ISCEY. Others are ODCX, ODCY and CALCS.
SYS DIAG: the usual BRS message
Calibration Lines: It appears that Calibrations Lines are running.
ODC Master Observation Ready Bit: RED
Observation Intent Bit: Commissioning
Ops Observatory Mode: Commissioning
Activity Log:
7:00 Evan and Sheila continuing work on ASC.
7:32 ETMX Dust Monitor giving Invalid Alarm
8:08 Refreshed the Operating mode FOMs
9:32 ETMX Dust Monitor giving Invalid Alarm
10:52 Still working on ASC issues
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.
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.
just to clarify, it was the UIM driver that needed to be reset
Plot attached shows SRCL goes at -30 seconds, then PRCL goes at -12 seconds.
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).
ETMX coils didn't actually die... it was the PUM driver, and it was reset...
Repairs planned for Tuesday Maintenance.
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.
ER8 Day 6. No restarts reported.
ER8 day 5. No restarts reported.
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.)
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.
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.
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.
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.
@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.
Sudarshan reports that a PCal line was turned off sometime last night. He is turning it back on at 17:53.
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)
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
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.
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.
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.
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.
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.)
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.
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.
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
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.
12:07 LockLoss.