Lockloss at 22:45 (14:45) due to 7.1 mag EQ in Southern Indian Ocean. Seismic is up to 2.5um/s and increasing. Have the IFO in a DOWN state until things settle down.  

   Good observing for first half of shift. Range is just over 80Mpc. Wind and seismic are OK. Microseism is still high but is starting to trend downward. 

The 0.25 Hz bandwidth coherence results between H1 and L1 as generated by stochmon (see Fig. 9)
https://ldas-jobs.ligo.caltech.edu/~thomas.callister/stochmonO1/stochmon.html
are showing a new peak at 24.75 Hz to 25.0 Hz.
The 0.1 Hz coherence results (Fig. 11) show finer structure with peaks at
24.9, 25.0 and 25.5 Hz.
Those coherence plots are also posted below.

Pat Meyers ran STAMP-PEM for H1 and L1 around these frequencies. For H1
https://ldas-jobs.ligo-wa.caltech.edu/~meyers/stamppem/results/HTML/11325/H1-GDS-CALIB_STRAIN-HTML-1132574417-3600-245-255.html
There was coherence to be seen at these frequencies with
lots of PEM-CS accelerometers/mics and then getting into the suspensions.

The STAMP-PEM results at L1 did not show anything interesting at these frequencies.
https://ldas-jobs.ligo-la.caltech.edu/~meyers/stamppem/results/HTML/11325/L1-GDS-CALIB_STRAIN-HTML-1132577658-359-245-255.html

Nathaniel Strauss ran the coherence tool over the data for the more recent O1 week using 1 mHz resolution. The full set of coherence tool results for the last O1 week for H1 can be found here:
https://ldas-jobs.ligo-wa.caltech.edu/~eric.coughlin/O1/LineSearch/H1_COH_1131753615_1132358415_SHORT_1_webpage/
Nathaniel found much structure in this 25 Hz region in tons of channels. His summary is here:
https://ldas-jobs.ligo-wa.caltech.edu/~nchriste/O1/noise_lines/25Hz/Lines_at_24-25_Hz.pdf

Keith Riles has speculated that for this observed H1-L1 coherence an H1 line at 24.9 Hz is getting tangled up with the L1 line at 24.82 Hz. He also notes that there are plentiful 1-Hz combs in both IFOs with various offsets from zero, including lines that appear at about 24.5 and 25.0 Hz. I am also posting spectrums that Keith made from H1 and L1 in that band from the first week of O1

Nelson, Nathaniel, Pat, Keith

Maybe obvious and I don't have a lot of detail; and, others have already shown (maybe indirectly) that the blends of the ISI impact the IMC.  But here is a coherence plot showing huge coherence between the ISI inertial X motion and IMC-F between 50 and 130mHz.  The blends here are the Quite_90s, I'll look to get some comparison when we run the 45mHz blends.

Checked all the ISI coil criver status bits for dropouts (these will no longer drop us out of lock (tripping the ISI WD) since 3 Nov.)  None showed any drops from good state.  I saved DV templates for these channels in /ligo/home/hugh.radkins/DataViewerTemps/ with names that should be obvious.  Maybe I'll set up a famis point to do this monthly.

In 23939 Evan pointed out low frequency glitches. These look very similar to the scattering glitches seen at LLO every day (there likely driven by OM suspension motion). I think these gltiches at LHO are probably related to SRM or PRM optic motion for a few reasons. 

Figures 1 and 2 show the SNR/Freq plots from hveto of Strain and Mich, respectively. These both show a relationship between amplitude and SNR that is what you expect for driven fringes/shelves sticking out farther above the noise, the higher frequency they are driven to. 

Figures 3 and 4 show omega scans of Strain and Mich showing pretty clear arches. The arches are stronger in Mich than in Strain (in terms of SNR). 

Figures 5 and 6 show the fringe frequency prediction based on the velocity of the PRM and SRM optics. The period is about right for both. The results for other optics are shown here. The code is here. And the scattering summary page for this day is here. The dominant velocity looks like about 0.15Hz judged by eye from the timeseries. 

Figure 7 shows that during the glitchy times (green and yellow) the SRM and PRM optics are moving more at about 0.12Hz (probably compatible with the largest velocity frequency above). There's also a pretty strong 0.6Hz resonance in PRM, but this is the same in good and bad times. 

Title:  12/04/2015, Evening Shift 16:00 – 00:00 (08:00 – 16:00) All times in UTC (PT)
	
State of H1: 08:00 (16:00), The IFO locked at NOMINAL_LOW_NOISE, 22.2w, 79Mpc.  

Outgoing Operator: Jim

Quick Summary:  IFO locked in Observing mode for the past 5.5 hours. Environmental conditions are mixed – wind is up to a light breeze (2-7mph), seismic activity is quiet. Microseism is still on the high side at 0.6um/s.     

The timing error on SUS ETM-Y has returned after Travis reset it last night. 

O1 days 76,77

model restarts logged for Thu 03/Dec/2015 No restarts reported

model restarts logged for Wed 02/Dec/2015 No restarts reported

The tail end of Travis' shift was plagued by higher winds on top of high microseism. Just as he was leaving the IFO was finally starting to catch DRMI. After he left I started having more luck, but the ISS has been stuborn all night so far, I've had to engage it twice by hand now. I would have had to do it a third time, but I broke the lock by trying to switch blends on ETMX. Currently that chamber alone is running the 90mhz blends because it was oscillating at 40mhz again. H1 seems to be doing okay with one chamber on the higher blends with the high microseism, although the ASC signals look like when we are running them everywhere. This maybe how we want to run ETMX until we can figure out what is going on with that ISI.

Title: 12/3 Eve Shift 0:00-8:00 UTC (16:00-24:00 PST).  All times in UTC.

State of H1: Lock acquisition

Shift Summary: Conditions for relocking aren't improving much.  Microseism is still high at 0.6 um/s and the wind is picking up at ~30 mph. 

Incoming operator: Jim

Activity log:

After the initial lockloss of my shift, and one short 20 min. lock stretch, I have been struggling to get very far (can't get PRMI to lock now).  I have done initial alignment twice for lack of other things to try (AS camera has looked poor after both alignments). 

3:10 reset TIM errors for H1SUSETMY and H1IOPASC0

Cause unknown at this time.

Microseism still ~0.6 um/s, but we're locked anyhow.

Evan G., Jeff K.

Jeff and I got to talking about the problematic 1 Hz comb (and associates) below 100 Hz, and he thought maybe we could have a look at the timing system because there are certainly a lot of 1 PPS signals running around. Our goal was to get a sense of the system and to see where we might start looking for anything broken or misbehaving (not that there is an obvious problem, but it is a place to start).

Summary:

We looked at channels on the timing comparitors to check out timing difference between the GPS signal from the master/fanout with comparitors. The timing fanouts looks very stable aside from a small (~40 ns) shift at EY compared to the EY Symmetricom GPS antenna after a power outage. Another comparitor, the Time Code Converter (TCT), shows a constant, consistent drift at CS, EX, and EY. The timing difference currently for the TCT is around -1.6 us for CS, EX, and EY.

Details:

From the Timing MEDM screens we looked at the comparitor signals to understand the time difference. We had to verify where the cables were plugged in because it is not obvious from the MEDM screen. We used T070173 as a reference for the timing system. We made 60-day trends of the mean values for the different comparison values. Our legends are labeled as follows:

H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 = "Timing solutions flywheel vs timing master"
H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_2 = "Atomic clock? vs timing master"
H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_3 = "Symmetricom GPS Antenna vs timing master"
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 = "EX Time Code Converter (TCT) vs EX Timing Fanout"
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_3 = "EX Symmetricom GPS Antenna vs EX Timing Fanout"
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 = "EY Time Code Converter (TCT) vs EY Timing Fanout"
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_3 = "EY Symmetricom GPS Antenna vs EY Timing Fanout"

It appears that things are ok, but we are not sure at what values "we should get worried about this." The only other notable issue was looking at the MEDM screen, the channel H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_4 would periodically drop to zero and oscillate much more than any of the other channels. We do not know if this is a problem.

Most likely related to transmitted power drop reference in aLog 23941.

[Sheila, Jenne, Travis, JeffK, EvanH]

The transmitted powers through the IFO are dropping on a several-hour timescale, and we don't know why. It looks like this was also happening at the end of yesterday's 31 hour lock.  (POP_LF is shown for the last day or so in the attached plot.)  These are the only 2 locks in the last 10 days that have this trend - for all the others the powers stay nice and steady.

The power into the interferomter as measured by both IMC_Trans and IM4_Trans is steady, so it's not anything from the PSL or IMC. 

We have looked at all the alignment and length control signals that we can think of, as well as the witness channels on the bottoms of the optics, and we aren't seeing anything that jumps out at us as a cause of this power drop.

Intriguingly, the REFL power is dropping as well as the transmitted powers, so perhaps we're losing our mode matching throughout the lock?  Sheila found that the TCS CO2 power is different after Tuesday maintenence this week, although it's not changing throughout these locks.

Anyhow, we're not sure what is wrong, so we're not sure what we would tweak if we could, so we're leaving the IFO alone.  But, I suspect that once POP_LF gets down near 15,000 counts we'll lose this lock. 

Currently ~6m wave activity off the Pacific Northwest coast causing elevated microseism. Omicron glitch rate correspondingly rises, especially in the low frequency region. I attach an image showing microseism trend and Omicron glitchgram. Can we get clues to upconversion mechanisms from IFO data during this time?

An unnecessary trip of the ISI occurs everytime the complete platform is deisolated and then reisolated.

The model code keeps the T240 Saturations out of the watchdog bank for tripping the ISI when ever all the isolation gains are zero.  But if the T240s are riled up the Saturations still accumulate.  As soon as the T240 Monitor has alerted the Guardian that the T240 has settled and the Guardian then starts Isolating, the watchdog trips because the T240 saturations are too many.  This only trips the ISI and so the T240 does not get upset again, and after the operator has untripped the watchdog (clearing the saturations,) the ISI isolates fine.

It seems we missed this loophole, if the HEPI does not trip, the T240s often don't get too upset so it isn't a problem.  Otherwise, usually something is happening, EQ, platform restart, etc, and the operator (Jim & Me too) just untrip and chalk it up to whatever.

This should be fixed and I'm sure Jamie/Hugo will have some ideas but I suggest something like adding lines:

reset (push) H1:ISI-{platform}_SATCLEAR

wait 60+ seconds

after line 51 in .../guardian/isiguardianlib/isolation/states.py

ISSUEs: 1) The reset will clear all saturations, not just the T240s.  2) The wait is required because the Saturation bleed off code still has the bug of needing a bleed cycle to execute so any reset can take up to 60 seconds.  Wasted time not locking/observing.

Integration Issue #1163 filed