05:32 UTC Just like last night, nothing's obvious on the FOM. No runaway signal that I can see. The range was stable. The IFO just dropped lock.

I was tasked by Sheila to find out which of the 1st violin mode harmonics are consistently rung up. We were hoping to see just a few modes that like to ring up so we can have the guardian damp them automatically. However, pretty much everything in 1kHz rings up over time (also true back in O1). Some of the lines seem to be ringing down on their own and some don't. Because we only have 2-3 free violin filter banks per test mass I chose to damp some of the lines that are high and don't ring down on their own. The lucky frequencies that will be damp automatically by the guardian are:

[ITMX]

992.42Hz -- MODE9: FM8(BP), FM2(-60deg), FM4(100dB), -10gain

994.27Hz -- MODE10: FM5(BP), FM2(-60deg), FM4(100dB), -10gain

[ITMY]

994.65Hz -- MODE9: FM8(BP), FM2(-60deg), FM4(100dB), +10gain

998.81Hz -- MODE10: FM8(BP), FM2(-60deg), FM4(100dB) -10gain

[ETMX]

1003.67, 1003.78, 1003.91 -- MODE10: FM1(BBP), FM2(-60deg), FM4(100dB), +30gain -- Luckily the phases work out such that I can make a broader bp filter that covers all three lines. I wish to make more of these for other test masses but they weren't as straight forward.

1004.54 -- MODE9: FM9(BP), FM2(-60deg), FM4(100dB), +10gain

[ETMY]

1009.44, 1009.49 -- MODE1: FM6(BBP), FM4(100dB) +15gain (these two lines are generally the highest of 1k violin amplitude. I don't want to crank up to the gain too much. Just let them damp slowly, safely, and surely)

With permission from Keita I took the IFO out of observing briefly to test all the settings (LLO was down), wrote them in the ISC_GEN_STATES.py, and accepted the differences in the SDFs. I haven't hit the load button yet. I hit load button after a lockloss.

Note: BBP = Broad Band Pass filter (not that broad, actually, just broader than usual)

J. Kissel

I've taken a new set of calibration measurements that can be used to help track the slow changes in the sensing function over time. The goal is to have a set of these measurements once every few weeks over the course of the run to eventually build up enough of a data set that we can compare the results against the parameter tracking from calibration lines -- specifically the SRC detuning spring frequency and Q, which we're currently not tracking.

The new data live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/SensingFunctionTFs/
   2017-01-24_H1DARM_OLGTF_4to1200Hz_25min.xml
   2017-01-24_H1_PCAL2DARMTF_4to1200Hz_8min.xml
   2017-01-24_H1_PCAL2DARMTF_BB_5to1000Hz.xml

These do *not* need to serve as a new set of reference measurements, given that we've only changed digital filters today (see LHO aLOG 33585).

The broad-band (BB) PCAL2DARM transfer function was in the spectrum from Jan 23 2017 23:09:32 UTC for a minute or so (50 averages, 75% overlap, 0.5 Hz BW), so this can be used to verify the GDS pipeline output as well.

More detailed analysis of the sweeps to come.

With Jenne and Krishna's approval, I added a couple of steps to ISC_LOCK to reduce the chance that BRSX will engage damping while we are locked. In the DOWN state I added an ezca call on line 218 to set the BRS damping upper limit to a level lower than we usually run:

        ezca['ISI-GND_BRS_ETMX_HIGHTHRESHOLD'] = 1000

On line 1098 (TURN_ON_BS_STAGE2) I reset this value to the normal run value:

        ezca['ISI-GND_BRS_ETMX_HIGHTHRESHOLD'] = 2000

If either of these states cause a problem relocking, the on shift operator should just comment both of these lines out. Then check on the BRSX overview that the damp threshold value has been set to 2000. If it's still at 1000, you can use a caput in terminal or right click --> probe --> adjust to set it to 2000.

restarted immediately.

Background - 
The site's roughing pumps haven't been run for a few years and are to be re-purposed as standby "Beam Tube Roughing Pumps" (BTBPs) in the near future.  The plan is to run one (of 6) during each of the next five consecutive maintenance days as a demonstration of their functionality.  Following this, they will be brought up to current maintenance and relocated to the LVEA on or around the Beam Tube building penetrations.

Today - 
EDP200 s/n CSM1165
Oil level good but dirty -> no action required at this time.  Internal coolant 12 fluid oz. low - Added 12 fluid oz. of 50/50 mix of distilled water and Drystar coolant w/rust inhibitor.  Installed modified ASA blank to cap inlet.  Modification included tapped hole allowing addition of a mechanical vacuum gauge and 1/4" ball valve for gas admission.  Ran pump for 1 hour with the only load being 2 LPM of UHP GN2.  Pump ran quiet and achieved operating temperature; pressure < 29" Hg - no problems with this unit.  
 

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):

• Curtain contacting top of IOHT2L  -->  Resuspended curtain so it's no longer touching top of Enclosure
• Entire row of curtains resting on top of ISCT6  -->  Jeff B helped me roll these up and suspend them above ISCT6, so there is no longer contact.
• Curtains contacting cables on north side of IOHT2L, southside of ISCT1, & TCS table  --> NO Action Taken
• Curtain contacting top of IOHT2R  -->  NO Action Taken (since we don't use this table for operations).

Other Items:

• Speaker has long wire connected to it  -->   Reckon this must be for injections & is probably a known set-up.  Just wanted to make a note of it.
• "Blip Glitch" set up at HAM6 elec rack (set up for Sept-Dec 2016)  -->  This is a set up inside still connected inside the HAM6 Elec Rack.  Since Dec2016 is expired, do we still want to keep this set up?
• LVEA Hi-Bay Card Reader found OFF  -->  With Robert stating these Card Readers do not pose an a noise issue to H1, Landry asked that we keep Card Readers ON, so I turned this one on (note:  the reader with the switch for this particular one is in the LVEA).

WP6451 Dave:

The cell phone text alert system was modified to:

1. restore the actual pump level for CP4

2. annotate the daily messages with the error status for each channel

I restored CP4 and its ERROR channel in the h0ve alarm configuration file.

I modified the epics_alarm_texter.py code so each daily text for cryopump and vacuum gauge status shows the corresponding ERROR status of each value. The ERROR status is a single character following the value:

SPACE means no error

"!" means error

"?" means error channel data unavailable

Today's vacuum gauge text is:

2.602e-09  1.907e-09  1.365e-09  1.624e-09  
2.434e-09  9.976e-10  1.203e-09  1.317e-09  

spaces following the numbers means no errors

Today's cryopump text is:

cp1=92.0  cp2=92.0  cp3=-1.0? cp4=0.0! 
cp5=92.0  cp6=92.0  cp7=92.0  cp8=92.1  

CP3 has a value -1.0? which means both the value and the error are unknown (this is currently not monitored by the system)

CP4 has a value of 0.0! which means we are receiving a value of 0.0 but the ERROR channel is asserted (4-20mA current below 4mA)

Borja has continued working on his analysis of signals sent to the suspensions after locklosses, (see 23831), he is working on another alog with the current results.  

After his original log, I made some changes to the ISC_LOCK down state to make it more efficiently turn off loops, and removed some things that were shutting of DRMI loops in the ISC_LOCK guardian, becuase those loops are also handled in the ISC_DRMI guardian.  However, what was done in ISC_DRMI wasn't turning everything off.  Today we tried to make similar edits to ISC_DRMI to make sure it was efficiently turning off ASC and LSC feedback to the suspensions.  We have tested this once, and fixed one error.  The new code is very slow to complete, ten times slower than extremely simlar code in ISC_LOCK, and takes a total of 19 seconds to finsh turning things off.  Since we don't understand why this code should be slower, we filled a bug 1068  The currrent svn revision of ISC_DRMI is 14928 

For now we are leaving the new, slow code in place because at least we think it is better than the old code which was also slow. 

Attached script checks any jumps for ITM M0 TEST outputs (e.g. when operators run initial alignment) and L2 witness monitors (or oplev) starting 09/Jan/2017 UTC for 14 days. It calculates DC "response" in urad/urad, as in angle measured by witness (or oplev) per angle offset of M0.

In the attached, just look at middle two panels. Second panel from the top shows the DC "response" for both ITMX and ITMY, and you can clearly see that ITMY startted to act erratically after Jan 15 2017 10:30:00 UTC or so, and it was fixed as soon as the vertical offset was applied to push the optic up (third panel from the top).

Seems like V=-65.7um is the threshold for ITMY to rub something. Interestingly, when ITMY rubs, YAW is constrained but PIT moves more in DC. Also, since the vertical offset was applied, ITMY has slowly drifted back up by about 30um, probably due to temperature change.

Unfortunately this doesn't show anything about CPX because the M0 offset only acts on ITMX chain, not CPX.

THis morning I took the weekly ETM charge data set.  Unfortunately I did not put 2-and-2 together that Beckhoff EX issues may have caused problems with the SUS ETMX HV power supply while I was running the measurement of ETMX, so its data has a bit of a large error bar.  Even so, it mostly looks like things are OK there wrt charge accumulation (or lack thereof!).  All looks good at ETMY as well.

J. Kissel, S. Dwyer
WP # 6448

I've installed the improved 4.7 kHz elliptic bandstop notch in FM3 of the DARM2 bank, as designed yesterday (see LHO aLOG 33546),
    User Model     Bank Name        Filter Module       Name             Design String
    H1OMC          H1:LSC-DARM2     FM3                 "not4735.25"     ellip("BandStop",4,1,80,4720,4750)gain(1.12202)
The filter file has been committed to the userapps repo, 
    /opt/rtcds/userapps/release/omc/h1/filterfiles/H1OMC.txt      (r14921)

Because this filter bank in unmonitored by SDF, yet under guardian control, we've ensured that this filter is always on by hard-coding the filter to be always on into the DOWN state of the ALS_DIFF.py guardian (line 112)
    /opt/rtcds/userapps/release/als/common/guardian/ALS_DIFF.py   (r14918)
which has been committed.

Calibration impacts:
Both the CAL-CS (which produces DELTAL_EXTERNAL) and the GDS (which produces GDS-CALIB_STRAIN) time-independent portions of the low-latency calibration pipeline are unaffected by changes to the DARM filters. However, the calculation of time-dependent correction factors (TDCFs) involves correcting for the entire DARM loop frequency dependence between calibration lines. Thus as the change to the DARM filter banks changes the DARM loop, it impacts the computation of the TDCFs, which impacts h(t). See T1500377 for details of the calculation.

That being said, the improvement in to notch reduces this impact at the calibration line frequencies to negligible. However, for completeness, traceability, reproducibility, and sanity's sake, we update the calibration model in order to account for this new filter. 

Calibration update process:
Here're the steps to ensure that the calibration has been updated to reflect the change:
- Copy the updated OMC filter file from the chans archive to the copy of the archive in the CalSVN and commit,
    ]$ cp /opt/rtcds/lho/h1/chans/filter_archive/h1omc/H1OMC_1169320184.txt /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1omc/H1OMC_1169320184.txt
- Create a new IFOparams.conf and corresponding IFOparams_YYYY-MM-DD.conf configuration files in the CalSVN,
    ]$ cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/params/
    ]$ svn mkdir 2017-01-24
    ]$ svn commit -m "" 2017-01-24
    ]$ cp H1params.conf 2017-01-24/     #note that the H1params.conf file in the top level of the O2/H1/params/ folder is the 2017-01-03 reference model (LHO aLOG 33004)
    ]$ cp 2017-01-03/H1params_2017-01-03.conf 2017-01-24/H1params_2017-01-24.conf
- Update IFOparams.conf file to point to the newly updated H1OMC filter file in the variable DfilterFile, and make sure the DfilterModulesInUse2 is calling out that the new filter is on in FM3, and commit to the repo.
- Make a new CAL_EPICS parameter file that points to the new reference model,
    ]$ cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/CAL_EPICS/
    ]$ cp callineParams_20170103.m callineParams_20170124.m
- Change par.conf.ifoDepFilename and par.conf.ifoMeasParams to point to IFOparams.conf and corresponding IFOparams_YYYY-MM-DD.conf
- Use 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/CAL_EPICS/writeH1_CAL_EPICS.m
  to create and install new EPICs records. Be sure to update the par0 that calls the above mentioned callineParams_YYYYMMDD.m
- Accept the new records in the SDF system for both safe.snap and OBSERVE.snap, and commit
    /opt/rtcds/userapps/release/cal/h1/burtfiles/
    h1calcs_safe.snap
    h1calcs_OBSERVE.snap.

This process generates the following output for offline DCS consumption, and represent the new calibration model applicable for all lock stretches beyond 2017-01-24 20:00 UTC:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/params/2017-01-24/
    H1params.conf                    (r4212, lc: 4212)
    H1params_2017-01-24.conf         (r4212, lc: 4212)

    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/CAL_EPICS/
    20170124_H1_CAL_EPICS_VALUES.txt (r4215, lc: r4215)
    D20170124_H1_CAL_EPICS_VALUES.m  (r4215, lc: r4215)
    
Because it's about time we take a new set of calibration suite measurements, I'll take a set later today and compare against this new model.

Laser Status:
SysStat is good
Front End Power is 34.06W (should be around 30 W)
Front End Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 2.0 days, 17.0 hr 57.0 minutes (should be days/weeks)
Reflected power is 13.65Watts and PowerSum = 77.54Watts.

FSS:
It has been locked for 0.0 days 0.0 hr and 11.0 min (should be days/weeks)
TPD[V] = 2.413V (min 0.9V)

ISS:
The diffracted power is around 3.6% (should be 3-5%)
Last saturation event was 0.0 days 0.0 hours and 41.0 minutes ago (should be days/weeks)

Possible Issues:
(Be sure to look into these, as they will not be printed in the report)
PMC reflected power is high
 

Note: See attached screenshot of the PMC Refl power for the past month.  It has been reported as being high for the past 2 weeks (see Corey's aLog 33378).  Is this due to some adjustment by the PSL team and we should update our weekly script with a higher nominal value, or is this a real issue?

This completes FAMIS 7422.

TJ & Hugh--Re WP 6286

Successfully modified the Guardian Parameters to just restore the non-pringle-mode target positions:

from isiguardianlib.isolation.const import ISOLATION_CONSTANTS
ISOLATION_CONSTANTS['CART_BIAS_DOF_LISTS'] = (['Z','RX','RY'],['X','Y','RZ'])
from isiguardianlib.HPI import *
prefix = 'HPI-HAM6'
ca_monitor = True

The top two lines of the HPI_HAM6.py code above are the modifications.

However, it does not sequence things quite as we would like: it completely restores the vertical dofs before even starting the isolation of the horizontal loops.  Although this platform did not have difficulty completing the isolation, it is reasonable that some platforms could have trouble as it isolates the horizontal dofs after it has driven the vertical dofs to their target position.  If those targets are extreme or whatever enough, the error point of the horizontal loops may be too large for the loops to engage stabily.  The preference would be for all the loops to be running before any of the target positions are restored.

We'll look into changing the sequence more to our preference but TJ feels it could be complicated or at least deeper into the code.  WP remains active.

I created and started Nutsinee's TCS_RH_MON node that will monitor the TCS Ring Heaters. There were no issues creating it and it seems to work as it should.

It has been added to the GUARD_OVERVIEW.adl as well under TCS.

I updated (userapps)/cds/h1/scripts/check_guardian_nodes_against_medm_screen.bsh to use the the more up-to-date guardian client command to get the nodes. All nodes are on the overview.