TITLE: 08/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 12mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY:
TITLE: 08/26 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: Ed
SHIFT SUMMARY: Nothing to report. Lock is 11+ hours old.
LOG: None
A pair of landscapers was spotted on site. Since they weren't making much noise, I decided to let them continue their work. See attached photos.
TITLE: 08/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 14mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: Locked for 3 hours. No issues to report.
This is a summary of relocking after this morning's lockloss.
Lockloss at 17:39 (10:39) ? All appeared normal at the time
Had to tweak ALS X to get it to lock and build up power
There were a few lock losses at LOCKING_ASL
As the X arm locked, the power would immediately drop toward zero until lock broke
Put ALS X into unlocked state again, and touched up ETM-X pitch
LOCKING_ALS went on without issue
DRMI_1F would not lock
Dropped to PRMI relock sequence, which completed OK
DRMI_1F still did not look good
After 8.5 minutes went to CHECK_MITCH_FRINGES and hand tuned the BS
PRMI locked OK
DRMI_1F locked OK
Stopped at CHECK_AS_SHUTTERS and dresses a bit more out of PRM and SRM
Run the rest of the way up into ENGAGE_SOFT_LOOPS
Lock loss at 18:49 (11:49)
Again ran up through locking sequence went with no manual intervention
Lock loss at 19:28 (11:28) ? There was an OMC saturation message 42 seconds after entering INCREASE_POWER right at the time of the lock loss
Third automated locking attempt reached NLN at 20:13 (13:13)
Back in Observing at 20:14 (13:14)
There were NO SDF differences to resolve with this relock
All going well until 17:39 (10:39) unknown lockloss. Wind was coming down at the time and primary microseism was improving. Then the Z-axis shot up to 0.09um/s. It bounced around for about 30 minutes, and then dropped back down to about 0.01um/s. Nothing on USGS or SEIMON. Relocking has been a bit of a chore so far. Had to work on ALS X several times. After two attempts at DRMI_1F and PRMI states, had to go through CHECK_MITCH_FRINGES to get DRMI_1F to lock. Tweaked PRM and SRM to get a little better buildup. Things going well until a lockloss at ENGAGE_SOFT_LOOPS. Running buck up through the locking sequence.
TITLE: 08/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Nothing to report. Locked for 9.5 hours.
TITLE: 08/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 14mph Gusts, 11mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: 1.5 hour lock, winds have calmed down.
TITLE: 08/25 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: TJ
SHIFT SUMMARY: After the wind calmed down, H1 relocked without much issue after a few attempts.
LOG: Previous aLogs.
Noticed on the Access System that a door on the Mechanical room was flashing yellow with red lightning bolt through it. Upon inspection, I found the north person door propped nearly completely open with the door stop. I did not enter the Mechanical room, so hopefully no critters have claimed it as their home.
No IA needed and no SDF diffs upon relocking.
Likely due to wind which is gusting to 30+ mph. I did not switch to a different SEI_CONF state because the threshold recommendation is 40+ mph with the relatively low (<0.1 micron/s) microseism were are currently experiencing.
TITLE: 08/24 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 19mph Gusts, 15mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: Locked for 13 hours and Observing for 4 after SQZ briefly kicked us out. No issues to report.
TITLE: 08/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Observing at 115Mpc INCOMING OPERATOR: Travis LOG: 15:59 UTC SEI_CONF to EARTH_QUAKE for eq from Vanuatu 16:21 UTC INJ_TRANS set to INJECT_SUCCESS 18:19 UTC SEI_CONF to WINDY 19:18 - 19:19 UTC SQZ_MANAGER dropped IFO out of observing, relocked itself
Have remained locked and in observing. No issues.
In alog 51366 I showed that the BS yaw is repeatedly wandering by about 1.5urad, and in looking for the source of that wander, I've discovered that the PSL Ante-Room temperature (blue) predicts this BS yaw behavior (orange). Of course, it's the diurnal temperature changes, but what is more interesting is that I can see the beam being steered on the PSL, with Camera 09 (red), that is on the IMC_IN beam. I can also see that there is often an increase in noise on the FSS TRANS PD (pink) signal during these temperature swings, though the increased noise is most easily seen with the FSS REFL PD (gray). The PMC TEMP (brown) appears to be effected by the temperature swing. Of course the question of why the Ante-Room? I started to recognize the connection between temperature and BS yaw, and then looked for signals in the PSL that would show if the beam was being steering in the PSL. This led to Camera 9, and from there, I talked with Jason, and he suggested the PMC heater, and the PMC TEMP turned out to have the best signal to use. I also looked at the FSS, and both TRANS PD and REFL PD signals showed the effect of temperature changes. Having found evidence of the beam being steered from the PSL, I looked for the best temperature sensors, and the ACN (AC North, a sensor in the ceiling) was a very good predictor, but not 100%, the ACS (AC south) was also only sometimes changing when the beam was being steered, and the PSL table temperature sensors are basically flat, so they are not showing the effect of the temperature swing. The signal that led me to the Ante-Room temperature was the dust monitor temperature, from the dust monitor under the PSL table, which has a resolution of 1F, but was often showing that level of change on a diurnal cycle. This behavior started around April, so I'm not sure if that was the change in weather, or something else. I was concerned that the PSL AC units were "acting up" so flipped the breakers off, and did not see a change (which is actually good, but doesn’t explain the IMC_IN and BS yaw changes). Given how well the PSL Ante-Room temperature predicts the IMC_IN beam and BS yaw changes, and the contradicting PSL table temperatures, it's clear that either there's something we have not yet identified as influencing the thermal stability of the PSL, or something we have identified has changed, and we're seeing the effects now. There are 12 plots from April to August in the attached PDF. Recently, there have been a number of lock losses during the fastest change in BS yaw during its wander, but it does not always break the lock, so I've included plots that show both. Plot times and FSS TRANS PD value:
21-Apr, 00:56UTC FSS TRANS PD=3.4
5-May, 23:57UTC FSS TRANS PD=3.9
21-May, 00:35UTC FSS TRANS PD=2.8
10-Jun, 00:56UTC FSS TRANS PD=5.2
29-Jun, 01:28UTC FSS TRANS PD=4.4
5-Aug, 01:50UTC FSS TRANS PD=4.1
6-Aug, 00:43UTC FSS TRANS PD=4.1
10-Aug, 02:11UTC FSS TRANS PD=2.7
12-Aug, 23:32UTC (X = -440000s) FSS TRANS PD=2.1
14-Aug, 22:59UTC (X = -280000s) FSS TRANS PD=2.3
18-Aug, 01:45UTC FSS TRANS PD=4.1
19-Aug, 23:32UTC FSS TRANS PD=4.4
I've also separately uploaded two of the plots from the pdf, which are recent examples, one where the H1 lock survived, and one where it did not.
TITLE: 08/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY: Standing down for GRB alerts (E348107, E348109).
L. Sun
The hourly C01 uncertainty budget plots and txt files are stored here https://ldas-jobs.ligo.caltech.edu/~ling.sun/Calibration/Uncertainty/O3C01/LHO/
LHO: from 1237827584 == Mar 28 2019 16:59:26 UTC to 1244307456 == Jun 11 2019 16:57:18 UTC
Note: If the detector is not locked or the calibration line uncertainty > 0.005, the results are not produced for that given time. (Results cover 71% of the whole duration.)
The attachment demonstrates that the variation of the envelopes is negligible.
- White dashed curve: median of the median values from all the hourly data
- White solid curve: median of the +/- 1 sigma values from all the hourly data
- Color: percentiles of the +/- 1 sigma curves (i.e., variation of the envelope)
L. Sun,
I've fixed the RRNom.py code to exclude kappa_U and kappa_P correction before 0416 in LHO. On the other hand, I found that some jobs unexpectedly failed due to cluster issues in the previous run. Some of the hourly data were missing. I've regenerated C01 statistics for the whole period. Now the coverage is 77% for LHO.
The updated percentile plot and the max mag/phase bound curves are attached. In the percentile plot, we see larger variation at low freq because kappa_U and kappa_P were not corrected before 0416.
The plots are generated using the script ^/trunk/Common/pyDARM/RRNomStat.py
Sample command: python3 RRNomStat.py --statDir=/home/ling.sun/public_html/Calibration/Uncertainty/O3C01/LHO/ --IFO=LHO --nameTag=O3_C01
L. Sun
The max bound plot in the previous comment shows the max of all statistics. Now it's updated to show the max bounds of different percentiles.
The variation in the uncertainty percentiles seen in the 95th ("2 sigma") and 99th ("3 sigma") from the 68th ("1 sigma") are a result of H1's h(t) not correcting for \kappa_P and \kappa_U during the observational stretched before April 16th, when we didn't trust them enough (see details in FRS Ticket 12997 and associated dependencies).
Why didn't we trust them? In short:
Because ETMX calibration lines used to determine \kappa_U and \kappa_P were too far apart from the PCAL absolute reference line -- and the time-dependent sensing function was varying enough (see 51115 and FRS Ticket 13012) that the approximation that "the calibration lines are close enough that the time variance of the ratio of C/(1+G) at PCAL frequency and each ETMX line is negligible" [see section 2.4 in T1700106] breaks down).
Thus, the (yes, still untrustworthy) measured values of \kappa_P and \kappa_U are applied as a *systematic error* in the uncertainty and error budget, and thus that budget is time-variant, and increasing the 95th and 99th percentile values. This creates an *over-estimate* of the systematic error, as PUM and UIM actuation strengths as measured with frequency dependent sweeps have remained entirely static over the run thus far -- see LHO aLOG 50992 and G1901479. However, we accept this poor assessment as of the time-dependence actuator systematic error as a "conservative" estimate of what it could be (where the GPR covers the unknown static frequency dependence).
After April 16th, we moved all actuator calibration line frequencies lower and much closer to each other (see LHO aLOG 48551).
Attached is supplemental material from Lilli showing what the percentiles look like if O3 uncertainty and systematic error estimates prior to April 16th are *excluded.*
One can see much less variance, and the 95th and 99th percentile curves lie right on top of the 68th percentile curve, as expected.
[Editor's note -- these were sent to calibration mailing list on Aug 27 2019, under thread "To Use or Not to Use: TDCFs for H1 until Apr 16th" -- 2019-08/msg00166.html. Unclear if they were yet put in the repo, but I've committed them to /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/, perhaps redundantly, and will remove and delete once I find out if /where they were committed elsewhere .