Valve stem pointer at its nominal indication and not consistent with the current PID output - most likely a blown fuse in the rack.  Even though Chandra R. and I had stroked the valve between 100% and 0% at the end of the day yesterday and visually confirmed it did stroke, the fuse is still the likely candidate here -> probably a 1 amp when it should be a 2 amp.  I conferred with the operator (Jeff B.) and Keita K. and we agreed to wait until a lock loss or 2 pm. local time whichever occurs first at which point Chandra or I will enter the LVEA and investigate/fix.

03:17 - 03:20 UTC Dropped out of observing to change H1:SUS-PI_PROC_COMPUTE_MODE26_PLL_SET_FREQ to 209.5 (to match H1:SUS-PI_PROC_COMPUTE_MODE26_PLL_FREQ_COUNT_OUTPUT) while damping PI mode 26. Accepted SDF difference (attached).

During the LVEA sweep I changed the H1 PSL make up air speed from 100% to 20%.

Fil and Richard

Verified the cabling for this setup.  Out of the whitening was a 9pin ISC cable 250 which ran to ADC0 AA chassis in ISC-C1 port 7.  It was unplugged from that port and move to ADC5 AA chassis port6 channels 21-24.  We still need to verify operation.

Important note!  The segment numbers I wrote above are incorrect

This morning I checked the signals from the bullseye detector using a scope in the ISC rack, and saw that all 4 channels had a large oscialltion at 52kHz.  I got it off the table and Mark Richard and Fil spent some time in the EE shop, and saw that indeed, attaching a long cable to the detector made it oscillate.  Mark changed the 50 Ohm series resistors to 100Ohms, which fixed the problem.  While we were there Mark also confirmed with a laser pointer that the middle segment is on pin 2 of the connector. 

While the detector was in the shop, Vaishali and I went back to the rack and checked which pins on the input to the whitening chassis showed up as which segments in the digital system.  This was not as I had expected, the correct mapping is in this table: 

Robert and I went back into the PSL and put the detecor back on the table, and removed the lens so that we now have close to equal amounts of power in the center of the bullseye and in the outer ring.  By the time we came out, the alignment seems to have shifted a little.  

Keita checked on the whitening, and it seems to be working OK.  We set dark offsets with the diode unplugged, one stage of whitening on and 24dB of whitening gain.  We didn't measure the dark noise, so if anyone gets a chance to go back in it would be good to both measure the dark noise and try to readjust the alignment. 

I went in to the PSL yesterday, the 14th, during the maintenance period as described in WP6522. I have done the following activities.

• I realigned the beam by steering the mirror in front of the bullseye.
• I uncoiled the 9 pin Dsub cable a bit and gave it an extra 1-meter slack.
• I took some pictures. They can be found at ResourceSpace.

By the way, here is a picture of the bullseye setup.

J. Kissel, on behalf of S. Karki and C. Cahillane.

The data provided by Sudarshan via SLM tool that represents the PCAL clipping actually used by Craig in his systematic error budget for CBC analysis chunks 2 & 3 during O2 -- i.e. from Nov 30 2016 17:09:39 UTC to Jan 22 2017 04:36:04 (1164560996 to 1169094982) --  has been committed to the svn here:
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Results/PCAL/
O2_RxPD_TxPD_factor_dcsready.txt

I attach a .png of the data also committed to the same location.

the last one in the list, wdreset_all.pl, has already been migrated.

Follow the progress on converting these scripts (and/or determining whether they're obsolete/unused) with Integration Issue / ECR Tracker Ticket 7394.

Note - There are several ISI scripts which are written in perl but are not in the list Dave made.
This is because I wrote them a really long time ago, and didn't realize you should add the .pl to the end of the name.
sigh. 
Naturally, these should also be updated into python or deprecated.
Included are v1 guardian scripts in 
/opt/rtcds/userapps/trunk/isi/common/scripts/bsc/
e.g. goto_DAMPED

there is stuff used at build time, e.g.
create_hamisi_payload

and a bunch of other stuff, some useful, some not. Here is the full list of the isi/common/scripts:
BSCISIchecker                    gps_filters
BSCISItool                       gpsget
BSCISItool_old                   ham
BSCISItoolwrapper.sh             hitChannelWithOnes
HAMISIchecker                    makeUserappsBranch
HAMISIchecker.orig               masterSwitchBlendFilters
HAMISIchecker.patch              medm_auto_concat.pl
HAMISItool                       resetWatchdogThresholds
HAMISItoolwrapper.sh             restart_guardians
align_restore_isi                sensor_hilo
align_save_isi                   setCartBiasSetpoints.pl
bsc                              setCartBiasWrapper.sh
buildBranchModel                 setFilterOffsets
check_filter.pl                  storeCartBiasTargets.pl
create_hamisi_payload            storeTargetOffsets.pl
create_hamisi_payload_with_links svnUpMedmDirs
create_isi_payload               svnUpUserappsBuildDirs
ff01off                          switchBlendFilters
ff01on                           wd_dackill_reset.pl
ff12off                          wd_plots
ff12on

Note - I'm a fan of the conversion, just don't want to forget anything

-Brian

There is no requirement that scripts in any language have extensions.  Scripts generally do not have extensions, whereas library files do.  One should not assume that all perl scripts have .pl extensions.  Ditto for python (.py) or bash/csh (.sh).

Sorry, probably my mistake.

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.sh
omicron-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!)