Sheila, Jenne, Mark, Richard, Fil, Daniel

We made some progress on installing a prototype of the bullseye detector that Mark has been building in the PSL today. 

• Jenne and I went into the PSL and realized that the location I ha orignally thought of for the diode wouldn't work.  After dicussing it with Jason we deicded to move aside the beam profiler in the DBB HPO path and put the diode there.  There was about 0.65 mW of power in this path.  Jenne added a steering mirror (Y1) and a diverging lens (PLCC-25.4-103.0-UV-1064).  To install the diode we had to remove the rail that was on the table, we placed it on the portable cart on the oposite side of the enclosure. 
• We used a temporary adapter cable that Mark made that allows us to power the diode from the power strips under the table and get the signals out onto a DB9.  We used a breakout board to display the segments on a scope while we were in the enclousre.  Based on watching the signals while we steered the beam around, we think that the segments are arranged like this:
  • pin1 pin6 (seg 1) side of the diode closer to the anteroom
  • pin 2 pin 7 (seg 2) center
  • pin 3 pin 8 (seg 3) side of diode closer to HAM1
  • pin 4 pin 9 (seg4) bottom of diode
• We decided to use the unused half of the MC2 trans QPD whitening chassis for this diode.  Fil made an adapter cable that we could use to get the MC2 signals from the 25 pin Dsub from the transimpendance amplifier and the bullseye signals off the 9pin Dsub that comes out of the PSL into the whiteing chassis. (The 9 pin  cable reaches, but next time someone is in the PSL we could uncoil a little more from under the table). 
• The whitening chassis already had BIO, but there was no beckhoff code for the spare hardware.  Daneil added this, and named the whitening PSL-SPARE_QPD.  Dave did a DAQ restart for this change. 

We will hopefully get the whitened signals into the ADC channels that are already set aside and connected to AS_D in the ASC model tomorow. 

J. Kissel, S. Kandhasamy

As we begin to produce the systematic error budget for H1's response function, we're looking to figure out how to address the clipping of light going into H1 PCAL Y's RX PD that had been revealed in early January (see LHO aLOG 33108 and 33187).

Because we got extremely lucky and took the 2017-01-03 reference measures at a time when the clipping -- which had been found to be slowly varying as a function of time -- had varied briefly back to nominal, this problem does not create any impact on the static, frequency-dependent part of the calibration pipeline. However, because the small, time-dependent correction factors are calculated using the H1 PCALY RXPD, these correction factors are systematically biased. 

Working through the math of T1500377, specifically Eqs. 9, 12, 15, and 16, one can see that while the cavity pole frequency estimate would not be impacted, the scalar correction factors are:
    If 
        x_pcal' = eps x_pcal
    where eps is a real number (the number to convert the apparent displacement, x_pcal, into the real displacement, x_pcal'), then
        kappa_TST' = eps kappa_TST
    and
         kappa_PU' = (1 / A_0^PU) [A_total' - kappa_TST' A_0^TST]
                        (A_total' = eps A_total, from Eq. 11)
                    = (eps / A_0^PU) [A_total - kappa_TST A_0^TST]
                    = eps kappa_PU
    and finally,
                 S' = (1 / C_res) [ x_pcal' / d_err - D_0 (kappa_TST' A_0^TST + kappa_PU' A_0^PU)]^-1
                 S' = eps S
    such that
          kappa_C' = |S'|^2 / Re[S'] = (1 / eps) kappa_C
which means that we can simply scale the entire response function with this time-dependent systematic error:
                 R' = [1 / (kappa_C' C_0) ] + [kappa_PU' A_0^PU + kappa_TST' A_0^TST]
                    = [eps / (kappa_C C_0)] + eps [kappa_PU A_0^PU + kappa_TST A_0^TST]
                 R' = eps R

I attach a 77 day minute trend of the ratio between RXPD and TXPD that's been obtained from data viewer***. I'm not yet advocating that time-series this be used as the representative systematic error, but I post it to be demonstrative. Stay tuned on how this data is encorporated into the uncertainty / error budget.

*** Because it's data viewer, it spits out some dumb Julian calendar time vector. Just subtract off the first value, and you get a time vector in days since the start of the trend, which is Nov 30 2016 00:54:44 UTC.

The data also lives in the CAL repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/PCAL/
    2017-02-14_H1PCALY_RXPD_Trend.txt
    2017-02-14_H1PCALY_TXPD_Trend.txt

The script used to process this data and plot the figure is here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/PCAL/
    plot_h1pcaly_RXvsTXPD_trend_20170214.m

WP6477 Check IRIG-B connections at end stations

Jim, Dave, Daniel:

We went to EY and verified that the IRIG-B signal which is recorded by h1iscex FEC is sent from the IRIG-B fanout. Because it goes into a 10xGain AA chassis, it has a voltage divider installed. Daniel confirmed that this signal should be sent from the CNS-II GPS receiver. In fact I had included this modification in the timing drawings during O1 and was presumably waiting end of O1 to change. We will work on getting this resolved installed ASAP. We did not make it to EY, it should be identical to EX.

WP6478 WAPS power up sends notification to sysadmin

Carlos, Richard:

LVEA and EY CDS WAPs were energized, no notification was received. This is a work-in-progress, will keep this WP open.

WP6475 TCS FLIR camera power control

Richard, Peter:

Verified that the switch inside the TCS enclosure toggles between REMOTE and ON. When in the REMOTE position, the Beckhoff system can turn the camera on and off. Both ITMX and ITMY cameras are in the REMOTE state, and Beckhoff has them turned OFF. We ran out of time to take an image, will start doing this weekly, beginning next Tuesday.

WP6479 DMT GSTLAL upgrade

Greg:

gstlal code was updated on the GDS machines

WP6480 GDS code update

Greg, John Z:

GDS code was updated on all GDS machines

WP6457 remove coil driver BIO from WD, HAM3

Hugh, Dave:

new h1isiham3 code was installed. Now only ham2 is running with the coil driver input to the watchdog.

WP6473 OAF add matrix, fix divide-by-zero

Sheila, Dave:

new h1oaf model was loaded

WP6483 Split corner station HWS server into two for ITMX, ITMY readout

Carlos, Dave:

h1hwsmsr had two camera cards. One is now in the new machine called h1hwsmsr1. While this work is on-going, H1EDCU_HWS.ini was removed from the DAQ to keep the EDCU green.

SDF safe vs OBSERVE reference investigation

Dave:

Not all FECs are in the OBSERVE reference. I noticed that it is not easy to trend which file is being used at any time in the past (e.g. when in observation mode). I have written a python script to add the SDF channels to the FEC autoBurt.req so the hourly autoburt will record this information. Plus conlog will then also monitor these channels for a true trend.

h1guardian0 reboot

TJ, Dave:

h1guardian0 was rebooted. It came back up with no problems. I took the opportunity to apply a safe-upgrade patch.

WP6485 Bullseye QPD install

Sheila, Jenne, Richard, Daniel, Dave:

As part of this WP, the h1ecatc1plc2 code was changed to control the spare whitening chassis. A new INI file was generated and added to the DAQ. A new autoBurt.req file was generated and added to the target.

DAQ

Dave:

DAQ configuration was changed to add back the H1EDCU_CONLOG.ini file and temporarily remove the H1EDCU_HWS.ini file. We had two restarts of the DAQ:

12:18PST to support isiham3 and oaf model changes

14:30PST to support Beckhoff changes

Continued WP #6472 see also entry 34052 

I rediscovered the fact that 3 of 8 of these actuators have different power requirements and are wired differently in the vacuum racks.  Prior to lifting leads to facilitate today's work, I had pulled the nominally applicable fuses.  Later I found that I had blown a fuse in the vacuum rack at an unexpected terminal number and then realized the novel wiring,  Of the three remaining actuators to be modified under WP #6472, two ought to have similar vacuum rack wiring.  I'll inquire with CDS regarding a drawing revision.

 

RobertS & HughR

Earlier in the maintenance period while Jim was centering the BRS, I exercised the BNCs and connectors attempting to correct the glitching reported in previous logs: 33648, 33767, 33976, & 33999.  I thought this had corrected the problem but my spectra had failed to resolve the problem.

The first attachment trends the problem data channels, ADC_0_9 & ADC_0_10, and others nearby in the the ADC rack--they happen to be magnetometers, for twenty days.  On 31 Jan I made the first attempt at centering the masses.  At this time starts the positive going glitches on the PEM STS channels.  Also the unused ADC_0_11 changes DC level and gets much noisier.  Notice too on 2 Feb when the STS masses were successfully centered, the ADC_0_11 changes DC level again.

After the BRS was centered, Robert and I went back to the VEA and tested a couple things.  See the second attachment, one hour of second trends:  The seismometer was unplugged from the host box and the Y channel was disconnected from the ADC.  After that Robert exposed the back of the host box and looked for issues--he thought he smelled some insulation.  During this period, the glitching disappeared from the nearby ADC channel.  When returned to service, the glitches returned as well.  The spectra looks as it did before: with enough resolution, these 46 second period glitches show a comb at lower frequencies and there is a 1/f shelf beginning at 50 or 60Hz.

Our suspicion is this host box is troubled and we should swap it out to confirm.  We'd like to exchange the Host Box from the HAM2 STS.

WP 6476

1. Installed interlock feedthrough panels on the TCS and HWS tables. While on table, Richard/Jason looked at the serial numbers for the lasers installed.

2. Looked at ISCT6, interlock monitoring system reported issues with the panels. Found one of the panels installed upside down.

F. Clara, P. King, J. Oberling, R. McCarthy

TITLE: 02/14 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:

• after commissioning I started an Initial Alignment
• ALS locked, aligned
• still working on locking X arm in IR
• symptom: locks only for about 2 seconds
  • turned ISI config back to Windy, which turned both BRSs back on
  • raised gain, lowered gain
  • tweaked alignment of IM4
  • reran ISC_LOCK through Init and Down and back to Initial Alignment
  • no improvement
  • asked Sheila to help
  • reset IM4 to alignment before Initial Alignment
  • raised gain, lowered gain
  • watched arms flash while in DOWN
  • I tweaked alignment of IM4 yaw by 10urad steps
  • longest lock as of my alog was about 4 seconds
• Sheila's still working on it
• handing OPS off to Patrick

TITLE: 02/15 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 3mph Gusts, 2mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.55 μm/s 
QUICK SUMMARY:

Cheryl and Sheila are troubleshooting locking the X arm on IR in initial alignment.

J. Kissel for J. Batch, J. Hanks, and J. Zweizig
CDS Bugzilla Ticket #1072

The interferometer output that is used by astrophysical searches, GDS-CALIB_STRAIN and DCS_CALIB_STRAIN_${calversion} (when available) are now available via DTT, thanks to J. Batch, J. Hanks, and J. Zweizig.

I attach a screenshot of a random time in which the IFO was observing and I know DCS-CALIB_STRAIN_CO1 is available (Jan 12 2017 @ 12:00 UTC) for proof.

The update that was required to DTT is not yet a part of the default call, so here're the instructions to-date:
(1) In a terminal, source the needed newer version of gds package that has this update:
    ]$ source /ligo/apps/linux-x86_64/gds-2.17.9-2/etc/gds-user-env.sh
(2) Initialize your kerberos ticket so you can use NDS2:
    ]$ kinit
    Password for arbert.einstein@LIGO.ORG:
(3) Start DTT:
    ]$ diaggui &
(4) Under the input tab, select "NDS2", then click over to the "Measurement" tab. Be patient while the NDS2 channel list is downloaded into DTT. You can reduce this time a little bit by narrowing down the Epoch Start and Stop times.
(5) Select the channels from the drop-down menus. Note 
    (a) for GDS-CALIB_STRAIN and DCS-CALIB_STRAIN_${calversion} the time you're requesting *MUST* be in the past. 
    (b) If you're requesting DCS-CALIB_STRAIN_${calversion}, you should check whether the data has been generated yet (see status table on the JRPC wiki.ligo.org page), since this is done manually when the calibration group feels it has a new better product to release.
(6) To calibrate into displacement units, [m], here's the DTT calibration:
    CAL-DELTAL_EXTERNAL_DQ
        Gain: 1 
        Poles: 0.3, 0.3, 0.3, 0.3, 0.3, 0.3
        Zeros: 30, 30, 30, 30, 30, 30

    GDS-CALIB_STRAIN
        Gain: 3994.47
        Poles: (none)
        Zeros: (none)

    DCS-CALIB_STRAIN
        Gain: 3994.47
        Poles: (none)
        Zeros: (none)

If you want the time-dependent correction factors in the GDS-CALIB* or DCS-CALIB* family of channels, they can be found under the "H1 (slow)" folder, e.g. 
    H1:GDS-CALIB_KAPPA_C

Happy hunting!

"One small step for man, one giant leap for mankind..."

Krishna drove out from Seattle this morning to provide moral support, so we tried resurrecting BRS-Y. After another two hours of trying, we finally got it in a position where it's usable, though still on the low side of it's range. It should be functional for another couple of months, though I'll want to fully assess that after the box heats up a bit overnight. It seems like most of the difficulty of adjustment was coming from the mass having a "happy place" that was too far beyond a usable place (i.e some alignment of contact grooves would pull the mass too far one way). This "happy place" is in the direction of the BRS drift, so maybe we'll be luckier next time. Anyway, it's running now, we can go back to the nominal SEI_CONF state of WINDY.

J. Kissel

Attached are the weekly charge measurements on the H1 ETMs. 

While the effective bias voltage remains low ( > +/- 10 [V]) for most quadrants of both test masses, ETMY is showing a consistent negative trend. This may be a result of H1's incredibly high duty cycle of the past few weeks (see O2 Time Accounting Page, weeks 8-10), which means 
    > the ESD is always in use with one requested bias voltage sign, and 
        >> little time is spent with the opposite sign requested bias voltage, 
            >>> free ions of a particular signed voltage continue to accumulate

Sheesh! We can't win when it comes to maintaining minimal charge accumulation: If we flip the bias when in use, we're liable to screw up the calibration (e.g. LHO aLOG 29868). If we flip the bias when not in use, we need a medium observing duty cycle in order to split the time between in-and-out- of use evenly (see evidence in this aLOG).

Perhaps we should resume thinking about what are the remaining *source* of free ions in the chamber... 

• 21:59, Chandra, John, and guest, heading to MX and possibly MY
• 22:00, Jenne, Sheila, out of PSL
• 22:01, I restart VerbalAlarms
• 22:01, JeffK, charge measurements will be done in about 10 minutes
• Will start relocking after that.
   

J. Kissel

Back in 2015, Leo updated the charge measurement scripts
    /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts/
    ESD_Night_ETMX.py
    ESD_Night_ETMY.py
to include automatic centering of the ETMs to the optical lever QPDs because he had found charge measurement results showed flaws if the optical lever was drastically miscentered (see LHO aLOG 19645). 

It's unclear why (it's pretty dense code, and I don't have the time to debug), but over the course of time, this auto-centering has become more problematic than it is useful: 
   - It makes an initial alignment adjustment to the alignment sliders (OPTICALIGN offsets) based on a measurement of the starting spot position.
   - the OPTICALIGN offsets have a finite ramping time (of order 2-10 seconds); before waiting for the ramp to finish or the optic to settle, it measures the spot position again, thinks its still miscentered, and makes another adjustment. 
   - This results in a semi-infinite loop of centering, and the charge measurements never start. 
Lately, even if I manually adjust the ETM alignment to be centered on the optical lever before I start the script, and hold the output of the OPTICALIGN banks such that the script *can't* have an influence on the centering, it *still* gets caught in the loop complaining that the optic is not yet aligned.

For the time being, I've commented out the use of the function OpLevAlign on line 616 (for both scripts). For reference, that function's definition starts on line 268 (for both scripts). I've commited the changes to the SUS repo.

I've also updated the charge measurement wiki page to reflect that one needs to be sure that (with the OPTIC's guardian in the ALIGNED state) the optic is centered on the optical lever before starting the measurements. 

Attached is a list of the perl scripts under /opt/rtcds/userapps/release/ at LHO. Their creation date is also shown. 

ECR E1700056 approves migrating these to python if and when applicable.

J. Kissel
ECR: E1700056
WP: #6484
FRS: #4231

I've upgraded the remaining SUS watchdog MEDM screens to call the new script,
    /opt/rtcds/userapps/release/sus/common/scripts/wdreset_all.py
and committed the changes to the following locations in the userapps repo:
    /opt/rtcds/userapps/release/sus/common/medm/
        bsfm/SUS_CUST_BSFM_WD.adl
        hxts/SUS_CUST_HXTS_WD.adl
        omcs/SUS_CUST_OMCS_WD.adl
        tmts/SUS_CUST_TMTS_WD.adl

I've also confirmed that each change works for at least one instance of all the above SUS types. 

We will continue to look for other, hopefully non-essential scripts that use PERL in hopes to close out this ECR. However, this will be of less priority since (we don't think) any other PERL scripts are used for IFO-imperative tasks.

JeffB's alog with the start of Maintenance is HERE (alog 34122).

Mantnenance day continued:

• 18:15, Aaron Viets, restarting calibration pipeline
• 18:17, Robert, out of LVEA, heading to EX
• 18:19, delivery to OSB
• 18:23, Dave, TJ, reset guardian
• 18:24, septic tank service
• 18:25, Fil, out of LVEA
• 18:26, Aaron Veits, pipeline restarted and all ok
• 18:37, DaveB, EX then EY, check electronics
• 18:39, ChrisS and Fire Depart, MX and then EX, checkinf sensors, all done fro the day
• 18:40, JeffB, starts LVEA transition to Laser Safe
• 18:42, JeffK, Debian watchdog work complete
• 18:43, Ken (contractor) and other, entering ECR and LVEA to survey worksite
• 18:47, Christina, at EX and leaving to get supplies and will return
• 18:47, I restarted VerbalAlarms after guardian reboot
• 18:48, TJ, relocking IMC
• 19:01, LVEA is laser safe
• 19:07, Bubba back from EY, no other parties are there
• 19:07, Christina, leaving EX, all other parties have left
• 19:07, Christina, heading to LVEA
• 19:15, Kyle, to LVEA
• 19:16, vendor, Paradice Water
• 19:24, Hugh, de-isolated HAM3
• 19:24, JeffK, tripping each type of optic suspention to test new Debian watchdog fix
• 19:37, Chandra, CP1 overfill alarm, looking into it
• 19:45, Sheila and Jenne, PSL bulleye install
• 20:06, checking on all Mantenance activities
   

Kyle found CP1 LLCV actuator flooded in his routine rounds to fix the leaky joints. Actuator was partially stroking during thawing and is now stuck at 100% open, so CP1 is currently overfilled. We're working on it.