TITLE: 10/05 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC STATE Of H1: Observing, ~75 MPc SHIFT SUMMARY: Remained locked in observing for entire shift. A few SUS ETMY glitches. INCOMING OPERATOR: Corey ACTIVITY LOG: 07:54 - 07:59 UTC Stepped out of control room. SUS E_T_M_Y saturating (Mon Oct 5 8:52:2 UTC) SUS E_T_M_Y saturating (Mon Oct 5 8:52:4 UTC) SUS E_T_M_Y saturating (Mon Oct 5 14:56:49 UTC)
The SSD RAID has failed on h1tw0, so the trend writer has been halted. This will affect the ability of h1nds0 to get recent raw minute trend data.
Still locked in observing at ~ 78Mpc. A couple of SUS ETMY saturations.
TITLE: 10/05 [OWL Shift]: 07:00-15:00 UTC (00:00-08:00 PDT), all times posted in UTC STATE Of H1: Observing @ ~ 78 MPc. OUTGOING OPERATOR: Cheryl QUICK SUMMARY: From the cameras the lights are off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell if they are off at mid Y. Seismic in 0.03 - 0.1 Hz band is around .015 um/s. Seismic in 0.1 - 0.3 Hz band is around .1 um/s. Winds are less than 5 mph. I noticed on the CDS DAQ Overview that tw0 restarted itself. I see that Corey noted this occurring on his shift as well.
TITLE: EVE Shift, Oct 4th-5th, 23:00:00UTC to 07:00:00UTC, 16:00PT-00:00PT.
STATE OF H1: locked since yesterday, 77Mpc
SUPPORT: MikeL
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: quiet
IFO Activity:
Intention Bit: Undisturbed (Sun Oct 4 21:1:58 UTC)
SUS E_T_M_Y saturating (Sun Oct 4 21:22:44 UTC)
SUS E_T_M_Y saturating (Sun Oct 4 21:37:16 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 0:18:31 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 0:57:11 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 2:30:11 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 4:23:13 UTC)
SUS E_T_M_Y saturating (Sun Oct 5 4:34:1 UTC)
TITLE: 10/4 DAY Shift: 15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC
STATE OF H1: In Observation Mode at 72Mpc
SUPPORT: Vinny, Robert
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Quiet shift with only small a small break for PEM injections.
Shift Activities:
Raw minute-trend writer, h1tw0, has been popping up medm message windows warning of "virtual circuit disconnects" (and h1tw0 boxes on the DAQ Detail go WHITE for a few seconds every few minutes).
LLO has had a GraceDB querying Failure for last few shifts/days.
Want to reiterate importance of contacting them whenever we receive an Alert on VerbalAlarms. The Alert/Trigger Site Response Checklist (L1500117), laminated at the Ops Work Station, states operator at each site must contact each the other to confirm they received the alarm (current state [LLO GraceDB Failure] is an example of the importance of this step).
Received GRB Alert at 18:11UTC. Going through the checklist (L1500117).
Yesterday when taking H1 to Observation Mode, Evan & I noticed a RED SDF on video0 (I think it was for PEMEX or EY), but we did not see it on our SDF screens on our work stations. I reopened the SDF and the RED went away. The medm was not frozen, because we were Accepting channels & it would go green before noticing this errant PEM RED. Just thought it was something interesting.
TITLE: 10/4 DAY Shift: 15:00-23:00UTC (00:00-8:00PDT), all times posted in UTC
STATE of H1: Observation Mode with Avg of 74Mpc
Outgoing Operator: JimW
Support: Vinny
Quick Summary: useism continues a slow trend down (at about 0.15um/sec). Winds hovering around 12mph.
Terramon has just come up with a RED warning of a 5.6 Peruvian earthquake who's Rayleigh wave is due here in a minute (0.7um/s), due at 15:30:38UTC. We'll see what happens.
L1 just went down at 15:30. Terramon said the EQ's Rayleigh waves (of 1.4um/s) would arrive there at 15:17UTC.
So we might not be out of the woods yet...watching 0.03-0.1Hz (all three axis have yet to move up at the same time and all are still under 0.1um/s...I've seen us drop out when all three go above that velocity...but that was a few weeks ago before the DHARD filter).
No signs of anything on tidal or ASC control strip tools either.
It's been 15min since the R-wave arrival estimate, I'm assuming we rode through the EQ. (it was barely observable in here on seismic bands, range, striptools). Time to make breakfast/coffee.
Title: 10/3 OWL Shift 7:00-15:00 UTC
State of H1: Low noise, observing 75 mpc
Shift Summary: Quiet night
Activity log:
Nothing happened. Quiet night, Corey's lock from yesterday made it through the night.
Quiet night at LHO. Wind ~10mph, seimic relatively low, lock from yesterday continues.
TITLE: 10/3 EVE Shift: 23:00-07:00UTC (Oct.4) (16:00-23:59PT), all times posted in UTC
STATE OF H1: Observation at 77Mpc
SUPPORT: Robert, Jordan, Sheila
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
LLO is still having issues with useism.
Robert did one round of injections, and produced many ETMY saturations in 2 minutes - he may need to redo this measurement tomorrow night.
Jordan did one PEM measurement and would like to take another. The first was about 30 minutes and the second should be about this long as well.
Shift Activities:
00:00:42UTC, Oct. 4th - Robert's PEM injections start
01:34:37UTC - Robert's PEM injections end
03:35:37UTC - Jordan's PEM injections start
04:06:47UTC - Jordan's PEM injections end
I started to look at our locking attempts over the last two weeks, especially trying to understand our difficulty yesterday. I will write a more complete alog in the next few days, but I wanted to put this one in early so that operators can see it.
We've known for a long time that at LLO they always pull the OMC off resonance durring the CARM offset reduction, and they've told us that they can't lock if it is flashing. We know that we can lock when it is flashing here, which might be because our output faraday has better isolation.
In the two weeks of data that I looked at, we've locked DRMI 64 times, 33 of these locks resulted in low noise locks and 31 of them failed durring the acquistion prodecure. Of these 31 failures, about 9 happened as the OMC was flashing. We also had about 12 sucsesfull locking attempts where the OMC flashed. OMC flashing probably wasn't our main problem yesterday, but it can't hurt and it might help to pull the OMC off resonance durring the CARM offset reduction.
Operators: If you see that the OMC is flashing (visible on the OMC trans camera right under the AS camera on the center video screen) you can pull it off resonance by opening the OMC control screen, and moving the PZT offset slider which is in the upper right hand quadrant of the screen. Even if you don't see the OMC flashing on the camera it might not hurt to pull the PZT away from the offset it is left at, which was the offset where it was locked in the last lock. I will try to add this to guardian soon and let people know when I do.
screenshot with slider circled in a red dashed line
Evan Sheila
Here is a plot of the 24 locklosses we had from Sept 17th to Oct 2nd durring the early stages of the CARM offset reduction. The DCPD sum is shown in red while the black line shows H1:LSC-POPAIR_B_RF18_I_NORM (before the phase rotation) to help in identifying the lockloss time. You can see that in many of these locklosses the OMC was flashing right before for as we lost lock. This is probably because the AS port was flashing right before lockloss and the OMC is usually nearly on resonance.
We looked at 64 total locking attempts in which DRMI locked, 24 of these resulted locklosses in the early stages of CARM offset reduction (before the DHARD WFS are engaged). In 28 of these 64 attempts the OMC DCPD sum was above 0.3mA sometime before we start locking the OMC, so the OMC flashed in 44% of our attempts. We lost lock 16 out of 18 times that the OMC was flashing (57% of time) and 8 out of 36 times that the OMC was not flashing (22% of the time).
We will make the guardian pull the OMC off resonance before starting the acquisition sequence durring tomorow's maintence window.
We've both restarted our sessions on TeamSpeak (I rebooted computer since ours would not allow me to open anything. Upon reboot, TeamSpeak opened automatically [thanks, Ryan!].). We are both now re-connected.