TITLE: 01/24 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
Wind: 11mph Gusts, 8mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.52 μm/s
QUICK SUMMARY:
No issues to report. RO is in alarm.
Detchar noticed glitches in h(t) due to snow plowing on Jan 13. LHO alog entries noting ongoing plowing were extremely helpful for figuring out what these glitches were. See the first attachment for spectrograms of an example snow plow glitch showing that near a VEA the initial impact of the plow on the ground and the subsequent scraping of the ground couples into h(t) up to ~100 Hz (witnessed by the ground STS2s, HEPI L4Cs and ISI GS13s). The last spectrogram shows the clear cadence of the plowing near the corner station on an 8 minute timescale.
Building on a DQ flag Laura added to identify when snow plowing was happening near a VEA on Jan 09-10 (alog 33116), I looked at the BLRMS (10-30, 3-10, and 1-3 Hz) for a couple weeks after that day to suggest other times to flag.
The second attachment shows BNS range and the 10-30 Hz BLRMS for days of interest. I used times noted in the alogs as when snow plowing was happening (marked in blue and orange) as a baseline to identify other potential snow plow times not mentioned in the alogs (marked in red).
Seismic glitches identified on Jan 19 and 20 (marked in purple) are likely unrelated to plowing and should be caught with an automated 10-30 Hz or 3-10 Hz BLRMS threshold DQ flag.
I recommend all identified times (blue, orange, and red) from Jan 09-20 be flagged with H1:DCH-SNOW_PLOW (v2).
TITLE: 01/24 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Lockloss once. Not sure how. Otherwise quiet shift. H0:FMC-CS_WS_RO_ALARM was blipping. At least John is awared of it. See alog33552 for the rest of the activities.
LOG:
00:52 Kyle to MY
01:19 Kyle back
Looks like the CO2Y laser lock point may be lost due to small jumps in the current that kicked the pzt out of its place. This is the first time I've seen such behavior (for myself anyway). This TCS guardian node is currently tied to the intent bit and can potentially kick us out of observe.
Plotted again with the full story of transitioning data points, as well as with IFO range to see when the lock transitions happen, and the TCSY flow rate. The laser power transits appropriately at lock loss and again at lock aquisition with a small spike in some TCSY channels. It's the big transit of some of the channels at the beginning of the 2nd lock that is the weird.
And here's a plot of the next 2 lock loss/acquisition events wrt TCSY. This time all signals did what is expected, no TCSY laser mode transistions with subsequent servo corrections.
I think the CO2 laser lock loss is due to the servo being set to an absolute DC value of power. When locking, the CO2 laser PZT scans its full range and we monitor the output power. We then chose a locking point based on an output power that is roughly half way between the minimum and maximum powers in a mode transition. When the loop is locked, the difference between the CO2 laser output power and the set point becomes the error signal for the PZT (with some gain, low pass filtering and integration).
This keeps the laser output power very stable but suffers from a problem that should the long term efficiency (over periods of days to weeks) of the laser changes (get better or worse), the mode-transition to power output power relationship may drift up or down. A mode hop will then approach the set point power. At some point, this becomes too close, the PZT voltage:output power relationship will become nonlinear and we'll lose lock.
Betsy and I think this is probably what happened here. This is backed up by the new locking point (laser power set point) being set a bit lower than previous.
The attached plot shows the laser output power dropping in advance of the PZT voltage. In fact, you can see the laser go through a mode-hop before the PZT reaches zero volts.
This is a relatively uncommon but currently unavoidable event. My recommendation is that we next characterize how frequently this does occur.
Been locked and observing for 10 hrs 44 mins. H1IOPASC0 timing is red on the cds overview. Not sure if hitting Diag Reset will drop us out of Observe so I'm leaving it alone for now. Hit the diag reset button and cleared the error without dropping the intent bit.
Lockloss 06:02:15 UTC. I hit the H1IOPASC0 diag reset button 06:01:10 UTC. Earlier I noticed a bunch of ETMY IPC went red and stayed red for less than a minute (1169272562-1169272582 -- that's why I decided to hit the diag reset button to make sure that one is not causing the other). Otherwise nothing's obvious on the FOM that could be the cause of the lockloss.
Back to NLN but the intent bit is waiting on TCS_ITMY_CO2 guardian. I'm investigating why it loses its lock point.
Back to Observe 06:52 UTC
The input power dropped by about half a watt compared to the previous lock.
C. Cahillane The first LHO total uncertainty budget is reported here for frequency range = 5-5000 Hz and GPSTime = 1167559936. This uncertainty budget was produced in five stages: 1) Take measurements of sensing plantC(f)and actuation stagesA_UIM(f),A_PUM(f),A_TST(f). 2) Run MCMC to fit calibration model parameters to each measurement. 3) Run Gaussian Process (GP) to fit residuals and find unmodeled systematic errors. 4) Produce histograms of the time-dependent parameters two minutes prior to the GPSTime requested. 5) Sample MCMC, GP posteriors, and time dependent histograms to produce a numerical uncertainty budget. The first plot is the total uncertainty budget for all frequencies. Also reported here is the extreme uncertainties for 10-2000 Hz and 2000-5000 Hz. This plot is probably why you're here. Other plots are: 2, 3, 4, 5: The MCMC MAP fit (green) to the Jan 3rd, 2017 reference measurements (red dots), plus 1000 fit instances (grey). (2=Sensing, 3=UIM, 4=PUM, 5=TST) 6, 7, 8, 9: The GP mean posterior (dark blue line) and 1 sigma uncertainty (light blue) and measurement residuals. (6=Sensing, 7=UIM, 8=PUM, 9=TST) PDFs 1, 2, 3, 4: The MCMC parameter corner plots for each measurement. (1=Sensing, 2=UIM, 3=PUM, 4=TST) PDF 5: The time-dependent parameter values and linear fit for two minutes of data, plus histograms. Sorry for the overwhelming number of plots. This was requested by the calibration group. Most people can safely ignore these. Potential source of uncertainty not yet included: 1) Spring Frequency and Inverse Q systematic error + uncertainty If these sources matter there will be a comment to this aLOG. For the LLO total uncertainty budget, please see LLO aLOG 31111.
Variations in the CDS indicated level for CP4 today before 5:15 pm local time were the result of experimental tinkerings and should be ignored. As of 5:15 pm local time, I am pumping on the clogged line with only a diaphragm pump having an in-line 1/4-turn ball valve which has been throttled to permit a maximum flow rate of 0.4 LPM. This flow rate was that which was observed when the diaphragm pump+throttled valve was supplied with 10 psi from a UHP N2 cylinder having an appropriately sized rotameter. Having vacuum on this line tonight should nominally result in a "0.0" percent full value displayed on the MEDM screens. Until further notice, other than 0.0 values shown will indicate that something pertaining to the "clog" has changed and would be of interest.
J. Kissel, S. Dwyer, K. Kawabe WP # 6448 Since we've been having trouble with the intermittent ring-up of the H1 SUS ETMY's 4735 Hz violin mode, Sheila and Keita suggest that we permanently turn on the 4735 Hz notch that's already in place in the LSC-DARM2 filter bank. Contrary to traditional belief, however, a change to the DARM filter banks no longer has no impact on the calibration, in general, because the time-dependent correction factors -- now applied to the h(t) data stream -- are computed using ratios of calibration lines, and the frequency dependence of full DARM loop shape (including changes to the DARM filter bank) between line frequencies must be compensated (see T1500377 and P1600063). In this particular case, one might expect a well-designed notch at 4.7 kHz should have negligible impact on calibration line frequencies used for time-dependence, given that the highest frequency line used is 331 Hz. However, the notch was not well-designed; just something slapped in quickly in a panic to prevent lock loss. Thus, Sheila and I propose a new design. See attached. Called out explicitly here: Current Design: notch(4735.25,5,80) Increased Q of Current Design: notch(4735.25,100,80) Proposed New Design: ellip("BandStop",4,1,80,4720,4750)gain(1.12202) Recall that foton's notch functions take inputs of the form notch(center frequency, Q, dB isolation in stop-band) ellip("filter type",order,dB ripple,db isolation, start frequency, stop frequency) The current design's Q is unnecessarily low, which means that at 331 Hz, there is a 1.15 [deg] phase impact. Too big, if we're correcting for 1% level changes in the optical gain. Both new designs (the higher Q notch and the elliptic band stop) have much less phase impact at the highest calibration line frequency (the elliptic has 0.09 [deg] phase loss, the high-Q notch has only 0.06 [deg] phase loss). However, the elliptic bandstop gets much greater isolation in a broader, 30 Hz band, than the high-Q notch. Thus, we proposed the elliptic band stop. We will upgrade the filter bank, make a new DARM loop model, and update the front-end EPICs representation of that model necessary for correct computation of time-dependent correction factors tomorrow morning during maintenance.
TITLE: 01/24 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY: Mostly a quiet shift
LOG:
19:00 Kyle to MY, back 20:00
22:00 Kyle to MY, back 22:30
Simply by chance I happened to notice the Diode Chiller warning light flash red momentarily on the laser system status screen. I informed the operator (Jim W.) and went to take a look. i watched for a minuite and it happenmed again so I added 500ml. I'm not certain if it could have taken more but it seemed as if it was just at the threshold that maybe the turbulence was barely tripping the warning.
So, I think from the plot, it looks as if it hasn't been happening for a long period of time.
https://lhocds.ligo-wa.caltech.edu will now display the Shibboleth Discovery Service page when it prompts you to log in. If you are familiar with accessing FRS, DCC, or other LIGO services, this is the "which organization are you from?" window that prompts you to pick between LIGO, KAGRA, backup IdPs, etc. This replaces a different system that has been superseded recently (the hidden bit that automatically points you to a LIGO IdP).
This change was made around 22:45 UTC.
All plots look to be in normal, nominal, ranges. There are obvious humidity increases that are consistent with the temperature changes/increases that have been happening in the LVEA. Also on the 1/20 Robert Schofield was measuring water flow noise and made a 9% increase in the flows which is apparent in the chiller pressure plots.
Agree with Ed's analysis, everything looks normal.
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 17 seconds. TC B did not register fill. LLCV set back to 17.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 2275 seconds. LLCV set back to 36.0% open.
Raised CP4 LLCV from 36% to 37% open.
Kyle went to grab a Helium tank just past the card reader at 22:51 UTC and found the card reader already ON. This is on our LVEA Sweep checklist but must have been missed. It is now OFF
It would be good to know if we should keep these Readers OFF or ON. Originally we had been turning them OFF after LVEA Sweeps, but the Sweep checklist had this crossed out & it marked with "ON" (So, the most recent version of the Checklist had the Card Reader line removed).
Maybe these Card Readers are not an issue? Maybe I heard Robert say these Card Readers were negligible.
Robert Schofield's investigations showed no coupling from the card reader in O1. These should be left ON, as they are used by the RRT for site status reconstruction in trigger evaluation.
Nothing noteworthy to report. Plots show normal consistencies between humidity fluctuations and front end diode powers. Incursions for FSS alignment are evident in environmental plots.
Looking back I believe the task number is a typo. It's supposed to read 6130. uups.
