Added 296 channels. Removed 8 channels. (changes attached)

(Keita Daniel)

We installed the amplitude stabilized RF EOM driver in the PSL. In the process the phase of the 9.1MHz modulation signal flipped by 179.3°. The measured RF power was 16.7dBm which requires H1:LSC-MOD_RF9_AM_RFSET to be set to 16.8dB.

The new controls/DAQ cables were used for both the 9.1MHz and 45.5MHz units. For the 9.1MHz unit we are using H1:ISC-430 (DB9/DAQ) and H1:ISC-432 (DB25/ctrl), whereas the 45.5MHz unit is using H1:ISC-431 (DAQ) and H1:ISC-433 (ctrl), respectively. The old cables have been pulled out of the PSL enclosure.

The RF readbacks of the 9.1MHz are currently shwoing around 18.3dBm. This is a calibration error which needs to be corrected in TwinCAT.

(All time in UTC)

15:20 Chris S. to X-arm (150 yards from corner station)

16:04 Jeff B. to Y end (Test Dust Monitor)

16:17 Let pest control in

16:30 Transitioned LVEA to LASER SAFE. Bubba to LVEA.

16:35 Joe escorting pest control through LVEA and VEAs.

16:37 Richard + Calos was up on the roof, not anymore (WP5743)

16:50 Hugh to both end stations (HEPI pump maintenance)

17:00 GRB/Supernova alarm

17:07 Brought MC1 and MC3 to SAFE for Richard's work

17:15 Bubba out of LVEA

17:29 Carlos rebooting NUC machines

17:30 Jim rebooting Guardian machine

17:42 Rick to PSL enclosure

17:47 Hugh back

          Let Hanford fire dept. in -- to X arm

17:52 Richard going on the roof

           Guardian restart seems to be completed but all the HPI have 'CODE ERROR'. Can't be cleared with LOAD or by restarting Guardian.

18:02 Joe and pest control done in all the VEAs.

18:10 Another Hanford fire dept. came to do some testing.

18:19 Jeff B. back from EX

18:27 Rick left the laser room in the "commissioning" mode

18:30 PRM, PR3 to SAFE. Put MC1 and MC3 back to SAFE.

           Bubba closing GV5, GV7 for heavy crane work.

18:38 Richard back to LVEA

18:43 Rick done

18:49 Dave restarting ISC node Guardian

19:06 Dick to Electronics rack by PSL.

19:41 Dave rebooting Guardian machine

19:53 Dave done

            Bubba out of the LVEA. GVs are opened.

19:54 Pest control done everywhere.

20:25 Keita and Daniel out of PSL. Going back after lunch.

20:40 Richard done for now. Put PRM, PR3, MC1 and MC3 back to ALIGNED

20:47 Let another fire dept. in.

21:03 Karen and Christina back to LVEA + open rollup door.

21:04 More fire dept. in. Joe taking them to EX and EY.

21:05 Keita's going back to the floor.

21:22 Richard going back out on the floor. Putting PR3, IM1, IM2, IM3, IM4 to SAFE

21:29 Bubba out to do more crane work.

22:39 Bubba out.

22:55 Richard done.

23:22 Let a delivery truck in And sent them back out to LSB.

23:58 Joe done escorting fire dept at VEAs.

00:00 IM3 WD tripped. After untripped there's no counts going out. Richard is working on it. Hand off to TJ

Replaced our aging NTP server with an new unit that has the ability to provide more protocols.  New Antenna on roof also.

Per work permit 5741 began the process of modifying all Suspension Satellite Amplifiers.  Drawing D0901284-v4 calls for the addition of Cap C601(10uF) and C602 (.1uF) between the -17V to Ground around U503 the Negative Regulator VEE1.
Today with Ed M. Soldering away in the lab we were able to complete all of Han2 units.
Complete are:
MC1, MC3, PRM, PR3, MMT1, MMT2, SM1, SM2  All Stages.

We did have a problem with two Sat Amps. One shared between MC1 and MC3 and the one for  MMT2,a trace blew when it was powered up.  So replaced SN 1100117 with SN S1000287 and SN1100068 with SN1100066.

Peter Shawhan, Carlos, Jim, Dave:

FRS4412, WP5740

Summary of problem, IERS (international earth rotation and reference systems) web page which announces future leap seconds addtions to UTC (called the Bulletin C page http://www.iers.org/SharedDocs/News/EN/BulletinC.html) was being accessed by LHO CDS several times per second. 

We had two problems: h1hwinj1 machine accessing the web page every 10 seconds, h1guardian0 machine accessing the web page on average several times per second. In both cases it was a non-bash-shell process calling the tconvert program.

tcleaps.txt data file

A new location outside of the apps area is now used to hold the tcleaps.txt datafile which provides tconvert with the history of leap seconds. The new location is /ligo/data/tcleaps/tcleaps.txt. This directory is referenced by the environment variable TCLEAPSDIR.

h1hwinj1:

Fix was to change the standard environment as defined by the files /ligo/cdscfg/lho/h1/stddir_linux.sh and stdrc_linux.sh. Rebooted h1hwinj1 machine.

h1guardian0:

Guardian nodes call tconvert via the cdsutils-gpstime utility. Fix was to change /ligo/apps/linux-x86_64/cdsutils/etc/cdsutils-user-env.sh. Rebooted h1guardian0 machine.

Verification:

Before and after the changes we ran tcpdump on the main CDS NAT router to verify web access to the Bulletin C page went from several per second to zero. During normal operation, this web page should only be accessed twice a year.

This morning I closed GV 5 & 7 so I could crane the snorkel lift over the Y beam tube in the LVEA. Valve closure and opening times are as follows: GV5 closed @ 10:34 PT GV7 closed @ 10:36 PT. GV 5 opened @ 11:24 PT and GV 7 opened @ 11:26 PT.

DaveB restarted the guardian computer to correct a tconvert issue, WP 5740.

After this, every HEPI platform guardian reports this error:

2016-02-23T17:52:24.50084 HPI_HAM1 [ROBUST_ISOLATED.enter]
2016-02-23T17:52:24.57873 HPI_HAM1 W: Traceback (most recent call last):
2016-02-23T17:52:24.57874   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2016-02-23T17:52:24.57875     retval = statefunc()
2016-02-23T17:52:24.57875   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57876     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57876   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57877     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57877   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57878     return func(*args, **kwargs)
2016-02-23T17:52:24.57878   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57879     return func(*args, **kwargs)
2016-02-23T17:52:24.57879   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57880     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57880   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57881     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57882   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/states.py", line 490, in run
2016-02-23T17:52:24.57882     if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (self.has_requested_gs13_gain_switch == False) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):
2016-02-23T17:52:24.57883 KeyError: 'SWITCH_GS13_GAIN'
2016-02-23T17:52:24.57883
2016-02-23T17:52:24.57888 HPI_HAM1 [ROBUST_ISOLATED.run] USERMSG: USER CODE ERROR (see log)
2016-02-23T17:52:24.62596 HPI_HAM1 ERROR in state ROBUST_ISOLATED: see log for more info (LOAD to reset)
 

I've reloaded and restarted both HAM1 and HAM6 and the error returns.  It sure looks like it is related to the updates to get the ISI guardian to switch the GS13 gains depending on the state.  I can not find documentation (logs) that the HPI nodes have been restarted since the gain switching updates which were intended for the ISI.

I've elected to not attempt any code corrections at this time; I suspect Hugo will correct this easily.  Meanwhile, I don't know if the guardian will actually function if it trips.  This can be done easily however with the command scripts isolating to level1.

Attached are 7 day pitch, yaw, and sum trends for all active H1 optical levers.  Closing FAMIS #4393.

Notes:

• ETMy YAW has been trending down over the last 2 months (from around 0 to -7).  If +/- 10 is our zeroing no-go, we might have another 3-4 weeks until we get to -10 and will needt to re-zero the yaw for this oplev.

Planned outage for WP #5736 is complete (8AM-8:10AM Pacific). Optical taps were installed between LHO border router and our ISP.

FE watchdog was reset at 16:15UTC. 

FAMIS: https://ligo-wa.accruent.net/LB_Request_Update.asp?RequestID=3586

Den, Sheila, Evan

~> We tried reverting to the old QPD offsets (the ones we used throughout O1) for the soft loops and the PRM pointing loops. These seemed to make the recycling gain slightly worse, and did not improve the jitter coupling. This indicates that (as we had suspected) these offsets are no longer good to use.

~> We measured the 9 MHz oscillator phase noise coupling into DARM. This had been done previously (19911), but with a suspicious calibration and in a way that also drove the 45 MHz phase. This time, we used the OCXO to drive both the harmonic generator (bypassing the 9 MHz distribution amplifier) and to serve as a reference for an IFR/OCXO PLL with a >40 kHz bandwidth. The IFR is used to drive the 9 MHz distribution amplifier. The error point of the PLL was offset in order to maintain the relative time delay of the 9 MHz and 45 MHz signals. When we relocked, we found that the 18 MHz and 27 MHz signals had flipped sign, but otherwise the interferometer locked normally. However, there was a great excess of 45 MHz noise in DARM (worse even than before we installed the 9 MHz bandpass). Nevertheless, we were able to drive enough to see the effect of 9 MHz phase modulation in DARM. The coupling is roughly 2–4×10⁻⁶ mA/Hz above 100 Hz.

TITLE: 2/23 eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
QUICK SUMMARY: Commissioners doing their thing for my whole shift.

Log:

• 01:27 Kyle to MY for CP3 overfill
• 01:48 Kyle back
• 02:14 Evan to CER
• 02:30 Evan out
• 05:10 Evan, Sheila to CER
• 05:41 Evan, Sheila out
   

Following up on Andy's earlier posting and building on data-folding infrastructure 
he has been developing, Weigang Liu has tried folding the same three channels Andy examined, 
but folding daily and monthly over most of the O1 data set
(ignoring January data to avoid confusion from calibration / post-O1 studies).
Weigang sees similar behavior in each channel to what Andy found in a half-hour sample, 
but with some variations during the course of the run.

In brief, Weigang uses a Matlab script to read in full PEM data or observing-mode DARM-related channels,
folds it upon itself in 4-second intervals, computes an FFT of the folded data, excises unwanted
bands, then inverts the FFT to get a band-passed/low-passed/high=passed time series. Discontinuities
at starts of science segments are handled with a smooth ramping, and the 4-second intervals are
shifted by a half-second to avoid artifacts on integer-second boundaries due to the data processing.
All 4-second intervals are synchronized to be commensurate over gaps in data.

Attached below and linked here are summary plots for Sept-Dec 2015 for two magnetometer channels (40-Hz low-pass):
H1:PEM-EY_MAG_EBAY_SUSRACK_QUAD_SUM_DQ
H1:PEM-EY_MAG_EBAY_SEISRACK_QUAD_SUM_DQ
and a summary plot for Sept-Dec 2015 for the DARM-related suspensions channel (10-50 Hz band-pass):
H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ

Corresponding monthly and daily plots can be found by drilling down at these links:
H1:PEM-EY_MAG_EBAY_SUSRACK_QUAD_SUM_DQ
H1:PEM-EY_MAG_EBAY_SEISRACK_QUAD_SUM_DQ
H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ

I have subtracted  SRCL coupling from DARM, and found that residual noise has the shape of 1/f^4-5 at 15-30Hz. I remember when L2 was in acquire state we could see actuator noise in this frequecy band in DARM. For this reason I decided to look into L2 noise again even though actuators are in the low noise (state 3) during current locks.

All 16 actuators show similar noise levels. Attached plot shows spectra for one of them (ITMX LL) in different states. When there is no control signal, actuator noise in low noise state is a factor of 10 smaller compared to acquire state in the frequency range 10-30Hz. However, if a small (few counts) low frequency excitation is applied, then actuator noise increases by a factor of 10. The noise increases almost by the same level if a large excitation is applied. I decided to check if upconversion happens in DAC, actuator or noise monitor. Control signal was shifted by a DC offset (10000 cnts) and actuator noise has reduced by a factor of 2-3. From this measurement one might conclude that DAC is responsible for extra noise. Also, we run oplev servo on the ITMs and even though control signal is aggressively low passed, actuator noise still increases above 10Hz.

Since L2 actuator noise depends on the low frequency control signal (or DC offset), then actuator noise may or may not be coherent to DARM at 10-30Hz. However, when we looked at DARM spectrum with bandwidth of 1Hz, we saw that noise goes up and down by a factor of 1.5 at 10-30Hz.

Den, Kiwamu, Evan

We continued investigations into locking robustness and low-frequency noise.

Notes on robustness:

>> Engaging the soft loops is still painful, particularly in yaw. When the loops are ramped up to their nominal gains (a few tens of millihertz bandwidth), the SRM yaw loop misaligns the SRM in yaw, which causes POP90 to rise and causes lockloss after about 1 minute. If the SRM yaw loop is turned off, this misalignment does not occur. So far, the most reliable way to engage the ASC is to (1) engage the soft loops with the −20 dB filters, and let them run for a few minutes, (2) turn off the SRM yaw loop, (3) turn off the −20 dB filters in the soft loops, and then (4) once the soft loop error points have reached 0, turn the SRM yaw loop back on. This has not been added to the guardian.

>> Den retuned the PR2 actuator feedforward which decouples MICH from PRCL, but this has not been added to the guardian yet.

Notes on noise:

>> Similar to yesterday's frequency noise test, we injected high-frequency noise into the ISS first-loop error point. We drove several volts (both sine waves and broadband noise) up to 10 MHz, but we did not see any nonlinear coupling.

>> As noted previously, the input jitter coupling into DARM is worse than before, particularly in pitch. Den opened the SRM angular loops and moved SRM to minimize the coupling. However, this seemed to make the noise worse in other places. In particular, the region from 35 Hz to 70 Hz swas dominated by some kind of nonstationary excess (perhaps scattering in HAM6). Also, there appeared to be a slight excess frequency noise above 5 kHz.

>> We drove the ITM ring heaters (upper and lower) in common-mode in order to measure the voltage-to-displacement coupling in DARM. By driving a few lines at 250 mVpk between 80 and 160 Hz, we could see that the coupling goes like 1/f². The levels at 160 Hz are as follows:

>> We flipped the sign of the DARM offset. Normally we run with the X arm shorter than the Y arm (i.e., a positive offset is applied at the DARM error point, and DARM is Lx − Ly); so here we are running with X arm longer than Y arm. This is achieved with the ISC_LOCK paramter lscparams.omc_sign that is applied at the appropriate points during the dc readout handoff. The sign of the SRCL feedforward also has to be flipped, and the SRCL FF filters that we normally use cause some 1 Hz instability that unlocks the interferometer. We installed a more aggressive AC coupling filter (FM8), and this solved the issue. DARM has a small amount of excess noise with this new offset, but the SRCL coherence does not seemed to have changed much after FF retuning. Good time to look at is 2016-02-21 21:44:40 (bruco).

Yesterday, I switch the HAM3 ISI to use the "HAM5" STS (now, actually in the biergarten), did an initial measurement to make sure the ISI was performing okay, then left it overnight. This morning I compared it's performance to HAM2, and I think we should switch all of the ISIs to used this seismometer. Attached 3 spectra show the GS13 spectra for X,Y and Z over a ~1 hour period overnight. In all DOF's over most frequencies, HAM3 does better than HAM2 now, where previously they had performed similarly (excepting HAM3's transient .6hz mystery line). Most important, HAM3 does much better where sensor correction gets us most of our isolation (~.1-1hz). This is an easy change, and should be totally transparent.