This afternoon we had 2 more locklosses due to the instability at 1.88 Hz which we have struggled with for a few weeks.  (31707) 

This time Keita and I looked at the filters for the soft loops, and saw that we have some kind of plant inversion from a long time ago that has a complex pole at 1.83 Hz, which was giving us 15bB of gain there unnecessarily. (reminder, the soft loops generally have bandwidths of a few hundred mHz, except for CSOFT P which needs to have gain at 0.5Hz to supress our dPdtheta instability).

We turned off these invY filters, and saw that the noise at 1.88Hz in several of our YAW ASC loops was reduced.  For the soft yaw loops, the peak at 1.88Hz was reduced by about 20dB (in the attachment, dashed lines are from last night's undisturbed lock stretch, the solid lines are from the last lock where the invY filters were off.)  There is still clearly extra noise at 1.88 Hz, so something else may be nearly unstable. 

I've scheduled a coherent bbh injection for 3:00 UTC as part of the end-to-end test. 

The schedule file (schedule_1163473217.txt) was modified and checked into the svn (https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/inj_trans/). I logged into each site's hardware injection machine (l1hwinj1 and h1hwinj1) and checked out the updated schedule file (/usr/local/home/hinj/Details/inj_trans). I then reloaded the INJ_TRANS guardian at each site. At LHO EvanG checked that the guardian was ok, he had to change the request to INJECT_SUCCESS (i forgot to check this).

Here is the new line in the schedule file:

1163905217 H1L1 INJECT_CBC_ACTIVE 1 1.0 Inspiral/{ifo}/coherentbbh7_1126259455_{ifo}.out

Each IFO will need to be in observation intent mode for the injection to go through.

J. Kissel
WP 6338

We've implemented the same bug fix to the CAL-CS front-end model that LLO has that connects the H1:CAL-CS_TDEP_DARM_LINE2_DEMOD_OSC into the sum for calibration line output of the CAL-CS model, shipped over to the OMC model to be added in just after the LSC-DARM banks. This oscillator is occasionally used for testing, so we need it hooked up. 
Check out LLO aLOG 29521 for screenshots of the model change.

This change merely required an svn update of the 
/opt/rtcds/userapps/release/cal/common/models/
CAL_CS_MASTER.mdl
to absorb the changes that Joe has already made, followed by an installation and restart of the h1calcs model. No DAQ restart was required, but the DAQ was restarted for various other changes made this morning.

J. Kissel, 
ECR E1600340
II 6665
WP 6338

I've installed the infrastructure that allows for control of the IFO's DARM DOF with either (or both) PCALs as designed by LLO (see LHO aLOG 29509). Unfortunately, because this was implemented quickly -- this is not decided in the LSC output matrix, but a combination of gains downstream. 

This change required an update to the common library part,
    /opt/rtcds/userapps/release/cal/common/models/PCAL_MASTER.mdl,
modifications to both PCAL model's top-level
    /opt/rtcds/userapps/release/cal/h1/models
    h1calex.mdl
    h1caley.mdl,
and a DAQ restart after installation and restarts of both end-station cal models. 
Also, I've updated the PCAL_END excitation screen,
    /opt/rtcds/userapps/release/cal/common/medm/PCAL_END_EXC.adl
However, I discovered that the PCAL overview 
    /opt/rtcds/userapps/release/cal/common/medm/PCAL_END.adl
also need modification to pass down the correct macro variables from that it received from the SITEMAP. Otherwise the new path to the new PCAL_DARM filter bank was ill-defined and wouldn't open. I've committed the changes to the top level models, as well and the PCAL overview screen in there respective locations in the SVN.    

For now, to transition from using ETM DARM control to PCAL DARM control, one should leave the LSC output matrix pointing to the correct end station's QUAD, but zero the 
H1:SUS-ETM[X/Y]_L3_ISCINF_L_GAIN (i.e. the first longitudinal input to the SUS), and turn on that end-stations PCAL DARM control bank, H1:CAL-PCALY_DARM. Of course, you have to design the appropriate filtering to account for the difference between the ESD drive and PCAL drive, which I have not yet done.

Krishna

I recentered the c-BRS based on a visual inspection of the instrument. The two interferometer arm-lengths were mismatched on the order of ~1 mm and were accordingly adjusted. The differential tilt signal may show some improvement, assuming it is not limited by other noise.

I have also been investigating the excess low-frequency signals in c-BRS by comparing it to a host of nearby sensors. So far, the likely suspect appears to be air pressure, though I don't yet understand the mechanism for the effect. I'll fill in more details tomorrow.

I have restarted the DCS Disk2Disk processes writing to archive at LHO with,

 set CHECK_SOURCE_MD5SUM 1

in the Disk2Disk .conf files, so that the CDS .md5 files are now compared with the md5sum found by Disk2Disk before the file gets copied to the LDAS archive. (The file must also pass FrCheck to be copied, as before.)

Evan, Dave

the CW hardware injection has not been running since the restart of the h1calex model at lunch time. Via monit, I restarted this process and it looks like the injection is running again.

J. Kissel for S. Karki

I've moved the roaming calibration line to its highest frequency we intend to go, and it's also the last super-long duration we need. We may run through the lower frequency points again, given that (a) they need much less data, and (b) those data points were taken at various input powers that will likely confuse/complicate the analysis. Below is the current schedule status.

Current Schedule Status:
Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 11 2016 21:37:50 UTC    Nov 12 2016 03:28:21 UTC      ~several hours @ 25 W
1501.3       35k                      02:00                   39322.0           Oct 24 2016 15:26:57 UTC    Oct 31 2016 15:44:29 UTC      ~week @ 25 W
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC    Oct 24 2016 15:26:57 UTC      several days (at both 50W and 25 W)
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days     @ 50 W
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days     @ 50 W
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months   @ 50 W
4001.3       40k                      10:00                   39322.0           Nov 12 2016 03:28:21 UTC    Nov 16 2016 22:17:29 UTC      days     @ 30 W (see LHO aLOG 31546 for caveats)
4301.3       40k                      10:00                   39322.0           Nov 16 2016 22:17:29 UTC    Nov 18 2016 17:08:49 UTC      days     @ 30 W          
4501.3       40k                      10:00                   39322.0           Nov 18 2016 17:08:49 UTC    Nov 20 2016 16:54:32 UTC      days     @ 30 W (see LHO aLOG 31610 for caveats)   
4801.3       40k                      10:00                   39222.0           Nov 20 2016 16:54:32 UTC    Nov 22 2016 23:56:06 UTC      days     @ 30 W
5001.3       40k                      10:00                   39222.0           Nov 22 2016 23:56:06 UTC

J. Kissel, C. Vorvick

This morning, during repair of an infrasound microphone in the PEM stay-clear zone the corner station sensor correction STS got an impulse.  Unfortunately sensor correction to the corner-station SEI was not turned off, because it was unclear to those present that these two things would be interrelated. As such, this impulse was sent to the SEI systems and tripped a large fraction of their watchdogs (see LHO aLOG 31735). 

This includes the HAM2 ISI, on which the IMs are suspended. Whenever the HAM2 ISI trips or goes offline, the IMs all move to a new position, regardless of their requested alignment slider values.

This is merely another instance of the on-going issue with the IMs, as reported in
Integration Issue 4698
(note that as of this aLOG I've cleaned up the long and confusing digital paper trail associated with this bug.)

Sadly, we must wait until WHENVENT HAM2 before we can resolve this issue.

Here's how much the IMs moved:

      dP [urad]     dY [urad]
IM1      0.2          0.8             
IM2      31           5
IM3      6            0.5        
IM4      0.5          1
I've attached a 24-hour trend of the position to show this as a function of time. The black vertical line on each plot indicates the time of HAM2 ISI trip. 

Notes:
- From Cheryl's experience, a "large" jump that we need to correct for is 1 [urad] and 5 [urad] for IM1 and IM2/IM3 respectively, thus I've bolded the values in the table that are a large jump. I put "large" in quotes, because to-date, these numbers have just been empirically determined from commissioning experience. Cheryl is working on an analytical quantitative method for determining what is a large move based on metrics of the input faraday like the alignment's impact on the IFI's extinction ratio, etc.

- IM2 and IM3 are those SUS that typically move. IM4 never moves appreciably (so its typically not reported), and indeed that has been a defining bit of evidence in the study as to why IM2/IM3 move.

We've restored their alignment to the most recent out of lock positions as reported by their M1_DAMP_P/Y_IN1_DQ channels (or whatever EPICs versions of those channels you prefer). These must be restored to an out of lock alignment, because IM4 is globally controlled for alignment to follow the IFO when locked, which is decidedly the wrong alignment for lock acquisition.

at 17:35 UTC today, work on the corner station infrasound mic, in the biergarten, close to the ITMY STS caused a corner station trip that included all BSC ISI and HEPI as well as all HAM ISIs (NOT HAM HEPIS). Some suspensions were tripped as well. It is believed that the heavy piece of equipment, replaced onto the ground in the PEM "stay clear" zone is what cause the spike.

Tied the shunt trip main breakers to the thermal protection and E-Stop button in the DAQ room.  Tested that the system trips with either an over temperature condition or pushing the E-Stop Button.

WP 6344

Jim B, Dave B, TJ

Reverted nds2-client software to version 0.12.2 for Ubuntu 12, Ubuntu 14, and Debian8 workstations.

nds2-client-0.13.1 software was causing problems with a python getdata request for 30 seconds of data from 40 seconds ago, and/or multiple channels.  We will characterize this issue a bit more after the holiday to file a bug report.

John Z., Aaron V.

John restarted the primary GDS pipeline at GPS time 1163860820 +- several minutes, and I restarted the redundant pipeline at GPS time 1163887460. The latency was ~5-10 seconds and the CPU usage is ~70%, both usual. This restart picked up gstlal-calibration-1.0.8, which includes these changes:

- Addition of option --kappas-default-to-median to replace rejected kappas with last good median instead of default
- Bug fix to prevent/reduce latencies due to bad dataValid flags
- Addition of option --demodulation-filter-settle-time to allow filter to settle before accepting computed kappas.

A new filters file is also being used. See this aLOG for information on the filters: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31712

(see WP6332)

Also running turbo pump connected to PT180 hardware on dome of BSC8.  Coordinating with PEM folks to see if the IFO commissioning community can live with this noise source for a few days.  If so, we (Vacuum) would then bake the PT180 hardware while being valved-out from the YBM and while being pumped by these temporary pumps.  

Will be leaving these run past the official "Maintenance Day" period so as to see what these look like if/when the IFO is in low-noise.  May need to do some "on/off" tests as per Robert S. 

Jeff K, Kiwamu I, Darkhan T,

Overview

The CAL-CS EPICS records for tracking temporal variations of the DARM parameters have been updated at 2016-11-21 22:03:46 UTC. These values are identical to the ones in LHO alog 31677 from yesterday, i.e. D20161120_H1_CAL_EPICS_VALUES.m and D20161121_H1_CAL_EPICS_VALUES.m are identical.

New values have been accepted in SDF_OVERVIEW.

Details

Following DARM paramemter files were used to calculate these values:

${CalSVN}/Runs/ER10/Common/params/IFOindepParams.conf              r3752
${CalSVN}/Runs/ER10/H1/params/H1params.conf                        r3826
${CalSVN}/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf  r3786

And the DARM model scripts from

${CalSVN}/Runs/O2/DARMmodel/*  r3814

The *.m file with EP1-9 values and the verbose output are attached to this report. All of the files have been committed to CalSVN at

ER10/H1/Scripts/CAL_EPICS/

D20161121_H1_CAL_EPICS_VALUES.m
20161121_H1_CAL_EPICS_VALUES.txt
20161121_H1_CAL_EPICS_verbose.log