Raised the dust monitor alarm levels for the optics labs (CS LAB1 and CS LAB2)to Clean 10,000.
TITLE: 07/11 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC STATE of H1: Observing at 107Mpc INCOMING OPERATOR: Jeff SHIFT SUMMARY: Briefly dropped out of observing twice by TCS_ITMY_CO2 guardian. No other issues. LOG: 07:11 - 07:13 UTC TCS_ITMY_CO2 guardian drops out of observing 07:17 - 07:18 UTC TCS_ITMY_CO2 guardian drops out of observing 14:33 UTC Visitors for cultural survey through gate
Briefly dropped out of observing twice by TCS_ITMY_CO2 guardian. No other issues.
TITLE: 07/11 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 11mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: No issues.
TITLE: 07/11 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 31hr lock, Observing my whole shift. Seems like we have had more glitches than usual and I belive our range reflects that.
LOG:
TITLE: 07/10 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
Wind: 12mph Gusts, 9mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: Calibration work finished a bit ago, observing for 1 hour.
Good observing first half of the shift. Received a good GRB Alert. Dropped out of observing twice, once for a TCS Laser glitch and once of a Squeezer unlock. Both recovered and we were back in observing in less than 2 minutes. IFO is in the hands of the commissioning team as they run the Wednesday calibration measurements, from 20:00 (13:00) to 22:00 (15:00). Wind and microseism are bit elevated. No other problems or concerns.
[J. Kissel, A. Viets] Starting at 19 UTC on April 25, 2019, I produced 48 hours of calibrated data with "fast kappas," that is, the time-dependent correction factors (TDCFs) were computed and averaged using a smaller amount of input data. 10 s of data were used to demodulate the calibration lines, and the computed TDCFs were smoothed with a 20 s running median and a 5 s running mean. (Normally, 20 s are used for demodulation, the median is 128 s and the mean is 10 s.) I was trying to find evidence of the "2-minute period oscillations" noted in several aLOGs in late April and early May, e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=48948, https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=48902, https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=48857, and https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=48846. It appears that the oscillation as measured using kappa_C is small compared to the noise when using a shorter median + mean for the TDCFs. So, my suspicion is that these oscillations would be difficult to correct in the calibration. If we use a short average, noise in kappa_C increases to the 1% level, and our usual few minutes of averaging is relatively insensitive to 2-minute oscillations. Several plots of the results are attached: 1. All 48 hours of "fast" kappa_C. I *think* that the SR3 heater change occurred near the end of the day on 4-26, near the beginning of the last long lock stretch shown in this plot. The noise in kappa_C does not increase noticeably, as one might expect if the 2-minute oscillations had a significant impact on kappa_C and increased at that time. However, a small increase in the average value of kappa_C is seen at that time, which is also visible on the summary page for April 27 near the beginning of the day: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20190427/cal/time_varying_factors/. I also computed the correlation coefficient between fast kappa_C and one of the ASC channels (ASC-CHARD_Y_OUT_DQ) before and after the SR3 heater change: Using 15 hours starting at 00:00 UTC on April 26 (first long lock stretch in the plot): -0.0045891 Using 15 hours starting at 03:00 UTC on April 27 (last long lock stretch in the plot): 0.01318592 The correlation did increase, but remains small. 2. The first 15 hours noted above, with ASC-CHARD_Y_OUT_DQ also shown 3. The last 15 hours noted above, with ASC-CHARD_Y_OUT_DQ also shown 4. A zoom-in of 50 minutes of data during the last lock stretch shown in the first plot. 5. Even more zoomed in: ~17 minutes. It is difficult to see any correlation by eye, or to see any periodic oscillations in kappa_C that are distinguishable from noise. It is possible that I have not used the best time for this investigation, or that I should analyze a different front-end channel instead of ASC-CHARD_Y_OUT_DQ. If this is the case, I hope someone else can point me in the right direction. Otherwise, it looks like it is not worth trying to compensate for fast fluctuations in the calibration, but rather to stick with what we've done in the past.
TITLE: 07/10 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC STATE of H1: Observing at 114Mpc INCOMING OPERATOR: Jeff SHIFT SUMMARY: Remained locked and in observing entire shift. No issues. LOG: 13:37 UTC Restarted FOM on nuc4 13:44 UTC Dust alarm in vacuum prep lab
Have remained locked and in observing. No issues.
TITLE: 07/10 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY: No issues.
TITLE: 07/10 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Observing since the end of a short commissioning period. Range seems a touch lower than usual, but I don't notice anything glaring at me as to why. The 48Hz peak is a bit higher than it has been lately though...
LOG:
Daniel, Dave:
at 19:54 UTC (12:54 PDT) the CNS-II GPS receiver at EX went into an alarm state. Attached image shows EX status on lower left, with EY on lower right for comparison.
Daniel says that the 1PPS signal did momentarily glitch at the time the error was raised, but since then the signal is correct (see attachment). He does not know why the system is reporting 'waiting for lock', it detects and tracks the same number of satellites as EY. If the problem perists overnight, he suggests we power cycle this unit during Tue maintenance.
Power cycled Tue around 9am. The clock returned to its old configuration.
Power cycled Tue around 9am. The clock returned to its old configuration.
J. Kissel reporting for D. Sigg and D. Barker. Daniel notes a transient glitch in the 1PPS comparator signal and the IRIG-B, but these are just monitored channels. Their report was in error, and has no impact on the IFO. After that the output from the unit was nominal but with a stuck error which got cleared on reboot. This is just a "thing that can happen sometimes, though rare, and has no consequence? and thus has been determined to be NOT A FAULT and thus will not be reported in the FRS system.
This is a continuation of the investigation in this aLOG comment: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49620 I've plotted 48 hours of data beginning at 19:00 UTC on April 25, 2019. The goal was to capture the SR3 change noted here: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=48787. There is no obvious noteworthy change in the spring frequency or quality factor seen in this plot, only the usual changes in the few hours at the beginning of each lock stretch. The last plot shows trends of DeltaL / Pcal for the same 48-hour period, comparing C00 to a calibration that additionally corrects for time dependence in fs and Q, as well as kappa_PUM and kappa_UIM. It is consistent with the result of the previous aLOG comment, showing that compensating for more time dependence consistently improves calibration accuracy.
Quick trend comparing SRC spring freqnuency against BNS range and DRMI power levels. This will be done much more carefully ... soon.
[J. Kissel, A. Viets] At Jeff's request, I made time series plots of the SRC optical spring squared frequency with several front-end channels on the same plot, to see which are highly correlated. Additionally, I've listed (in the same order as the plots) the Pearson correlation coefficients between fs^2 and each other channel. Note that the correlation is reduced by two effects: first, fs^2 is not computed during lock loss and therefore remains constant, and second, noisy fluctuations (on ~2 minute time scales for fs^2, since that is about how much input data is used to compute each output value) are probably not correlated. Channel Name Name in Plot Correlation Coefficient Description H1:LSC-TR_Y_NORM_INMON TRY -0.07759334 arm cavity power, normalized to power when the Y arm is locked alone H1:LSC-TR_X_NORM_INMON TRX -0.07641386 arm cavity power, normalized to power when the X arm is locked alone H1:LSC-POPAIR_B_RF90_I_NORM_MON POP90 0.00209429 45 MHz sidebands inside PRC H1:LSC-POPAIR_B_RF18_I_NORM_MON POP18 0.05289885 9 MHz sidebands inside PRC H1:LSC-PR_GAIN_OUT16 PRG -0.0719822 power recycling gain H1:LSC-POP_A_LF_OUT16 POP DC -0.09153975 power inside the PRC H1:LSC-REFL_A_LP_NORM REFL DC 0.01795835 power reflected off of the input to PRM H1:IMC-MC2_TRANS_SUM_OUT16 IMC TRANS -0.08331603 power transmitted from the IMC By eye, the power recycling gain, the power in both arm cavities, the power in the PRC, seem to be consistently negatively correlated. So it would appear that the SRC's optical spring frequency is related in some way to the power circulating in the detector. Note the physical meaning of fs^2 as we have defined it: a positive value indicates an optical anti-spring, and a negative value indicates an optical spring. Based on these results, more power in the detector => optical spring is less "anti" and more "pro."
The original aLOG entry shows that correcting for time-dependent systematic errors in the sensing function assuming a model with SRC detuning improves calibration accuracy at the lowest Pcal line frequency. Given that we now believe the primary cause of low-frequency time-dependent systematic errors in the sensing function is a parasitic coupling of angular motion sensing to DARM rather than SRC detuning (see G1901353 and LHO aLOG 50992), I wanted to investigate whether correcting for SRC detuning could lead to an overall improvement in calibration accuracy. The short answer is "Well, close to the lowest Pcal line, yes, but not reliably at other frequencies." I used four Y-end Pcal broadband injections (RX channel), and plotted DeltaL / Pcal from 10-400 Hz for two calibrated data sets: one that corrected for all modeled time-dependence except SRC detuning (spring frequency f_s and quality factor Q), and one that additionally includes time-dependent corrections for SRC detuning. In order to get a measurement of all time-dependent correction factors, I started the gstlal calibration pipeline ~1 hour before the broadband injection, since the calibration lines are turned off during the injections. The dates and associated aLOGs are listed below in the same order as the plots:
Text files with the data of the plots in the previous comment can be found in the calibration SVN in this directory:
aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
with names like
H1_With_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_[GPS_START_TIME]-[DURATION].txt
for data corrected for "SRC detuning" time dependence and names like
H1_Without_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_[GPS_START_TIME]-[DURATION].txt
for data that is not.
Since there is now precedent, I've moved and committed the above mentions "DCS analysis of broadband injections" text files in to the DCS_BB_plots/ directory, e.g.
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/DCS_BB_plots/
H1_Without_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1244406526-120.txt
H1_Without_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1246226240-120.txt
H1_Without_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1247431237-120.txt
H1_Without_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1248718240-120.txt
H1_With_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1244406526-120.txt
H1_With_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1246226240-120.txt
H1_With_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1247431237-120.txt
H1_With_SRC_Corrections_over_CAL-PCALY_RX_PD_OUT_DQ_1248718240-120.txt
This afternoon we spent about 3 hours struggling to lock ALS.
At 20:45 UTC we lost lock while transitioning to Earthquake mode (though the ground motion wasn't really that high)
While reacquiring we kept losing lock while trying to lock ALS. We saw a few different problems:
In conclusion: for some reason we don't know, we couldn't lock ALS for a couple of hours this afternoon. Then for some reason we don't know, we could lock it again.
very similar symptoms now, July 8th 2019 around 23:00 UTC
The problem yesterday evening and probably at the earlier time as well was that the COMM beatnote strength was too low (less than -10dBm). We fixed this by moving a pico in HAM3. For now I've added a check to the ALS_COMM guardian so that it will give a notification and not try to lock if the comm beatnote is less than -9dBm.
During O1+O2 operators used to adjust the alignment of PR3 when the X arm was locked in green to increase the beatnote strength for COMM, we stopped doing this because we thought that PR3 is actually more stable when left alone, and that it might be better to just move the pico when the beatnote gets misaligned, which is what is done at LLO.
Corresponds to FRS Ticket 13231, which has now been closed as per above course action.
This was the TCSY laser relocking...again. The last time it relocked was July 2 17:10 UTC.
The CO2Y PZT seems to be moving much more than CO2X.