TITLE: 02/22 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 69Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 8mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.18 μm/s
QUICK SUMMARY: Locked for 25 hours. No issues were passed from Corey.
TITLE: 02/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 70Mpc
INCOMING OPERATOR: Travis
SHIFT SUMMARY:
Nice and very quiet shift with nothing to hand off to Travis. This is just how we like it!
LOG:
Still humming along (22+hr long lock). Range dipping with the morning Hanford traffic. Time for lunch.
TITLE: 02/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 69Mpc
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
Wind: 7mph Gusts, 6mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.19 μm/s
Very quiet with useism down at the 50percentile for the last 24+hrs.
QUICK SUMMARY:
Nothing much to pass on. H1 has been locked for 17+hrs with a range at or above 70Mpc. Fundamental violin mode at quiet 2e-19.
TITLE: 02/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 70Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Not much happened. Been locked for almost 17 hours.
Not much going on. Low wind. Quiet seismic. Stable range. One GRB alert which I mistakenly took the INJ_TRANS guardian to INJECT_KILL manually for an hour before I realized that it was already at the correct state (EXTRIG_ALERT_ACTIVE).
Continuation of WP #6472 As found, the CP8 unit was "full" of water. It would have had an electrical short soon had it not been modified. 7 of 8 are done. Only LLCV for CP7 remains to be modified -> I expect to get to it next Tuesday
WP6490 Reroute IRIG-B signals
Dave:
At EX and EY the IRIG-B signals were rerouted from the IRIG-B fanout to the CNS-II GPS receiver. Further work needed to change the IRIGB format.
Investigate LVEA-WAP issue
Carlos:
The LVEA WAP was found to be working correctly. Last week's issue presumably was due to an ethernet cable not fully seated.
WP6493 new h1oaf filters
Heather:
Filters were installed on Monday 20th.
WP6491 Upgrade DMT login machine OS
Carlos, Jonathan:
h1dmtlogin was upgraded from Deb7 (Wheezy) to Deb8 (Jessie)
HWS channels added back to DAQ
Dave:
DAQ was restarted to re-acquire the HWS slow channels via the EDCU
TITLE: 02/21 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY: Fairly light Maintenance Day activities resulted in H1 remaining locked throughout the maintenance period. LVEA was swept shortly after noon PST and we were back to Observing by 20:45 UTC.
LOG: See attached .txt file for the blow-by-blow.
With Kiwamu, we edited the OAF BLRMS display to show the output of H1:OAF-RANGE_SUM_MTRX. Also added a link to H1 aLIGO SITE MAP, under the LSC menu, to jump directly to the OAF BLRMS ranges.
While editing the OAF BLRMS display, we noticed that the BLRMS range contributions were much lower than expected. We realised from 34169 that when the models were restarted, the BLRMS filters had not been restored. While LLO was down at Feb 20 2017 22:54 UTC, we restored the filter settings. We made changes to SDF to update the default BLRMS filter settings.
Remove the dust monitor (#2) from the HAM2 area. The collected data is enough to start looking into the causes of the high particle counts in the PSL enclosure. Dave B. made the necessary software changes for the shutdown, which were incorporated into the DAQ restart.
h1dmtlogin was updated to debian stable (8).
model restarts logged for Mon 20/Feb/2017 - Thu 16/Feb/2017 No restarts reported.
The HWS ITMX,Y channels are once again stable, I have added H1EDCU_HWS.ini back into the DAQ. The DAQ was restarted at 12:12PST to make this change.
WP 6490 At both end stations the IRIG-B source was moved from the IRIG-B fanout (port 8 on top row) to the IRIG-B output of the CNS-II independent GPS receiver. The 0.1 Gain box was moved as well as the bnc-coax cable (needed because the PEM-AA chassis has an internal gain of 10.0 on all channels). The CNS IRIG-B time-code unfortunately is of the old sine-wave, amplitude-modulated type. To convert this to the square-wave, pulse-width-modulation type requires a jumper change on the PCB. We are waiting for an opportunistic time to make this change. Will add this task to WP6490.
Maintenance day was rather light in regards to impact on the IFO as evidenced by remaining locked through the entire maintenance period. Jeff B did a sweep of the LVEA. As of 20:45 UTC, we are back to Observing. The range has deteriorated during the maintenance period and has not fully recovered. Currently we are in the low 60 MPc range.
The range seems to have slowly recovered and were are at the typical O2 range of high-60 to low-70 MPc.
Attached is a list of channels monitored by Conlog with the number of times each changed over the period of one hour this morning. Each of these channels changed more than 600 times in the hour. I will likely remove these from Conlog unless I hear a strong objection otherwise. These should be updated to be written as readonly in the autoBurt.req files. I understand that this would probably require changing the comments in the Beckhoff code that generates them. The motivation for removing these is that Conlog has now used approximately 11% of its available disk space of 2 TB in about 2 weeks and 5 days. A question: What are the guardian channels that end in _WORKER?
guardian '_WORKER' channels provide status of the guardian worker subprocess. They do not need to be tracked by conlog.
The guardian channels that should be tracked by conlog are:
I removed from Conlog the channels in the list.
Went through an updated LVEA Sweep checklist (T1500386) after Maintenance Day activities. Issues/Notes are below (and some photos are attached).
Cleanroom curtains on ISC Tables:
Do we worry about this? Found "mechanical shorts " of curtains contacting various ISC Tables. Below are what I found for curtains/tables and actions taken (if any):
Other Items:
Blip Glitch Set-Up: EXTEND Until End of O2
This is for Robert. We should update the note on this set-up to say "Set-up until End of O2".
Tom Dent, Miriam Cabero
We have identified a sub-set of blip glitches that might originate from PSL glitches. A glitch with the same morphology as a blip glitch shows up in the PSL-ISS_PDA_REL_OUT_DQ channel at the same time as a blip glitch is seen in the GDS-CALIB_STRAIN channel.
We have started identifying times of these glitches using omicron triggers from the PSL-ISS_PDA_REL_OUT_DQ channel with 30 < SNR < 150 and central frequencies between ~90 Hz and a few hundreds of Hz. A preliminary list of these times (on-going, only period Nov 30 - Dec 6 so far) can be found in the file
https://www.atlas.aei.uni-hannover.de/~miriam.cabero/LSC/blips/O2_PSLblips.txt
or, with omega scans of both channels (and with a few quieter glitches), in the wiki page
Only two of those times have full omega scans for now:
The whitened time-series of the PSL channel looks like a typical loud blip glitch, which could be helpful to identify/find times of this sub-set of blip glitches by other methods more efficient than the omicron triggers:
The CBC wiki page has been moved to https://www.lsc-group.phys.uwm.edu/ligovirgo/cbcnote/PyCBC/O2SearchSchedule/O2Analysis2LoudTriggers/PSLblips
I ran PCAT on H1:GDS-CALIB_STRAIN and H1:PSL-ISS_PDA_REL_OUT_DQ from November 30, 2016 to December 31, 2016 with a relatively high threshold (results here: https://ldas-jobs.ligo-wa.caltech.edu/~cavaglia/pcat-multi/PSL_2016-11-30_2016-12-31.html). Then I looked at the coincidence between the two channels. The list of coincident triggers is: ----------------------------------------------------- List of triggers common to PSL Type 1 and GDS Type 1: #1: 1164908667.377000 List of triggers common to PSL Type 1 and GDS Type 10: #1: 1164895965.198000 #2: 1164908666.479000 List of triggers common to PSL Type 1 and GDS Type 2: #1: 1164882018.545000 List of triggers common to PSL Type 1 and GDS Type 4: #1: 1164895924.827000 #2: 1164895925.031000 #3: 1164895925.133000 #4: 1164895931.640000 #5: 1164895931.718000 #6: 1164895958.491000 #7: 1164895958.593000 #8: 1164895965.097000 #9: 1164908667.193000 #10: 1164908667.295000 #11: 1164908673.289000 #12: 1164908721.587000 #13: 1164908722.198000 #14: 1164908722.300000 #15: 1164908722.435000 List of triggers common to PSL Type 1 and GDS Type 7: #1: 1166374569.625000 #2: 1166374569.993000 List of triggers common to PSL Type 1 and GDS Type 8: #1: 1166483271.312000 ----------------------------------------------------- I followed-up with omega scans and among the triggers above, only 1164882018.545000 is a blip glitch. The others are ~ 1 sec broadband glitches with frequency between 512 and 1024. A few scans are attached to the report.
Hi Marco,
your 'List of triggers common to PSL Type 1 and GDS Type 4' (15 times in two groups) are all during the known times of telephone audio disturbance on Dec 4 - see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32503 and https://www.lsc-group.phys.uwm.edu/ligovirgo/cbcnote/PyCBC/O2SearchSchedule/O2Analysis2LoudTriggers/PSLGlitches
I think these don't require looking into any further, the other classes may tell us more.
The GDS glitches that look like blips in the time series seem to be type 2, 7, and 8. You did indeed find that the group of common glitches PSL - GDS type 2 is a blip glitch. However, the PSL glitches in the groups with GDS type 7 and 8 do not look like blips in the omega scan. The subset we identified clearly shows blip glitch morphology in the omega scan for the PSL channel, so it is not surprising that those two groups turned out not to be blips in GDS.
It is though surprising that you only found one time with a coincident blip in both channels, when we identified several more times in just one week of data from the omicron triggers. What was the "relatively high threshold" you used?
Hi. Sorry for taking so long with this. I rerun PCAT on the PSL and GDS channels between 2016-11-30 and 2016-12-31 with a lower threshold for glitch identification (glitches with amplitude > 4 sigma the noise floor) and with a larger coincidence window (coincident glitches within 0.1 seconds). The list of found coincident glitches is attached to the report. Four glitches in Miriam's list [https://www.atlas.aei.uni-hannover.de/~miriam.cabero/LSC/blips/O2_PSLblips.txt] show up in the list: 1164532915.0 (type 1 PSL/type 3 GDS), 1164741925.6 (type 1 PSL/type 1 GDS), 1164876857.0 (type 8 PSL/type 1 GDS), 1164882018.5 (type 1 PSL/type 8 GDS). I looked at other glitches in these types and found only one additional blip at 1166374567.1 (type 1 PSL/type 1 GDS) out of 9 additional coincident glitches. The typical waveforms of the GDS glitches show that the blip type(s) in GDS are type 1 and/or type 8. There are 1998 (type 1) and 830 (type 8) glitches in these classes. I looked at a few examples in cat 8 and indeed found several blip glitches which are not coincident with any glitch in the PSL channel. I would conclude that PCAT does not produce much evidence for a strong correlation of blip glitches in GDS and PSL. If there is, PSL-coincident glitches must be a small subset of blip glitches in h(t). However, some blips *are* coincident with glitches in the PSL, so looking more into this may be a good idea.
Hi,
thanks Marco for looking into this. We already expected that it was a small sub-set of blip glitches, because we only found very few of them and we knew the total number of blip glitches was much higher. However, I believe that not all blip glitches have the same origin and that it is important to identify sub-sets, even if small, to possibly fix whatever could be fixed.
I have extended the wiki page https://www.lsc-group.phys.uwm.edu/ligovirgo/cbcnote/PyCBC/O2SearchSchedule/O2Analysis2LoudTriggers/PSLblips and the list of times https://www.atlas.aei.uni-hannover.de/~miriam.cabero/LSC/blips/O2_PSLblips.txt up to yesterday. It is interesting to see that I did not identify any PSL blips in, e.g., Jan 20 to Jan 30, but that they come back more often after Feb 9. Unfortunately, it is not easy to automatically identify the PSL blips: the criteria I used for the omicron triggers (SNR > 30, central frequency ~few hundred Hz) do not always yield to blips but also to things like https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=156436, which also affects CALIB_STRAIN but not in the form of blip glitches.
None of the times I added up to December appear in your list of coincident glitches, but that could be because their SNR in PSL is not very high and they only leave a very small imprint in CALIB_STRAIN compared with the ones from November. In January and February there are several louder ones with bigger effect on CALIB_STRAIN though.
The most recent iteration of PSL-ISS flag generation showed three relatively loud glitch times:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/hveto/day/20170210/latest/scans/1170732596.35/
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/hveto/day/20170210/latest/scans/1170745979.41/
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/hveto/day/20170212/latest/scans/1170950466.83/
The first 2 are both on Feb 10, in fact a PSL-ISS channel was picked by Hveto on that day (https://ldas-jobs.ligo-wa.caltech.edu/~detchar/hveto/day/20170210/latest/#hveto-round-8) though not very high significance.
PSL not yet glitch-free?
Indeed PSL is not yet glitch free, as I already pointed out in my comment from last week.
Imene Belahcene, Florent Robinet
At LHO, a simple command line works well at printing PSL blip glitches:
source ~detchar/opt/virgosoft/environment.shomicron-print channel=H1:PSL-ISS_PDA_REL_OUT_DQ gps-start=1164500000 gps-end=1167500000 snr-min=30 freq-max=500 print-q=1 print-duration=1 print-bandwidth=1 | awk '$5==5.08&&$2<2{print}'
GPS times must be adjusted to your needs.
This command line returns a few GPS times not contained in Miriam's blip list: must check that they are actual blips.
The PSL has different types of glitches that match those requirements. When I look at the Omicron triggers, I do indeed check that they are blip glitches before adding the times to my list. Therefore it is perfectly consistent that you find GPS times with those characteristics that are not in my list. However, feel free to check again if you want/have time. Of course I am not error-free :)
I believe the command I posted above is an almost-perfect way to retrieve a pure sample of PSL blip glitches. The key is to only print low-Q Omicron triggers.
For example, GPS=1165434378.2129 is a PSL blip glitch and it is not in Miriam's list.
There is nothing special about what you call a blip glitch: any broadband and short-duration (hence low-Q) glitch will produce the rain-drop shape in a time-frequency map. This is due to the intrinsic tiling structure of Omicron/Omega.
Next time I update the list (probably some time this week) I will check the GPS times given by the command line you suggest (it would be nice if it does indeed work perfectly at finding only these glitches, then we'd have an automated PSL blips finder!)
