I simply logged in to the alog using my credential on Ops station. I opened up GraceDB webpage and noticed that the GraceDB querying is good again.
The ext_alert.py script which periodically views GraceDB had failed. I have just restarted it, instructions for restarting are in https://lhocds.ligo-wa.caltech.edu/wiki/ExternalAlertNotification
Getting this process to autostart is now on our high priority list (FRS3415).
here is the error message displayed before I did the restart.
File "ext_alert.py", line 150, in query_gracedb
return query_gracedb(start, end, connection=connection, test=test)
File "ext_alert.py", line 150, in query_gracedb
return query_gracedb(start, end, connection=connection, test=test)
File "ext_alert.py", line 135, in query_gracedb
external = log_query(connection, 'External %d .. %d' % (start, end))
File "ext_alert.py", line 163, in log_query
return list(connection.events(query))
File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 441, in events
uri = self.links['events']
File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 284, in links
return self.service_info.get('links')
File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 279, in service_info
self._service_info = self.request("GET", self.service_url).json()
File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 325, in request
return GsiRest.request(self, method, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 201, in request
response = conn.getresponse()
File "/usr/lib/python2.7/httplib.py", line 1038, in getresponse
response.begin()
File "/usr/lib/python2.7/httplib.py", line 415, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.7/httplib.py", line 371, in _read_status
line = self.fp.readline(_MAXLINE + 1)
File "/usr/lib/python2.7/socket.py", line 476, in readline
data = self._sock.recv(self._rbufsize)
File "/usr/lib/python2.7/ssl.py", line 241, in recv
return self.read(buflen)
File "/usr/lib/python2.7/ssl.py", line 160, in read
return self._sslobj.read(len)
ssl.SSLError: The read operation timed out
I have patched the ext_alert.py script to catch SSLError exceptions and retry the query [r11793]. The script will retry up to 5 times before crashing completely, which is something we may want to rethink if we have to.
I have request both sites to svn up and restart the ext_alert.py process at the next convenient opportunity (the next time it crashes).
TITLE: Sep 26 OWL Shift 23:00-07:00UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Observing
LOCK DURATION: Entire Shift
SUPPORT: N/A
INCOMING OPERATOR: Nutsinee
Activity log:
09:13 SUS E_T_M_Y saturating (Sun Sep 27 9:13:21 UTC)
09:13 SUS E_T_M_Y saturating (Sun Sep 27 9:13:23 UTC) .6Mpc
10:19 SUS E_T_M_Y saturating (Sun Sep 27 10:19:5 UTC) 3Mpc
11:45 SUS E_T_M_Y saturating (Sun Sep 27 11:45:40 UTC) odd...no loss of range
12:21 Noticed the GraceDB quey failure.
14:15 Mike checked in by telephone. He suggested that I e-mail Duncan, Leo and Peter S about the GraceDB query failure that has existed for the duration of my shift.
Shift Summary: Smooth sailing with the IFO locked at 74Mpc. Wind speeds <10mph. 4 ETMY glitches. No obtrusive seismic or weather activity. I e-mailed Duncan, Leo and Peter S about the GraceDB query failure that has existed for the duration of my shift. Handing off to Nutsinee.
Mid-Shift Summary: Smooth sailing so far with the IFO locked at 74Mpc. Wind speeds have decreased to <5mph. 3 ETMY glitches so far.
TITLE: Sep 27 OWL Shift 07:00-15:00UTC (00:00-08:00 PDT), all times posted in UTC
STATE Of H1: Observing
OUTGOING OPERATOR: Patrick
QUICK SUMMARY:. IFO Locked at 70Mpc/22.9W. No injections are running. All lights are off in LVEA, MID, END and PSL. Wind is below 15mph. Microseism seems to be riding steady @ ~.1µm/s. EQ seismic seems nominally steady @ .2µm/s. No noticable 45Mhz RFAM glitching noticible in triggers, in the last hour at least. Verbal Alarms is down on FOM,Video5.
TITLE: 09/26 [EVE Shift]: 23:00-07:00 UTC (16:00-00:00 PDT), all times posted in UTC STATE Of H1: Observing, ~71 MPc SHIFT SUMMARY: Remainder of shift quiet except for SUS ETMY saturations. Wind has come back below 20 mph. Seismic in 0.03 - 0.1 Hz is coming down at end X and end Y. INCOMING OPERATOR: Ed ACTIVITY LOG: 03:59 - 4:06 UTC Stepped out of control room ETMY SUS Saturations: SUS E_T_M_Y saturating (Sat Sep 27 0:2:19 UTC) SUS E_T_M_Y saturating (Sat Sep 27 0:14:27 UTC) SUS E_T_M_Y saturating (Sat Sep 27 0:57:42 UTC) SUS E_T_M_Y saturating (Sat Sep 27 2:23:2 UTC) SUS E_T_M_Y saturating (Sat Sep 27 2:23:5 UTC) SUS E_T_M_Y saturating (Sat Sep 27 2:40:7 UTC) SUS E_T_M_Y saturating (Sat Sep 27 2:41:41 UTC) SUS E_T_M_Y saturating (Sat Sep 27 3:20:30 UTC) SUS E_T_M_Y saturating (Sat Sep 27 4:0:59 UTC) SUS E_T_M_Y saturating (Sat Sep 27 4:18:21 UTC) SUS E_T_M_Y saturating (Sat Sep 27 5:0:57 UTC) SUS E_T_M_Y saturating (Sat Sep 27 5:7:52 UTC) SUS E_T_M_Y saturating (Sat Sep 27 6:20:14 UTC)
23:12 UTC Tour in control room before 23:36 UTC Tour out of control room 23:37 - 23:39:10 UTC Stepped out of control room 23:55 UTC Tour in control room 00:13 UTC Tour out of control room 00:30 - 00:39 UTC Stepped out of control room 7 SUS ETMY saturations. Range is starting to trend down over last hour, now at ~ 65 MPc. Winds have ranged up to 30 mph. Seismic in 0.03 - 0.1 Hz band at end X and end Y has come up to ~ .1 um/s. Corner station is at ~ .01 um/s. Have remained in observation mode since beginning of shift.
Executive summary:
A matlab file (37 MB) containing the averaged inverse-noise-weighted spectrum from the first week can be found here: https://ldas-jobs.ligo.caltech.edu/~keithr/spectra/O1/H1_O1_week1_0-2000_Hz.mat Because of the way multiple epochs are handled, the matlab variable structure is non-obvious. Here is how to plot the full spectrum after loading the file: semilogy(freqcommon,amppsdwt{1,1})
Keith has found: "There is a sporadic comb-on-comb with 0.088425-Hz fine spacing that appears with limited spans in three places near harmonics of 77, 154 and 231 Hz (ambiguity in precise fundamental frequency)" Using the coherence tool, we have seen coherence between h(t) and a number of auxiliary channels that shows this comb around 77 Hz. Seems to be around the input optics, in channels: H1:PEM-CS_MAG_LVEA_INPUTOPTICS_Z_DQ H1_SUS-ITMY_L1_WIT_L_DQ H1:SUS-BS_M1_DAMP_L_IN1_DQ H1_SUS-ITMY_L1_WIT_P_DQ H1:SUS-BS_M1_DAMP_T_IN1_DQ H1_SUS-ITMY_L1_WIT_Y_DQ H1:SUS-BS_M1_DAMP_V_IN1_DQ H1_SUS-ITMY_L2_WIT_L_DQ H1:SUS-BS_M1_DAMP_Y_IN1_DQ H1_SUS-ITMY_L2_WIT_Y_DQ See the attached figures. Nelson, Soren Schlassa, Nathaniel Strauss, Michael Coughlin, Eric Coughlin, Pat Meyers
The structure at 76.4Hz Nelson listed some channels for above shows up in at least 50 other channels. Greatest coherence is consistently at 76.766 Hz, second greatest is (mostly) consistently at 76.854Hz. Spacing between the two combs is about 0.0013Hz. The epicenter seems to be the INPUTOPTICS/the SUS-BS and SUS-ITM* channels, like Nelson said (see below for fuller list). The plots above are pretty typical, but I have plots for all channels listed and can post any more that are useful. Most or all channels showing the comb with max coherence greater than 0.1 are listed below. Max coherences over 0.2 are marked below as strong, and max coherences under 0.15 as weak. Those marked strongest are around 0.22. I haven't included anything of max coherence <0.1 but I'm sure there are many. H1:ASC-AS_A_RF36_I_PIT_OUT_DQ (weak) H1:ASC-AS_A_RF36_I_YAW_OUT_DQ H1:ASC-AS_A_RF36_Q_PIT_OUT_DQ H1:ASC-AS_A_RF36_Q_YAW_OUT_DQ (weak) H1:ASC-AS_B_RF36_I_YAW_OUT_DQ H1:ASC-AS_B_RF36_Q_YAW_OUT_DQ (strong) H1:ISI-BS_ST2_BLND_RZ_GS13_CUR_IN1_DQ (strong) H1:ISI-BS_ST2_BLND_Z_GS13_CUR_IN1_DQ (strong) H1:ISI-HAM2_BLND_GS13RZ_IN1_DQ H1:ISI-HAM2_BLND_GS13Z_IN1_DQ H1:ISI-HAM3_BLND_GS13Z_IN1_DQ (strong) H1:ISI-HAM5_BLND_GS13RZ_IN1_DQ H1:ISI-HAM5_BLND_GS13Z_IN1_DQ H1:ISI-HAM6_BLND_GS13RZ_IN1_DQ H1:ISI-ITMX_ST2_BLND_RX_GS13_CUR_IN1_DQ (weak) H1:ISI-ITMX_ST2_BLND_Z_GS13_CUR_IN1_DQ (strong) H1:ISI-ITMY_ST1_BLND_RZ_T240_CUR_IN1_DQ (weak) H1:ISI-ITMY_ST1_BLND_Y_T240_CUR_IN1_DQ (weak) H1:ISI-ITMY_ST2_BLND_RZ_GS13_CUR_IN1_DQ (strong) H1:ISI-ITMY_ST2_BLND_Z_GS13_CUR_IN1_DQ (strong) H1:LSC-PRCL_IN1_DQ H1:PEM-CS_LOWFMIC_LVEA_VERTEX_DQ (strong) H1:PEM-CS_MAG_LVEA_INPUTOPTICS_Y_DQ (strongest) H1:PEM-CS_MAG_LVEA_INPUTOPTICS_Z_DQ (strong) H1:SUS-BS_M1_DAMP_L_IN1_DQ (strongest) H1:SUS-BS_M1_DAMP_T_IN1_DQ (strong) H1:SUS-BS_M1_DAMP_V_IN1_DQ (strong) H1:SUS-BS_M1_DAMP_Y_IN1_DQ (strong) H1:SUS-ITMX_M0_DAMP_R_IN1_DQ (strong) H1:SUS-ITMX_M0_DAMP_V_IN1_DQ (strong) H1:SUS-ITMY_L1_WIT_L_DQ (strong) H1:SUS-ITMY_L1_WIT_P_DQ (strong) H1:SUS-ITMY_L1_WIT_Y_DQ (strong) H1:SUS-ITMY_L2_WIT_L_DQ (strong) H1:SUS-ITMY_L2_WIT_P_DQ (strong) H1:SUS-ITMY_L2_WIT_Y_DQ (strong) H1:SUS-MC1_M3_WIT_L_DQ H1:SUS-MC1_M3_WIT_P_DQ (weak) H1:SUS-MC2_M1_DAMP_L_IN1_DQ H1:SUS-MC2_M1_DAMP_T_IN1_DQ H1:SUS-MC2_M1_DAMP_Y_IN1_DQ H1:SUS-PR2_M1_DAMP_P_IN1_DQ H1:SUS-PR2_M1_DAMP_R_IN1_DQ H1:SUS-PR2_M1_DAMP_V_IN1_DQ H1:SUS-PR2_M3_WIT_L_DQ H1:SUS-PR2_M3_WIT_P_DQ (weak) H1:SUS-PR2_M3_WIT_Y_DQ (weak) H1:SUS-PR3_M1_DAMP_P_IN1_DQ H1:SUS-PR3_M1_DAMP_V_IN1_DQ H1:SUS-PRM_M1_DAMP_L_IN1_DQ (strongest) H1:SUS-PRM_M1_DAMP_T_IN1_DQ H1:SUS-PRM_M1_DAMP_Y_IN1_DQ (strong)
The 99.9989Hz comb Keith found (designated H) appears in 109 channels (list is attached). Coherence is uniformly greatest at the ~500Hz harmonic, with many channels approaching .7 and greater, drops off sharply at the ~600Hz and ~700Hz, and is invisible after 700. (See spreadsheet titled "comb_H_sigcohs_wk1.xslx" for a list of cohering channels by line, with coherence value.) At all harmonics except the ~300Hz, the structure manifests in the signal and the coherences as two lines .001Hz apart, but if I recall correctly .001Hz is the resolution of the frequency series, so it's safer to say that this is a bulge with .001Hz < width < .002Hz. At ~300Hz, almost all the cohering channels with data in that range show a bulge of width about 0.5Hz (see attached "disjoint_plots" for a comparison of typical channels by harmonic). This bulge, and the fact that it appears in all the same channels associated with the rest of the comb, makes me think that the fundamental may be the bulge at ~300Hz and not the line at 99.9989Hz. An interesting feature of the bulge is that in many cases, it has a prominent upward or downward spike at 299.96Hz, which is just the place the line would be if it were there (see "bulge_w_spike.jpg"). More to come re: changes in week 4 data, patterns in cohering channels, and the spike.
LHO hosted a public event this afternoon. Arrival time at LSB = 1:00 - 2:30 PM PM. Departure time = 3:00 - 5:00 PM. Group size = ~170 adults/children of all ages. Vehicles at the LSB = ~50 passenger cars (very uncertain). A series of three walking tours between 3:00 and 5:00 brought a total of ~120 people into the control room during this time span.
TITLE: 09/26 [DAY Shift]: 15:00-23:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Observing at ~75 Mpc
SUPPORT: Mike
QUICK SUMMARY: Less 45MHz glitches during my shift. DHARD Y boost turned off (as MIke requested). Wind speed coming below 20 mph. Several small earthquakes throughout the shift.
INCOMING OPERATOR: Patrick
ACTIVITY LOG:
18:07 Jodi to high bay area looking for contamination control stuff. Still observing.
18:14 Jodi out
19:08 Switched the ifo to Commissioning to turn off the DHARD Y boost filter.
19:09 Back to Observing
22:33 A big tour group starting to march in the control room. ~20 adults. There was also a 5.1M earthquake at Pacific-Antarctic Ridge arrving at about the same time so there were glitches in DARM during the time. Just in case anyone wants to look into outreach noise.
22:46 Group leaving.
23:00 Handing off to Patrick.
TITLE: 09/26 [EVE Shift]: 23:00-07:00 UTC (16:00-00:00 PDT), all times posted in UTC STATE Of H1: Observing at ~71 MPc OUTGOING OPERATOR: Nutsinee QUICK SUMMARY: Lights appear off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell from the camera if they are off at mid Y. Seismic in 0.03 - 0.1 Hz band is coming down from a small peak to ~.7 um/s. Seismic in 0.1 - 0.3 Hz band is around .09 um/s. Wind speeds are less than 20mph, may be coming down.
The LIGO-Caltech systems folks have set up a dedicated account for GWIstat and the associated processes that Chad set up to feed it information about the LIGO detectors, running on the ldas-grid machine at Caltech. The new URL for the GWIstat display is https://ldas-jobs.ligo.caltech.edu/~gwistat/, and it does not require ligo.org authentication any more. The old URL now redirects to the new URL. (At least I think so -- let me know if you run into any problems.) Due to moving GWIstat to its new location, the durations of the current observing segments are not reported correctly.
Parameters:
GPS Start Time = 1127247535 # Beginning of time span, in GPS seconds, to search for injections
GPS End Time = 1127333935 # Ending of time span, in GPS seconds, to search for injections
Check Hanford IFO = True # Check for injections in the Hanford IFO frame files.
Check Livingston IFO = True # Check for injections in the Livingston IFO frame files.
IFO Coinc Time = 0.01 # Time window, in seconds, for coincidence between IFO injection events.
Check ODC_HOFT = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in HOFT frames.
Check ODC_RAW = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in RAW frames.
Check ODC_RDS = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in RDS frames.
Check GDS_HOFT = True # Check GDS-CALIB_STATE_VECTOR channel in HOFT frames.
Report Normal = True # Include normal (IFO-coincident, consistent, and scheduled for network injections and consistent and scheduled for IFO injections) injections in report
Report Anomalous = True # Include anomalous (non-IFO-coincident, inconsistent, or unscheduled) injections in report
All injections found were UNSCHEDULED CBC injections in H1. There were no injections found in L1. All injections were consistent.
Mike asked me to turn it off to maintain the configuration. So I went off observing for a bit to switch off the boost filter. I accepted the change in SDF and back to observing. All this took less than a minute.
TITLE: 09/26 [DAY Shift]: 15:00-23:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Observing. The range fluctuates between ~70-40Mpc most likely due to RF45 glitches.
OUTGOING OPERATOR: Ed M.
QUICK SUMMARY: RF 45MHz has been glitching. Wind speed seems to be increasing (now ~30 mph). Seismic activity in earthquake band increasing coresponding to the wind speed. Last earthquake report from Terramon was about an hour ago.
TITLE: Sep 26 OWL Shift 23:00-07:00UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Observing
LOCK DURATION: Entire Shift
SUPPORT: Mike Landry
INCOMING OPERATOR: Nutsinee
Activity log:
13:59 After tweaking, 45Mhz RFAM held stable for ~15 minutes. Still glitching but not as frequently.
14:05 looks like a quake is incoming. Engaging Sheila’s DHARD_Y boost.
14:25 Wind on the X arm is picking up to around 16 to 20mph.
14:28 accepted DHARD_Y boost change in SDF and going to go back to observing.
14:31 Intent bit set to Undisturbed
End-Shift Summary: Last half of my shift has been dominated by a continuing loss of range due to constant low frequency glitching in DARM. Mike visited me and we realized that it was the 45Mhz RFAM issue. We toggled the gain a bit as per Stefan’s aLog and then reverted it back. This seems to have lessened the occurrences although it will still happen sporadically. IFO was locked for the entire shift. ETMY glitched twice around 08:00UTC and didn't glitch again for about 4 hours. Then they came at the typical frequency. Mexican EQ showed on the graph so while we were out of Observing I switched on Sheila’s DHARD_Y boost and accepted the change to be able to return to Undisturbed. Neither Terramon nor the USGS site showed the quake before our graph did. nice. Handing off to Nustinee.
Now that the multi-processing version of HWInjReport is operational and returning results (multi-processing code is an absolute bear!), this is the first of daily reports of analysis of output from HWInjReport. Currently, HWInjReport still has to be run manually and requires one to checkout the current schedule file from the SVN (currently at https://svn.ligo.caltech.edu/svn/dac/hwinj/Details/tinj/schedule; if this has changed, please let me know so I can modify the run script appropriately). Automatic execution of HWInjReport is soon to come. I've attached copies of the output report file and the schedule file used. NOTE: the report file is very wide due to the number and size of the columns in the network injections tables of the report. To examine the report, you will need to either zoom out or change the font size in your browser/text editor to 10pt or less (I'm looking into compressing the columns in the network injections tables in future updates).
The daily run performed with the following parameters:
GPS Start Time = 1127163296 # Beginning of time span, in GPS seconds, to search for injections
GPS End Time = 1127249696 # Ending of time span, in GPS seconds, to search for injections
Check Hanford IFO = True # Check for injections in the Hanford IFO frame files.
Check Livingston IFO = True # Check for injections in the Livingston IFO frame files.
IFO Coinc Time = 0.01 # Time window, in seconds, for coincidence between IFO injection events.
Check ODC_HOFT = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in HOFT frames.
Check ODC_RAW = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in RAW frames.
Check ODC_RDS = True # Check ODC-MASTER_CHANNEL_OUT_DQ channel in RDS frames.
Check GDS_HOFT = True # Check GDS-CALIB_STATE_VECTOR channel in HOFT frames.
Report Normal = True # Include normal (coherent, consistent, and scheduled) injections in report
Report Anomalous = True # Include anomalous (incoherent, inconsistent, or unscheduled) injections in report
NOTE: coherent -> coincident. Missed changing that in the code where it outputs the report.
The schedule file only has injections spanning 1125280499 - 1126450499. This is outside the range of times checked by HWInjReport, so there are no occurring or non-occurring scheduled injections reported.
No normal injections, as defined above for HWInjReport, were reported for the network injections. All injections found were reported as UNSCHEDULED, and all injections occurring were reported as CBC injections.
Two H1-L1 coincident injections were found: CBC 1127175853.757(H1), 1127175853.764(L1) and CBC 1127179822.757(H1), 1127179822.764(L1). Both injections were reported as UNSCHEDULED but, otherwise, had no other reported anomalies.
H1 had only 1 single-IFO injection, CBC 1127173426.757 (the report file shows 3, but only 1 is actually an H1-only injection. There is apparently a bug due to the multi-processing code that is not propagating the association of the other 2 injections with their corresponding L1 injections. It's basically a problem of how memory works for a multi-processing environment.)
L1 had 5 single-IFO injections:
The first three injections have the anomaly that they occur in the ODC hoft and GDS hoft frames but not in the ODC raw or ODC rds frames. The remaining 2, other than being UNSCHEDULED, had no other anomalies reported.
ADDENDUM: I was able to successfully fix the data propagation bug. I've attached a copy of the resulting "fixed" report that correctly shows the single-IFO injections for H1 and L1.
Peter Shawhan and I examined the anomalies more closely and found they are not anomalies. The missing injections in RAW and RDS for L1 do actually occur, but HWInjReport missed them. My current working hypothesis is that the code missed these injections because of how it has to separate the list of files to pass to FrBitmaskTransitions into chunks of no more that 4090 files. This is to prevent the number of arguments passed to FrBitmaskTransitions, one for each file, from exceeding the number of arguments supported by the OS (I actually ran into this issue at one point with the RAW frame files). HWInjReport merges the output from the chunks into a single continguous internal list, however, it currently is not accounting for the occurrence doubled transitions (two "off" or "on" transitions consecutively placed) during the process of merging the transitions internally. This may cause the code to become misaligned when finding the injections, based on the bit transitions, and so it completely misses it.
I am reasonably convinced this is the case because when I performed a run on a time-span around the anomalies, 1127162120 - 1127162970, the anomalies do not occur. But, this is because the list of files is much smaller and only needs one chunk, instead of several, to be passed to FrBitmaskTransitions.
This also brings another point which is that I need to include all the output files, the report generated, the schedule used, and the log file when I upload files with my alog summaries of HWInjReport, because the log file has a lot of information regarding the internal activity to HWInjReport. I built it that way because the code has some unexpectedly complex logic in places, which has made debugging a total bear, and it only got worse with the transition to multi-processing.
I just realized there is another bug in HWInjReport, though this one is somewhat benign. While HWInjReport is specified to cover only a certain time-span, it actually ends up covering a larger time-span due to the fact that FrBitmaskTransitions processes entire frame files and HWInjReport is processing the resultant transitions into injection events. This means that HWInjReport can receive from FrBitmaskTransitions a set of transitions that lie well outside the specified time-span and, consequently, generate injection events that lie outside the time-span. It does not have this issue with the scheduled injections, because it trims those to the specified time-span before doing any further processing. The fix, fortunately, is simple: just trim the transitions from FrBitmaskTransitions to within the specified time-span. However, the bug does have the effect of potentially creating injections just outside the beginning or ending of the specified time-span that are flagged as UNSCHEDULED, because the scheduled injections to which they may correspond were trimmed.
14:31UTC Intent bit set to Undisturbed
Ed, Mike L
13:50UTC addressing RF45 AM issue that has been ongoing for about 4.5 hours. Mike L and I decided to try a reduction in the LSC-MOD_RF_45_AM gain by 1dB to as per Stefan's aLog https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21716
Mid-Shift Summary: IFO Locked @ 64Mpc (lower than normal due to funny business visible in DARM). No obtrusive Seismic or wind activity. 2 ETMY glitches. Some increasing activity in the lower DARM frequencies are causing drops in range. It just keeps bouncing up and down (see screenshots) Is this a combination of bounce and roll modes ringing up? This was the same activity that I noted in my transition summary. Is it from anthropogenic noise?
So this was due to the 45Mhz RFAM issue that H1 has been experiencing. With Mike L's help, I got an education on what it is and how to try and tame it in the days prior to it being rectified once and for all.
Please disregard the alog. Mike just told me that GraceDB working was coincidence with Dave restarting the Python script. It wasn't me...