[Greg Mendell, Aaron Viets] The GDS calibration pipelines were restarted at GPS time 1176571587. The output, latency, and CPU usage looks as expected. The command line arguments and filters have not changed from last week, as the same filters and options will work with the older code.
Two maintenance items and one FAMIS task on the docket today: increase HPO pump diode currents and tweaking of the beam alignment into the PMC, and the weekly FAMIS PSL power watchdog reset. The following work was done with the ISS OFF.
HPO Pump Diode Currents
I increased the HPO pump diode currents and temperature tuned the diodes. A summary of the new and old pump diode currents is below in Table 1. Diode Box #1 continues to decay faster than the other 3 diode boxes. We want to replace an in-service diode box once its operating current exceeds 90% of its maximum. These DBs max out at 60A, so the target for replacement is 54A of operating current. Using this as a guideline, DB1 is beginning to get close to replacement.
| Operating Curent (A) | ||
| Old | New | |
| DB1 | 51.7 | 52.4 |
| DB2 | 51.5 | 51.9 |
| DB3 | 51.5 | 51.9 |
| DB4 | 51.5 | 51.9 |
Following this, I temperature tuned the diodes to maximize the output power of the HPO. A summary of the temperature changes is listed below in Table 2.
| Diode Box 1 (°C) | Diode Box 2 (°C) | Diode Box 3 (°C) | Diode Box 4 (°C) | |||||
| Old | New | Old | New | Old | New | Old | New | |
| D1 | 25.0 | 24.5 | 20.0 | 20.0 | 22.0 | 21.5 | 24.0 | 24.0 |
| D2 | 25.5 | 25.0 | 19.5 | 19.5 | 26.0 | 25.5 | 21.5 | 21.5 |
| D3 | 27.5 | 27.0 | 20.5 | 20.5 | 26.0 | 25.5 | 23.0 | 23.0 |
| D4 | 24.0 | 23.5 | 18.5 | 18.5 | 23.0 | 22.5 | 21.5 | 21.5 |
| D5 | 26.0 | 25.5 | 18.5 | 18.5 | 27.0 | 26.5 | 23.5 | 23.5 |
| D6 | 25.5 | 25.0 | 19.0 | 19.0 | 21.5 | 21.0 | 23.5 | 23.5 |
| D7 | 23.0 | 22.5 | 19.5 | 19.5 | 22.5 | 22.0 | 23.5 | 23.5 |
After this work, the HPO is now outputting 169.2 W.
PMC Beam Alignment Tweak
Next, with the ISS still off, I tweaked the beam alignment into the PMC. Only small tweaks were required to maximize the transmitted power. Unfortunately I was not able to recover as much transmitted power as usual; last time I tweaked this alignment, with the ISS turned back on the PMC reflected power was ~14W and the transmitted power was ~65 W. Now the best I could do, with the ISS turned back on, is 16.2W of reflected power and 63.9W of transmitted power. To me, this indicates a slight mode mismatch, which requires a PSL incursion to correct. For now, and for the scope of this work permit, the PMC transmitted power is >60W, which is our target for PMC transmission. This is sufficient for now, and we will plan a PSL incursion for the next maintenance window to investigate this possible mode matching issue.
This closes LHO WP 6578.
FAMIS 3646
During the course of the above work, I reset both PSL power watchdogs; this was at ~16:30 UTC (9:30 PDT). This completes FAMIS task 3646.
TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 12mph Gusts, 8mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY: all times UTC
TITLE: 04/18 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR:Cheryl
SHIFT SUMMARY:
LOG:
12:27 Lockloss - reason unknown
13:32 NLN
Notables:
TITLE: 04/18 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 70Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY:
TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Went out of Observing briefly to run a2l, but other than that it has been running very smooth. 50.5hours
Out of Observing from 02:26 - 02:31UTC to run a2l while LLO was down.
FAMIS6894
ITMX_ST1_CPSINF_V1 high freq noise is high
These plots were made via the python script by Jim and the above message was what it printed out.
Greg, Dave:
While investigating IOP-SUS ADC+Timing errors, I found an event at 03:07:01 Sunday 4/16 PDT in which all of the SUS-EY front end models reported a STATE_WORD of 16 (DAQ error). At the same time, the DAQ Data Concentrator reported a sequence of 23 data blocks with invalid CRC check sums (except for h1susetmypi which reported 24). Greg confirms that the GDS/DMT calibration code did see an invalid data flag at that time.
The CDS overview for the end station sus systems is attached. The EX CRCs incremented at 04:39 4/14 UTC, the EX CRCs incremented at 10:07 4/16 UTC (21:39 Thursday and 03:07 Sunday PDT respectively). Greg says that the EX event on Thursday did not cause a calibration issues as only EY data is being used.
Trending over the past 150 days (to start of O2) shows CRC error burst have occurred 6 times at EX and 8 times at EY.
Detailed time plot of Sunday morning's 03:07 EY event suggests that the data error is contiguous for 23 blocks of data (1/16th second blocks), meaning 1.44 seconds of bad data.
Investigation is continuing.
Miriam, Evan and Dave:
Over the past few weeks we have been investigating the correlation between end station sus computer model glitches and blips seen in the calib_strain channel. Some past glitch events were analyzed by hand, which proved to be time consuming. I have written a python script to capture glitches in real time and log them to a file (script is report_fec_glitches.py in the cds/h1/scripts area).
Today I analyzed 20 glitches which occurred between 4/12 and 4/15. I have written up this analysis on the following wiki page: https://cdswiki.ligo-wa.caltech.edu/wiki/EndStationSusGlitchBlipAnalysisApril2017
As the investigation continues, results will be added to this wiki page.
The raw data can be found in /ligo/cds/lho/h1/fec_glitches/2017/04
Executive summary: about 35% of SUS front end computer glitches appear to cause a blip in calib_strain. The detailed sequence of ADC, Timing and IPC errors differs significantly between glitches.
Located our mobile STS2 (C) as close to the ITMY STS2 (B) as possible which means about 18in center to center.
The two graphs attached show low wind (~5mph) and high wind (~20mph) graphs of ASD and coherence between the two huddling STSs. Good coherence moves well down during the windy conditions as the ground motion increases to above the instrument noise. Coherence above 0.9 moves from 50ish mHz to 5 or 10mHz (depending on dof.) Tomorrow I'll move the roaming machine to around BSC8 and then wait for calm and wind.
In the quite time plot the HAM5 channel (mobile STS?) is noticeably noisier then the IMTY channel, is it the instrument? or the mounting?
TITLE: 04/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: locked entire shift
LOG:
TITLE: 04/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 19mph Gusts, 14mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY:42.5 hrs lock, rode through a good sized earthquake.
Shifter: Beverly Berger
LHO fellows: Karl Toland, Vaishali Adya
For complete results see https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20170413.
I started to repeat the measurement described in llo alog 28797 while we were waiting for LLO to come back up around 20:05 UTC. Since LLO is back, I have stopped and put things back to normal, and Cheryl is running A2L before we go back to observing. (This was about 45 minutes of commisioning).
I got as far as tuning an excitation and finding that an offset of around 0.3 in POSY may be about right, but that we need to wait a long time for the OMC ASC loops and the slow kappa C calculation to settle when making these measurements. The template with the excitation is saved at sheila.dwyer/OMC/OMC_alignment_jitter_check.xml We will continue this Wednesday.
Set the gain of PI modes 27 to zero next time you do this measurement.
As Cheryl noted, mode 27 rang up during your work today (mode 19 was just bleed over from 27). Since we're using OMC DCPD as the error signal for this mode, driving OMC ASC loops changes the phase as seen by this mode such that we must've been driving up the PI; mechanical drive up was real, as it was seen by the TransMon QPD.
This mode is nominally stable after the thermal transient, so as long as you're an hour or so into a lock, you can just set the gain of mode 27 to zero during OMC commissioning.
I also took about 10 minutes with the interferometer locked on RF just now to put some offsets into the OMC alignment loops. These dither loops are very slow, it takes about 3 minutes for them to react to an offset change. For POS X introducing an offset of 0.3 decreases the transmitted power to 88%, for POS Y an offset of 0.3 decreases it to 95% of the power for the normal alingment. I didn't get to check the ANG loops, but it seems like they will need larger offsets (2 or 3).
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1200 seconds. LLCV set back to 20.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1484 seconds. LLCV set back to 38.0% open.
Raised both by 1%.
CP3 to 21%
CP4 to 39%
Contemplating the next layer of automation by adding to code incremental increases/decreases to LLCV control value.
J. Kissel
Gathered regular bi-weekly calibration / sensing function measurements. Preliminary results (screenshots) attached; analysis to come.
The data have been saved and committed to:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/SensingFunctionTFs
2017-03-21_H1DARM_OLGTF_4to1200Hz_25min.xml
2017-03-21_H1_PCAL2DARMTF_4to1200Hz_8min.xml
2017-03-06_H1_PCAL2DARMTF_BB_5to1000Hz_0p25BW_250avgs_5min.xml
J. Kissel
After processing the above measurement, the fit optical plant parameters are as follows:
DARM_IN1/OMC_DCPD_SUM [ct/mA] 2.925e-7
Optical Gain [ct/m] 1.110e6 (+/- 1.6e3)
[mA/pm] 3.795 (+/- 0.0053)
Coupled Cavity Pole Freq [Hz] 355.1 (+/- 2.6)
Residual Sensing Delay [us] 1.189 (+/- 1.7)
SRC Detuning Spring Freq [Hz] 6.49 (+/- 0.06)
SRC Detuning Quality Factor [ ] 25.9336 (+/- 6.39)
Attach are plots of the fit, and how these parameters fit in within the context of all measurements from O2.
In addition, given that the spread of the course of the detuning spring frequency is between, say 6.5 Hz and 9 Hz, I show the magnitude ratio of two toy transfer functions, where the only difference is the spring frequency. One can see that -- if not compensated for, that means a systematic magnitude error of 5%, 10%, 27% at 30, 20, and 10 Hz, respectively.
Bad news for black holes! We definitely need to track this time dependence, as was prototyped in LHO aLOG 35041.
Attached are plots comparing the sensing and response function with and without detuning frequency. Compared to LLO (a-log 32930), at LHO the detuning frequency of ~7 Hz has significant effect on the calibration around 20 Hz (see response function plot). The code used to make this plot is added to svn,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/SRCDetuning/springFreqEffect.m
Attached are plots showing differences in sensing functions and response functions for spring frequencies of 6 Hz and 9 Hz. Coincidentally they are very similar to the plots in the previous comment which show differences when the spring frequencies are 0 Hz and 6.91 Hz.
Unfortunately we could not get DMT hoft to send output downstream with this change. We are going back to calibration 1.1.5 for now.