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.

I made a movie (about a minute long) of DARM over several hours yesterday with a 100 average exponential decay. It takes a couple of minutes to watch and shows that there are bumps, possibly from scattering, that come and go sometimes independently of each other. I say somewhat, because, when the spectrum gets good all of the bumps seem to be gone. There is also a broad background that rises and falls that does not seem to be composed of bumps.

https://ldas-jobs.ligo-wa.caltech.edu/~robert.schofield/DARM100averageExponential.mov

DAQ was restarted to apply three changes:

new DUST monitor (H1EDCU_DUST.ini)

new Guardian node (H1EDCU_GRD.ini)

new h1broadcast0 daqdrc

WP6450

h1broadcast0's daqdrc file was added to the cds_user_apps svn repository, and was then modified to prevent md5 check sum file generation

+# turn off generation of check sum files. DB 24jan2017
+set parameter "write_frame_checksums"="0";
 

change went in on the 11:44PST DAQ restart.

   Checked the pressures and temperatures of the dust monitor vacuum pumps. Both end station pumps are operating within normal parameters. I adjusted the air bleed on the CS pump to accommodate the new dust monitor at HAM1/2. The CS pump temperatures are all normal.

   Closed FAMIS task #7509

   Installed a new pump-less dust monitor between HAM1 and the PSL enclosure. This is a temporary placement to help understand why we are seeing elevated particle counts in the PSL Anit-Room and to a lesser extent in the PSL room as well.  

   The monitor is called Loc-2 and is accessed from the PEM MEDM screen under the LVEA label. Please let Jeff B. know of any alarms.     

Arnaud had sent along some measurements on HAM1, trying to measure the transmissibility from the HAM1 stack to the RM suspensions. I ran these measurments this morning, during the maintenance period. It looks like the LLO and LHO RM damping designs might differ a bit, maybe the LLO damping filter is a bit more aggressive? First image is just the RM1 L plant measurement, it was taken with the RMs both in DAMPED (unaligned) and HEPI isolated (SC was off, but HAM1 uses high UGF, blended (L4C/IPS) loops). The second image is the HEPI X to RM1 L transfer function, which was taken with HEPI in READY and the RMs still DAMPED. Both templates are saved in the SVN in H1/ HAM1/Data/Transfer_Functions/Measurements/Undamped folder.

EDIT: LLO's measurements are the black refs, my measurements are the red. Arnaud reports that the difference is due to an old damp filter design on the RMs, LLO now matches us.

WP 6452

The control room GDS software has been updated to gds-2.17.9-1 for Ubuntu 12.04 workstations.  This adds a leap second to the UTC/GPS conversion routines and fixes bugzilla 1064 (unit strings not read properly from NDS1), bugzilla 469 (improper channel list restriction in ezcademod).  The release also allows users to abort a DTT measurement when waiting to collect data that isn't available yet (part of bugzilla 474), and adds the ability to display units for channels in chndump.

Debian 8 workstations were already at gds-2.17.9-1. This is also compiled for SL6 if the hardware injection software needs it.

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.

Fil called and reported that one of the supplies was tripped upon his arrival.

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.

Evan G., Travis S., Heather F.

Since our previous measurement of the EY Pcal PD calibration had excess noise and glitches associated with other electronics, we made another round of measurements to verify the calibration of the Pcal PDs (see LHO aLOG 33392).

This time, we made sure that no other electronics were plugged into our supply, which resulted in better measurements and more accurate calibration, see attached figures. The peak-to-peak variation on the working standard (WS) measurements is ~4x smaller.

We find that that the calibration of the PDs is consistent with measurements made at the start of O2 to <=0.8% (see attached PDF). This appears consistent with historical variations made over the past 1.5 years. As additional measurements of the Pcal PDs are made, we will better constrain the variation in these measurements.

Finally, note that in early November 2016, we transitioned to a new working standard, so there is an offset in calibration values attributed to a new working standard PD responsivity.

Remotely from the control room, I tweaked the beam alignment into the PMC; this was done with the ISS OFF.  The power transmitted by the PMC increased to ~66.3W, and the power reflected decreased to ~13.8W.  With the ISS back ON the PMC is transmitting ~63.3W and reflecting ~13.8W.

Also in the WP, the PSL ODC bit 12 (PMC Transmission Limit) was already set to 50W, so no change was made by me today.

While doing this, I reset the power watchdogs for the 35W FE laser and the HPO (FAMIS task 3634).

This closes LHO WP 6444.

The controller unit was powered down and disconnected to change its output to 5.6 kV from 7.0 kV, did a re-configuration/calibration after via the front panel.

Cable was reconnected and the controller powered back up, attached is pressure trend of near volumes to X2-8 (2 hours).

Per WP#6447

17:40 Due to exemplary siesmic isolation efforts, work being done around HAM2 has failed to cause lockloss! So I've manually broken the lock to afford others the opportunity to work.

Looks like the CO2Y laser lock point may be lost due to small jumps in the current that kicked the pzt out of its place.  This is the first time I've seen such behavior (for myself anyway). This TCS guardian node is currently tied to the intent bit and can potentially kick us out of observe.