By Terra's request I have added a new button on the PI main screen that will launch a matlab script to plot the spectrum from 32758-32768Hz. Matlab has to be used because DTT cannot plot frequencies that close to the Nyquist Frequency, and python cannot be used because the Ubunutu machines have an old version of scipy without the welch function. The Debian machines do have an up-to-date version of scipy but operators use both machines. This is NOT a live spectrum, and should be used only to reference at what frequencies the modes are at. Continue to use the StripTools to monitor these PIs in real time.

A few notes:

• It can sometimes take around 50seconds before the plot is fully displayed.
• If it failed to get data from the nds, try again. It isn't always reliable for reasons that I am trying to figure out.

Example output attached.

I have switched the model's which have identical safe and OBSERVE files to OBSERVE as part of the transition of all to OBSERVE. When this is complete, any model mistakengly in safe will stand out as out-of-configuration.

Models switched: ngn, odcmaster, pemmx, pemmy, psldbb, pslfss, pslpmc, susauxasc0, sushtts, susim, susmc1, susmc3, susomc, sussr2

The full report can be found on the detchar wiki: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20170213


Below I summarise the main highlights of this shift:

- The duty cycle was 57.6 hours (79.9%). The range was between 65-75Mpc.
- The line around 500Hz likely due to fundamental violin modes, which has been seen since the beginning of the DQ shift. And the bounce and roll mode seen after locklossm which is also typical behavior seen in LHO over the DQ shift.
- GDS calibration accuracy has been decreasing between 50 - 200Hz since this year
- Range dips at 03:52UTC, at11:58UTC, at22:31UTC and at 23:25 UTC are all in type3 in PCAT. I follow them up with omegascans, they are due to ETMY saturations in H1:FEC-98_DAC_OVERFLOW_ACC_3_1 [7], and they show in ETMY magnetometer,PEM-EY_MAG_EBAY_SUSRACK
- On 15th H1:LSC-X_ARM_CTRL [1] showd continuously during 10:39 - 18:04

12:43UTC Lockloss. Nothing in BLRMS. Nothing in Tidal. Nothing else apparent

• First attempt: OMC did not lock. After some prodding I got it to lock but upon DC Readout the OMC DCPD saturated and the lock was lost. 
• Second attempt: Find IR failed and lock was lost.
  • IMC wouldn't stay locked so I cleared WFS history and let it re-center itself
• Third Attempt: Locking went well through the past two issues.
  • At DC Readout ETMX RMS WD tripped - UL. I reset and let IFO stay at DC readout for a bit for stability.

13:54 NLN

• Strange - seems as if noise tunings weren't run. Bounce/Roll/Violin (f1) and 4.753Hz all rung fairly high.
  • damping Bounce Mode. Roll modes seem to have calmed down. Violins will come down on their own eventually. 4.7K mode damping down
• a2l passive measurement shows alignment bad in PIT. Running a2l script
• Accepted ETMX and ITMY damping gain changes in SDF for Bounce
• Accepted ITMX damping gain for Roll Mode in SDF

14:23 Set Observatory Mode to Observing - Set Intention bit to Undisturbed.

Nothing to report. Locked for 17Hr33Min coincidental w/LLO

TITLE: 02/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: In observing the entire shift. It appears that the anemometers on all the weather stations except end X may have frozen in place? No other issues to report.

Sheila, Keita and Robert have left. Still in observing. No issues to report.

When H1 is in observation mode, there are 23 models which are using their safe.snap target file for their SDF reference. All others are using their OBSERVE.snap file.

Of the ones using safe.snap, they fall into three catagories:

1. safe.snap and OBSERVE.snap are symbolic links to the same file in userapps

2. safe.snap and OBSERVE.snap are symbolic links to separate fies in userapps, but these files are identical to each other

3. safe.snap and OBSERVE.snap are symbolic links to separate files in userapps, and these files differ from each other

systems in catagory 1 and 2 can be switched from safe to OBSERVE with notoperational difference (although category 2 systems should ideally  be converted to category 1).

systems in catagory 3 will need some work to make safe and OBSERVER be the same.

Category 1:

h1ngn, h1odcmaster, h1pemmx, h1pemmy, h1psldbb, h1pslfss, h1pslpmc, h1sushtts, h1susim, h1susmc1, h1susmc3, h1susomc, h1sussr2

Category 2:

h1susauxasc0

Category 3:

h1calex, h1oaf, h1pmcpi, h1susauxb123, h1susauxex, h1susauxey, h1susauxh2, h1susauxh34, h1susauxh56

TJ and I were surprised that guardian switches some suspensions to OBSERVE (e.g. MC2) but skips others (e.g. MC1, MC3). TJ is looking into the  isc/h1/guardian/All_SDF_observe.sh which does this switching.

TITLE: 02/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.44 μm/s 
QUICK SUMMARY:

H1ASC is showing a configuration change on the CDS overview. Sheila says this is from filter modules added for the bulls eye sensor.

TITLE: 02/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC

STATE of H1: Observing at 62Mpc

INCOMING OPERATOR: Patrick

SHIFT SUMMARY: Not much. One lockloss. No issue recovering.

LOG:

18:07 Richard+Fil to LVEA by the PSL enclosure

          Kyle to LVEA to replace fuse vac

18:10 Hugh pulling controller box from HAM2 STS2

18:13 Hugh out

18:19 Richard out, going to CER

          Kyle out

18:26 Richard+Fil out

19:19 Karen and Christina pulling a vehicle by the roll up door.

(Duo, Nelson, Orion, Vladimir, Keith)

This is old news (going back to ER6 and ER7), but with lower-frequency lines improved since O1,
we are looking harder at the disturbances seen in both H1 and L1 DARM very near 100 Hz.
In both interferometers one sees lines / combs extremely near 100 Hz and several visible harmonics:

Computing average spectra of 30-minute Hann-windowned FScan SFTs from about the first two months of O2 data,
I see the following lines / combs:

H1: 

99.9762 Hz (visible to 2nd harmonic)
99.9989 Hz (visible to 5th harmonic)

L1:

99.9728 Hz (visible to 2nd harmonic)
99.9755 Hz (visible to 2nd harmonic)
99.9780 Hz (visible to 2nd harmonic) 
100.0000 Hz (visible to 2nd harmonic)

Having lines show up in both H1 and L1 so near 99.98 Hz has led to
spurious outliers in O1 CW all-sky searches and will likely do so again
for O2 searches. 

NoEMi shows correlations between DARM and end-station magnetometers.
Duo Tao followed up these clues for O1 H1 and L1 and more recently for O2 H1 and L1
with week-by-week coherences between DARM and auxiliary channels.
The lines near 99.98 Hz are seen in many magnetometer, suspension (and sometimes even accelerometer
channels) at both end stations at both LHO and LLO.

Given the prevalence of these lines in so many different types of channels, 
it's natural to suspect electronic coupling. Are there known power supply combs 
with ~100 Hz spacing? I see this LLO alog entry from Anamaria, which mentions
some 100-Hz detective work (and documents a dramatic mitigation of a 2.24-Hz comb).
Is there a better understanding of the 100-Hz artifact(s)? At either observatory?

Figugre -- Zoom of DARM for 100-Hz region, showing arithmetic and inverse-noise-weighted averaged spectra from H1 and L1 for December and January together

Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 455 seconds. LLCV set back to 14.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 89 seconds. LLCV set back to 34.0% open.

WP 6488

To test the host box as the source of the problem on the EndY PEM STS mounted with the BRS, we switched the HAM1 HEPI Z sensor correction around 10am when the IFO brock lock. This is the only platform and DOF using the HAM2 STS.  This has been the configuration since 14 Nov 2016, but Jim does not nelieve this switch from the ITMY seismometer made any improvement in the HAM1 isolation.  The sensor correction is directed to the IPS and the crossover to roll the IPS out of the blend is 700mHz.  The HAM2 and the ITMY STSs show unity TF and 0 phase below about 2 Hz, see attached.  Meanwhile the HAM2 GND STS is off and the Host Box is pulled; cables remain.

I'll post some performance metrics before and after.  Once we are sure the performance is not compromised, I'll switch the Host Box at EndY to see if the Glitching is corrected.

~1805 - 1818 UTC -> Kyle in and out of LVEA 

(see also entry 34166)

Sure enough!  Fuse supplying pwr to CP1's LLCV was blown (cable XV100, terminal #171).  It was a 1 amp -> I replaced with a 2 amp (have 1/4-20 bolt at the ready, just in case;)

Sheila, Jenne, Mark, Richard, Fil, Daniel

We made some progress on installing a prototype of the bullseye detector that Mark has been building in the PSL today. 

• Jenne and I went into the PSL and realized that the location I ha orignally thought of for the diode wouldn't work.  After dicussing it with Jason we deicded to move aside the beam profiler in the DBB HPO path and put the diode there.  There was about 0.65 mW of power in this path.  Jenne added a steering mirror (Y1) and a diverging lens (PLCC-25.4-103.0-UV-1064).  To install the diode we had to remove the rail that was on the table, we placed it on the portable cart on the oposite side of the enclosure. 
• We used a temporary adapter cable that Mark made that allows us to power the diode from the power strips under the table and get the signals out onto a DB9.  We used a breakout board to display the segments on a scope while we were in the enclousre.  Based on watching the signals while we steered the beam around, we think that the segments are arranged like this:
  • pin1 pin6 (seg 1) side of the diode closer to the anteroom
  • pin 2 pin 7 (seg 2) center
  • pin 3 pin 8 (seg 3) side of diode closer to HAM1
  • pin 4 pin 9 (seg4) bottom of diode
• We decided to use the unused half of the MC2 trans QPD whitening chassis for this diode.  Fil made an adapter cable that we could use to get the MC2 signals from the 25 pin Dsub from the transimpendance amplifier and the bullseye signals off the 9pin Dsub that comes out of the PSL into the whiteing chassis. (The 9 pin  cable reaches, but next time someone is in the PSL we could uncoil a little more from under the table). 
• The whitening chassis already had BIO, but there was no beckhoff code for the spare hardware.  Daneil added this, and named the whitening PSL-SPARE_QPD.  Dave did a DAQ restart for this change. 

We will hopefully get the whitened signals into the ADC channels that are already set aside and connected to AS_D in the ASC model tomorow. 

Attached is a list of the perl scripts under /opt/rtcds/userapps/release/ at LHO. Their creation date is also shown. 

ECR E1700056 approves migrating these to python if and when applicable.