TITLE: 01/05 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 68.823Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Locked and observe the entire shift. Low frequency noise (10-20Hz) also has been apparent all night. a2l didn't seem to help.
LOG:
15:30 out of observe to run a2l
15:46 Back to observe.
Still up and observing. Low wind, low useism. LLO is down.
TITLE: 01/05 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 68.6153Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT: Wind: 13mph Gusts, 10mph 5min avg Primary useism: 0.02 μm/s Secondary useism: 0.15 μm/s
QUICK SUMMARY: Not much. Verbal alarm complains about TCSY low flow. This is a known issue. The chiller on the mezzanine reported nomal flow rate.
02:49 H1 back to NLN
02:59 a2l. PIT out a little. YAW out a lot
03:14 Intention Bit set to Observing
04:32 Prop airplane flyover.
I think our fan flow rates at EY are bogus - In order to improve temperature control Bubba and I adjusted flows on SF1 and after no response decided to turn on SF2.
Plot of the idicated flows attached - SF2 (red trace) shows 7 days of somewhat uniform flow even though we just turned it on today. Blue trace does not show expected results of adjusting pitch control as we did today.
If temperature control has improved by tomorrow we will leave the second fan running (two fans operating). Please let us know if there is evidence of increased vibration or noise due to this fan addition.
Changes were made between 4:45 pm and 5:00 pm local time.
I was left instructions to run a2l a few hours into the new lock. It's a bit early but the range has deteriorated too much for my pleasure and the YAW coherence is coming apart pretty bad. I've informed LLO of my action and will also inform them when I'm finished and back in the game.
Incidentally, running the a2l script from th MEDM launch screen seems to crash all of the MEDM screens. I thought, at first that it was only the new Ops workstation but I now see it happening on the other workstation as well.
back to Observing @ 05:23UTC
Re: running a2l from sitemap->sus->a2l screen crashes medm screens
There was a typo on the a2l button that I must have added before the break. There was an apostrophe at the end of the command for running the a2l script, this obviously was doing something bad. It was actually my punctuation all out of order. Needed to be ' & not & ' . It's fixed now, a2l should run normally from this screen.
All times in UTC:
The attached plot shows that the fier alarm activated at approximately 2 minutes after 00:00UTC. Lockloss occurred approx 3 minutes after the alarm had been silenced.
It seems that the PSL Mic detected the alarm at roughly 00:02:23 until 00:09:12. The duration of it was approx 7 minutes.
I picked a common, control room StripTool channel, H1:LSC-TR_X_NORM_INMON, to represent the time of lockloss which seemed to have occurred at approx 00:12:16. Most all of the other mics show a spike feature at the same time as the TR_X plot indicating some correlation.
03:14UTC
While working on the HVAC Controls Upgrade, Apollo was restarting the air handling unit (AHU-4) which supplies air and heat to the office areas of the OSB. This apparently stirred up some dust in the duct work activating the smoke detector and setting off the building fire alarm. This brought about an abrupt end to the weekly meeting and also served as our annual fire alarm drill. Many parts of our system have not operated correctly for several years and this alarm was testament that this upgrade is paying off in that we will now be able to control our HVAC system the way it was originally intended to perform, possibly even better with the advancement in technology of the replacement parts. KUDOS to everyone on site for doing exactly what they were supposed to do during a fire alarm.
J. Kissel I've completed analysis of the new 2017-01-03 reference measurements (LHO aLOG 32942) that were taken after the L2/L3 cross-over upgrade (see LHO aLOG 32933), and including the updates to the AA/AI filtering (see LHO aLOG 32907). I will post more details later. However, I have not yet pushed these results to DARM loop model parameters or the front end replica, nor have I generated new EPICs records to go with them. Therefore, the time-dependent correction factors, which use the update EPICs records will still be ~15-30% incorrect as they've been since the L2/L3 crossover change (i.e. the entire datset since the restart after the break), and will flag the calibration as bad, which means the ANALYSIS_READY bit will still be flagged as bad the up-coming lock stretches over night. My hope is to get better information out within 24 hours. Apologies, and thank you for your continued patience.
~1625 - 1630 hrs. local -> Kyle in and out of LVEA Shut down rotating shaft vacuum pumps which had been pumping PT180 (BSC8) for the past 8 days. Also, removed ladder which had been leaning against BSC8. We should now have enough data to compare and contrast PT180's behavior between when it is exposed/pumped by the YBM to that of when exposed/pumped by a locally mounted turbo. Recall that the post-detect era installed Bayard-Alpert gauges PT170, PT180 and PT140 all exhibit a slow upward drift that the iLIGO era Cold Cathode gauges (sampling same vacuum volume) do not. Understanding/believing our gauges is critical. We will decouple the vacuum pumps from PT180 on the next maintenance day.
Pressure reading from PT180 is once again rising after being valved into main volume. We suspect the water load is causing this. End stations show no sign but also get 2.5x more pumping speed from cyropumps due to smaller volume.
PT140 pressure reading on diagonal volume (no crypopump) started dropping this week after a three month incline. These changes are due to LVEA temperature fluctuations.
Correction: water pumping speed is more like 1.8x more at end stations.
Corner volume = 445,000 liters
End volume = 88,000 liters
Corner cyropumping = [100,000 - 3,000] x 2 (L/s)
End cryopuming = 100,000 - 30,000 (L/s)
State of H1: Observe, and there's a potential for some site noise sources today listed below
Site Activities:
Bubba raised some concerns about the EY HVAC system and after running it by Mike, drove to EY to investigate.
I have produced filters for offline calibration of Hanford data from the beginning of O2 A until the end of 2016. The filters can be found in the calibration SVN at this location: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/GDSFilters/H1DCS_1163173888.npz For information on the calibration model, see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31693 https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32329 https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32907 For suggested command line options to use when calibrating this data, see: https://wiki.ligo.org/Calibration/GDSCalibrationConfigurationsO2 The filters were produced using this Matlab script in SVN revision 4050: ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/TDfilters/H1_run_td_filters_1163173888.m The parameters files used (all in revision 4050) were: ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/Common/params/IFOindepParams.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/H1params.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/params/H1_TDparams_1163173888.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CAL_EPICS/D20161122_H1_CAL_EPICS_VALUES.m Several plots are attached. The first four (png files) are spectrum comparisons between CALCS, GDS, and DCS. Kappas were applied in both GDS and DCS plots with a coherence uncertainty threshold of 0.4%. Time domain vs. frequency domain comparison plots of the filters are also attached. Lastly, brief time series of the kappas and coherences are attached, for comparison with CALCS.
More plots from beginning of O2 (Nov 30) to show that these filters still have the right model and EPICS.
Same set of plots one more time, this time in early ER10 (Nov 16). Note that kappas were not applied in the GDS pipeline this time, leading to a notable difference in the spectra.
These filters have been updated to account for corrections made to the DARM loop parameters since the AA/AI filter bug fixes. For information on the model changes, see: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=33153 The updated filters were produced using all the same files (updated versions) in SVN revision #4133. The only exception is that the EPICS file and the parameters file to produce it were: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CAL_EPICS/DCS20161112_H1_CAL_EPICS_VALUES.m /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CAL_EPICS/callineParams_20161118.m Note from the plots the slight discrepancy between GDS and DCS, presumably due to the corrections to the model. Also note that DCS and CALCS do not agree on the kappas. This is likely not cause for concern, as the model used to compute them was different. The EPICS and pcal correction factors were produced using the same parameter files as the filters, so they should be correct.
I reset the dark offsets for all LSC and ASC PDs. The ASC diodes already had scripts in ..../userapps/asc/common/scripts/dark_offset/, so I copied the style of those into an LSC script that now lives in ..../userapps/isc/common/scripts/dark_offset/.
I also created a bash script that will call each of those scripts in succession - it's natively in the isc folder, but linked in the asc folder: all_offsets_LSCandASC.
For last lock, and the one that Ed just got, we've had SDF diffs due to not rounding in one of the pre-existing dark offset scripts (the one that does the end station QPDs). The diffs were of the order 1e-16, so were just accepted so that we can Observe. I have modified (although not run, since we just locked) the script such that we have rounding. This should prevent the problem in the future. Next time we lose lock and I'm around, I'll try to remember to hand-round those values so that we don't keep getting non-useful SDF diffs.
Also, Ed might write about this in his shift summary, but it seems like the ASAIR_LF offset was set a little wrong. Sheila and Ed took the IMC to offline and hand-set that offset, and we were able to get through the PRX_Locked state of initial alignment. (The wrong dark offset was causing the output to not meet the guardian's threshold of whether the cavity was locked or not, even though it was locked).
