TITLE: 08/08 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 53Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 5mph Gusts, 4mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
GraceDB query failure (see previous alog). Talked to LLO and asked them to alert us when they receive notifications.
The Ops overview MEDM screen is showing a red block that reads 'GraceDB query failure' (see attached). I found the following wiki page: https://cdswiki.ligo-wa.caltech.edu/wiki/ExternalAlertNotification and followed the instructions to log in to h1fescript0 and run 'ps aux | grep exttrig'. It reports the following: root 787 0.0 0.0 77568 3636 ? Ss 23:41 0:00 sshd: exttrig [priv] exttrig 963 0.0 0.0 77568 1612 ? S 23:41 0:00 sshd: exttrig@pts/5 exttrig 964 0.9 0.0 26860 8112 pts/5 Ss 23:41 0:00 -bash exttrig 1217 0.0 0.0 18148 1260 pts/5 R+ 23:41 0:00 ps aux exttrig 1218 0.0 0.0 9380 940 pts/5 R+ 23:41 0:00 grep --color=auto exttrig exttrig 2386 0.0 0.0 28320 1640 ? S 2016 348:20 caRepeater exttrig 5449 0.0 0.0 26992 1464 ? Ss Jun20 0:00 SCREEN exttrig 5450 0.0 0.0 27416 8820 pts/8 Ss Jun20 0:00 /bin/bash exttrig 6107 0.0 0.0 129772 9276 pts/8 Sl+ Jun20 33:49 python ./viralert_epics_ioc.py This does not match what the wiki page says should be shown, but the wiki page was last updated in 2015, so maybe it is just not up to date? I suspect this is the reason that there was no verbal alert of the earlier GRB (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=38051)? As an aside, the screen that I brought up locally shows a red block near end Y that reads 'RMS WD'. This is not present on the one currently on the wall monitor. Looking at the ETMY suspension MEDM screen, to my eye I do not see anything out of place (see attached).
The wiki page does not give instructions for manually starting the code.
TITLE: 08/08 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 52Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:
LOG:
Backscattering at ISCT1 has been a problem in the past ( https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=35538) and we have installed new beam dumps (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=35636). To answer the question of whether backscattering from ISCT1 will be a problem at higher sensitivities (assuming the current beam dumping), we placed a rented large-amplitude shaker on the leg cross beams.
An estimate from the data shown in the plot suggests that, assuming linearity, the background motion of the table would produce noise at the level of 1.1e-19 m/sqrt(Hz) at 11.4 Hz (a coupling factor of 1.25e-11 m test mass motion per meter of table motion).
We double checked that the features associated with shaking in the figure were produced by scattering from the POP path by closing the beam diverter. The features did go away when we closed the beam diverter.
Philippe Nguyen, Sheila Dwyer, Robert Schofield
T Vo, Sheila
We measured a transfer function from PCAL X to DARM this afternoon. The attached screenshot shows a comparison of driving the ETMX ESD in the low noise state (with the settings that allowed us to transition to it from ETMY) and a drive to PCALX_DARM with the filters that Thomas copied from the ESD filter banks. The red trace (ref 14+15) were taken with a gain of -150 in the PCAL filter bank.
Based on this measurement, Thomas and I estimated this morning that we would need a gain of about -3000 in the PCAL X DARM bank to transition to PCAL X from the ESD, but that this would result in about 50 V rms on the OFS PD. (There is about -82 dB of gain between the OFS PD (in Volts) and the output of the PCALX DARM bank. This means that we would not have enough range on PCAL to simply replace the ESD with PCAL, so we have not tried the transition or locking ALS on ETMY.
If we aren't able to disconnect the ESD cables while in lock, we could look at using one of the ITM ESDs to transition from high voltage to low voltage on one ESD with the other disconnected. We also talked with Daniel, RIchard and Fil who had some ideas about different ways to try disconnecting the cables while in lock. We were about to try these when the EQ hit us.
Apologies, Intention bit off and then on again. There was a question about a Pcal line change that Sudarshan requested of me before returning to Observing but Sheila had turned all the lines off anyway.
02:40UTC Also, I just realized that the lights in the LVEA remained on for the last hour. Robert is going in to turn them off now.
01:37 We didn't get the verbal alarm ad Guardian didn't go into it's normal INJ_TRANS routine. This was done manually and a 1 hour stand-down is being observed. There were no changes being effected on the instrument at the time of LLO's verbal notification. There were some folks in the LVEA. H1 Intention Bit was still in Commissioning.
02:37 GRB 1 hr stand-down has expired.
TITLE: 08/07 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 53Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
TITLE: 08/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Locked the entire shift and 25 hours total. No issues to report. There are 'Configuration Change' lights on the CDS Overview for SUSETMY and CALEX. These are known to be related to WP 7104 and are filter modules that have been changed, but not yet loaded.
LOG: See previous aLogs.
22:59 Commissioning mode for Robert injections and Sheila/Thomas ESD work
Standdown to end 22:58 UTC.
In alog 38044, I posted views inside HAM2 from currently available viewports:
Lock is 21.5 hours old. No issues.
With Gerardo's help, I collected images of optics and baffles in HAM2 from all currently available viewports, with a focus on identifying fiducials for evaluating the input alignment. The full report is T1700230, and the most notable fiducials are listed below with images attached.
Fiducials of note:
TITLE: 08/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 55Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY: No issues handed off. Lock is 17 hours old.
TITLE: 08/07 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC STATE of H1: Observing at 54Mpc INCOMING OPERATOR: Travis SHIFT SUMMARY: Rode through a series of earthquakes in Papua New Guinea. Remained in observing the entire shift. LOG: N/A
M 5.3 - 156km SSW of Lorengau, Papua New Guinea 2017-08-07 12:12:11 UTC 3.351°S 146.777°E 10.0 km depth or M 5.3 - 171km SSW of Lorengau, Papua New Guinea 2017-08-07 12:02:50 UTC 3.510°S 146.819°E 10.0 km depth H1 remained locked.
FAMIS 6909 HAM3 V1 seems elevated. BS ST1 all DOF seem elevated. ETMY ST1 H2 seems elevated. ETMY ST2 V2 seems elevated. ITMX ST1 all DOF seem elevated. ITMX ST2 V3 seems elevated. ITMY ST1 all DOF seem elevated.
J. Kissel, R. McCarthy Some investigation on this... Date Jun 26 2017 Aug 02 2017 Time GPS 1182506160 - 1182506760 1185730620 - 1185731220 Time UTC 09:55:42 - 10:05:42 17:36:42 - 17:46:42 Time PDT 02:55:42 - 03:05:42 10:36:42 - 10:46:42 Richard points to data from the Jun 26th FAMIS check, in LHO aLOG 37138, worried that this might be exposing something wrong after the July 6th Montana EQ. - I've trended the global seismic configuration, and we were in "WINDY" at both these times, so this rules out a different configuration of the ST1 controls (i.e. I'd thought it was maybe that we were in a higher blend filter, or sensor correction for the site was off or something.) - The summary pages don't show a difference between the ST2 / Suspension Point performance on these two days, which means whatever excess that ST1 is seeing is controlled below the sensor noise of ST2 GS13s, which is good. (Not summary pages are a media spectra for the entire UTC day, not just for these 10 minute periods used for this FAMIS test). - Then I realized there should be a large difference in the 1-3, 3-10 Hz input ground motion, just due to the difference between 3am local and 10am local anthropogenic activity. I attach spectra comparing ground motion (as measured by the STSs on the ground in all VEAs), and they agree with what's shown in the ST1 CPS -- in the 0.8 to 20 Hz region, there are features that show roughly an order of magnitude more motion in all buildings comparing the Jun 26th time and Aug 02 time. This is not at all indicative of anything wrong. (Aug 02 is the reference, Jun 26 is the non-reference data). We should standardize at what time of day we use to gather data for inspection in this FAMIS task. The test was designed to look for elevation in the *sensor noise* of the ISI's capacitive position sensors, indicative of problems we've seen with the electronics -- i.e. the flat, above 10 Hz, featureless part of the spectra will be elevated above the black line if there's badness. There will likely *always* be feature-full, residual seismic motion that's visible in these spectra that can be different from test-to-test, especially on stage 1 in the 1-30 Hz range because ST1 does not isolate this region (that job is left for stage 2 / ST2). One can't necessarily *know* that the feature-full full stuff is "real" residual seismic data, but this test is designed for you to ignore that stuff, and focus on the high frequency flat portion of the spectra. Standardizing that we take the data in the middle of the night, local time, when there is less 1-30 Hz input ground motion (since most people are asleep), means the platform will be moving less, and expose more CPS sensor noise, and this'll be a more focused test.
I've updated both HAM and BSC python scripts to look at 2 am local using gpstime.tconvert('2am today') . I've also left code in, commented out, so that the measurement time can be specified in the terminal. It would be nice to have some easier to find or use documentation for some of these libraries. I knew there was tconvert python stuff, but had no idea where to find how to use it.